5
Zugriff auf 2.VLAN vom OpenVPN-Client klappt nicht
Hi Leute,
ich habe eine OpenVPN-Verbindung zu einem Gartengrundstück, die Server-Seitig ein APU macht und der Client bis vor einigen Tagen noch auf einem ALIX/pfSense mit 2 LAN-Netzen, terminiert war. Das eine Netz stellt mir das LAN/WLAN, das andere 2 IP-KAmeras, die ich von zu Hause erreichen kann.
Nun bin ich dort nach einem Providerwechsel, von UMTS/3 G auf LTE umgestiegen, dem nun leider mein ALIX/pfSense 2.3.5 wegen Inkompatibilität des LTE-Sticks weichen musste.
Eine alte Fritzbox3370, der ich vor einiger Zeit OpenWRT beigebracht habe, hat nun die Funktion des Alix übernehmen müssen. Ein anfängliches OpenVPN-Problem konnte ich mit einem Kernel-Upgrade fixen und das 2. LAN habe ich mit den VLAN-Einstellungen des Switches erstellt. Auch die LTE-Verbindung zu beiden VLAN 's klappt problemlos.
Was nicht funktioniert, ist die OpenVPN-Client Verbindung ins 2.VLAN. Logge ich mich per ssh von Client- oder Server-Seite ins 1.VLAN des Clients ein und gehe von da zum 2.VLAN, so ist die Verbindung bis zu meinem PC zu Hause vorhanden.
Umgekehrt ist auf der OpenVPN-Serverseite zum 2.VLAN Schluss, obwohl die Routing-Tabelle, zumindest im GUI der pfSense anderes sagt. Per ssh fehlt mir die Route zu diesem 2.VLAN allerdings, obwohl der Server richtig eingerichtet ist.
Tabelle des Servers im GUI...
Hier die Tabelle per ssh-Zugriff...
Das Netz 192.168.8.0/24 ist der Zugriff auf den LTE-Stick.
Das Netz 192.168.33.0/24 ist der Zugriff auf VLAN 1.
Das Netzwerk 192.168.6.0/24, wie im GUI ersichtlich, fehlt hier allerdings.
Hier die Tabelle des OpenWRT-Clients...
Das 2.VLAN-Netz "192.168.6.0 * 255.255.255.0 U 0 0 0 eth0.3" ist für die Kameras gedacht, aber eben nicht von zu Hause erreichbar.
Das Netz 10.100.10.0/24 ist mein Home-Netz, erklärt also auch die Verbindung "nach Hause".
Muss ich auf Grund der VLAN-Einstellungen auf der Fritten-WRT-Box, die beim ALIX nicht nötig war, eventuell eine 2.OpenVPN-Instanz "bemühen"?
Zumindest sind alle Interfaces eingerichtet, Firewallregeln angepasst und... ich komme nicht weiter.
Danke für Eure Hilfe...
Gruß orcape
ich habe eine OpenVPN-Verbindung zu einem Gartengrundstück, die Server-Seitig ein APU macht und der Client bis vor einigen Tagen noch auf einem ALIX/pfSense mit 2 LAN-Netzen, terminiert war. Das eine Netz stellt mir das LAN/WLAN, das andere 2 IP-KAmeras, die ich von zu Hause erreichen kann.
Nun bin ich dort nach einem Providerwechsel, von UMTS/3 G auf LTE umgestiegen, dem nun leider mein ALIX/pfSense 2.3.5 wegen Inkompatibilität des LTE-Sticks weichen musste.
Eine alte Fritzbox3370, der ich vor einiger Zeit OpenWRT beigebracht habe, hat nun die Funktion des Alix übernehmen müssen. Ein anfängliches OpenVPN-Problem konnte ich mit einem Kernel-Upgrade fixen und das 2. LAN habe ich mit den VLAN-Einstellungen des Switches erstellt. Auch die LTE-Verbindung zu beiden VLAN 's klappt problemlos.
Was nicht funktioniert, ist die OpenVPN-Client Verbindung ins 2.VLAN. Logge ich mich per ssh von Client- oder Server-Seite ins 1.VLAN des Clients ein und gehe von da zum 2.VLAN, so ist die Verbindung bis zu meinem PC zu Hause vorhanden.
Umgekehrt ist auf der OpenVPN-Serverseite zum 2.VLAN Schluss, obwohl die Routing-Tabelle, zumindest im GUI der pfSense anderes sagt. Per ssh fehlt mir die Route zu diesem 2.VLAN allerdings, obwohl der Server richtig eingerichtet ist.
Tabelle des Servers im GUI...
Hier die Tabelle per ssh-Zugriff...
Destination Gateway Flags Netif Expire
default fritz.box UGS igb0
10.10.4.0/24 10.10.4.2 UGS ovpns6
10.10.4.1 link#15 UHS lo0
10.10.4.2 link#15 UH ovpns6
192.168.8.0/24 10.10.4.2 UGS ovpns6
192.168.33.0/24 10.10.4.2 UGS ovpns6Das Netz 192.168.33.0/24 ist der Zugriff auf VLAN 1.
Das Netzwerk 192.168.6.0/24, wie im GUI ersichtlich, fehlt hier allerdings.
Hier die Tabelle des OpenWRT-Clients...
root@Leonardo:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.8.1 0.0.0.0 UG 10 0 0 eth1
10.10.4.1 10.10.4.1 255.255.255.255 UGH 0 0 0 tun0
10.100.10.0 10.10.4.1 255.255.255.0 UG 0 0 0 tun0
172.16.7.0 10.10.4.1 255.255.255.0 UG 0 0 0 tun0
192.168.6.0 * 255.255.255.0 U 0 0 0 eth0.3
192.168.8.0 * 255.255.255.0 U 10 0 0 eth1
192.168.33.0 * 255.255.255.0 U 0 0 0 br-lan
192.168.219.0 * 255.255.255.0 U 10 0 0 eth0.2Das 2.VLAN-Netz "192.168.6.0 * 255.255.255.0 U 0 0 0 eth0.3" ist für die Kameras gedacht, aber eben nicht von zu Hause erreichbar.
Das Netz 10.100.10.0/24 ist mein Home-Netz, erklärt also auch die Verbindung "nach Hause".
Muss ich auf Grund der VLAN-Einstellungen auf der Fritten-WRT-Box, die beim ALIX nicht nötig war, eventuell eine 2.OpenVPN-Instanz "bemühen"?
Zumindest sind alle Interfaces eingerichtet, Firewallregeln angepasst und... ich komme nicht weiter.
Danke für Eure Hilfe...
Gruß orcape
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665754
Url: https://administrator.de/forum/zugriff-auf-2-vlan-vom-openvpn-client-klappt-nicht-665754.html
Ausgedruckt am: 31.12.2024 um 10:12 Uhr
5 Kommentare
Neuester Kommentar
Nein, das musst du natürlich nicht und wäre auch der ganz falsche Weg. Dieser Thread behandelt das gleiche Thema:
Routing zw. 2 Tunneln auf EINEM openVPN-Server
Grundkonfig bei dir ist ja eine simple Site-to-Site Konfig wie sie auch hier zu sehen ist.
Der OpenVPN Server muss bei dir folgende Zeilen in der Konfig haben:
push "route 192.168.1.0 255.255.255.0"
route 192.168.3.0 255.255.255.0
route 192.168.8.0 255.255.255.0
route 192.168.66.0 255.255.255.0
Der erste Eintrag pusht das lokale LAN Des Servers (geraten mit .1.0 !) in die Routing Tabelle des Garten Clients. Die anderen 3 Einträge machen die lokalen LANs des Garten Clients in der Kernel Routing Tabelle des Servers bekannt.
Vermutlich hast du dann ein Client spezifisches Verzeichnis im Server, dort sollte dann bei einemk Site-to_Site die zum Common Name des Clients passende Client Konfig im Server stehen:
ifconfig-push 10.10.4.2 255.255.255.0
iroute 192.168.3.0 255.255.255.0
iroute 192.168.8.0 255.255.255.0
iroute 192.168.66.0 255.255.255.0
Das sind dann die OpenVPN Routen die dem Server sagen er soll .3.0, .8.0 und .66.0 in den Tunnel zum internen Client 10.10.4.2 routen.
Damit wäre dann routingtechnisch alles OK, was du überprüfen musst.
Mit etwas intelligentem Subnetting könnte man sich die 3 Einzelrouten ersparen und es mit einem einzelnen Eintrag erledigen. Leider schreibst du nicht welches lokale LAN du am Server benutzt aber z.B. mit einem 17 Bit Prefix (255.255.128.0) könnte man alle Netze von .0.0 bis .127.0 mit einem route Kommando bedienen.
Die siehst hier aber schon das Dilemma deines etwas unglücklichen Subnettings denn in dem Beispiel würde es nicht gehen weil das Routing Kommando auch das lokale LAN .1.0 mit inkludiert.
Leider bewirkt auch die unglückliche Wahl nur des .66er Subnetzes das man gleich wieder einen größeren Subnetzsprung mit einer 17 Bit Maske machen muss.
Wäre das intelligenter in den 4, 8, 16, 32 usw. Grenzen gewählt hätte man es kosmetisch sauberer lösen können. Oder die lokalen Client Netze in einen anderen RFC 1918 Bereich gelegt.
Routing zw. 2 Tunneln auf EINEM openVPN-Server
Grundkonfig bei dir ist ja eine simple Site-to-Site Konfig wie sie auch hier zu sehen ist.
Der OpenVPN Server muss bei dir folgende Zeilen in der Konfig haben:
push "route 192.168.1.0 255.255.255.0"
route 192.168.3.0 255.255.255.0
route 192.168.8.0 255.255.255.0
route 192.168.66.0 255.255.255.0
Der erste Eintrag pusht das lokale LAN Des Servers (geraten mit .1.0 !) in die Routing Tabelle des Garten Clients. Die anderen 3 Einträge machen die lokalen LANs des Garten Clients in der Kernel Routing Tabelle des Servers bekannt.
Vermutlich hast du dann ein Client spezifisches Verzeichnis im Server, dort sollte dann bei einemk Site-to_Site die zum Common Name des Clients passende Client Konfig im Server stehen:
ifconfig-push 10.10.4.2 255.255.255.0
iroute 192.168.3.0 255.255.255.0
iroute 192.168.8.0 255.255.255.0
iroute 192.168.66.0 255.255.255.0
Das sind dann die OpenVPN Routen die dem Server sagen er soll .3.0, .8.0 und .66.0 in den Tunnel zum internen Client 10.10.4.2 routen.
Damit wäre dann routingtechnisch alles OK, was du überprüfen musst.
Mit etwas intelligentem Subnetting könnte man sich die 3 Einzelrouten ersparen und es mit einem einzelnen Eintrag erledigen. Leider schreibst du nicht welches lokale LAN du am Server benutzt aber z.B. mit einem 17 Bit Prefix (255.255.128.0) könnte man alle Netze von .0.0 bis .127.0 mit einem route Kommando bedienen.
Die siehst hier aber schon das Dilemma deines etwas unglücklichen Subnettings denn in dem Beispiel würde es nicht gehen weil das Routing Kommando auch das lokale LAN .1.0 mit inkludiert.
Leider bewirkt auch die unglückliche Wahl nur des .66er Subnetzes das man gleich wieder einen größeren Subnetzsprung mit einer 17 Bit Maske machen muss.
Wäre das intelligenter in den 4, 8, 16, 32 usw. Grenzen gewählt hätte man es kosmetisch sauberer lösen können. Oder die lokalen Client Netze in einen anderen RFC 1918 Bereich gelegt.
Hi aqui,
und Danke erst einmal für Dein Feedback.
Die Routeneinträge sehen genau so aus, wie von Dir dargestellt...
Zur Erklärung...
Mein LAN ist ein VLAN an der APU mit dem Netz 10.100.10.0/24.
Der derzeit über den Tunnel nicht zu erreichende Netzbereich an der OpenWRT-Fritte, ist das als "DMZ" bezeichnete Interface 192.168.6.0/24.
Der Switch der Fritte ist wie folgt eingestellt...
DMZ = eth0.3 = Switch Port4
LAN Bridge mit WLAN = eth0.1 = Switch Port 2/3 192.168.33.0/24
WWAN = eth0.2 = Switch Port 1 (Port 1 ist bei der Original-Fritten-Firmware der WAN im Routermodus) ..noch eingestellt (WAN) für das Netz 192.168.219.0/24
WWANB 0 eth1 = USB-Port mit LTE-Stick DHCP 192.168.8.0/24
Die VLAN-Trennung zwischen Switch-Port 1 und dem Rest des Switches, ist ja bei der Fritte technisch schon so vorgesehen, um überhaupt eine Routerkaskade realisisieren zu können. OpenWRT gibt mir ja erst die Möglichkeit den Switch als VLAN noch weiter zu modifizieren, was ja auch insoweit funktioniert, da ich ja für das Netz 192.168.6.0/24 eine LTE-Verbindung habe und das Netz auch vom VLAN 192.168.33.0/24 getrennt ist.
Laut Logs der Server-pfSense baut sich die Route zu 192.168.6.0/24 auch auf....
nur scheint das VLAN des Tunnels nicht mit dem OpenWRT kreierten VLAN des Fritten-Switches zu können.
Wie gesagt, logge ich mich per ssh im VLAN-Netz 192.168.33.0/24 ein, egal ob vom Tunnel oder direkt an der Fritte, komme ich auch in das andere Netz und habe von da aus auch eine Rück-Verbindung "nach Hause".
Nur die Hin-Route ist beim VPN-Server 10.10.4.1 zu Ende und das wird so mit "netstat -r" auf der pfSense auch bestätigt.
Die Firewall ist derzeit eine Art Scheunentor, sollte also als Ursache ausscheiden und eine zusätzliche statische Route scheidet wohl auch aus, da die Routen auf dem OpenVPN-Server definiert werden.
Nun steht er da, der Rudi ratlos....
Gruß orcape
und Danke erst einmal für Dein Feedback.
Die Routeneinträge sehen genau so aus, wie von Dir dargestellt...
Zur Erklärung...
Mein LAN ist ein VLAN an der APU mit dem Netz 10.100.10.0/24.
Der derzeit über den Tunnel nicht zu erreichende Netzbereich an der OpenWRT-Fritte, ist das als "DMZ" bezeichnete Interface 192.168.6.0/24.
Der Switch der Fritte ist wie folgt eingestellt...
DMZ = eth0.3 = Switch Port4
LAN Bridge mit WLAN = eth0.1 = Switch Port 2/3 192.168.33.0/24
WWAN = eth0.2 = Switch Port 1 (Port 1 ist bei der Original-Fritten-Firmware der WAN im Routermodus) ..noch eingestellt (WAN) für das Netz 192.168.219.0/24
WWANB 0 eth1 = USB-Port mit LTE-Stick DHCP 192.168.8.0/24
Die VLAN-Trennung zwischen Switch-Port 1 und dem Rest des Switches, ist ja bei der Fritte technisch schon so vorgesehen, um überhaupt eine Routerkaskade realisisieren zu können. OpenWRT gibt mir ja erst die Möglichkeit den Switch als VLAN noch weiter zu modifizieren, was ja auch insoweit funktioniert, da ich ja für das Netz 192.168.6.0/24 eine LTE-Verbindung habe und das Netz auch vom VLAN 192.168.33.0/24 getrennt ist.
Laut Logs der Server-pfSense baut sich die Route zu 192.168.6.0/24 auch auf....
Apr 15 11:47:41 openvpn 70837 alwin/2.247.247.252:4868 MULTI: primary virtual IP for alwin/2.247.247.252:4868: 10.10.4.2
Apr 15 11:47:41 openvpn 70837 alwin/2.247.247.252:4868 MULTI: internal route 192.168.8.0/24 -> alwin/2.247.247.252:4868
Apr 15 11:47:41 openvpn 70837 alwin/2.247.247.252:4868 MULTI: Learn: 192.168.8.0/24 -> alwin/2.247.247.252:4868
Apr 15 11:47:41 openvpn 70837 alwin/2.247.247.252:4868 MULTI: internal route 192.168.6.0/24 -> alwin/2.247.247.252:4868
Apr 15 11:47:41 openvpn 70837 alwin/2.247.247.252:4868 MULTI: Learn: 192.168.6.0/24 -> alwin/2.247.247.252:4868
Apr 15 11:47:41 openvpn 70837 alwin/2.247.247.252:4868 MULTI: internal route 192.168.33.0/24 -> alwin/2.247.247.252:4868
Apr 15 11:47:41 openvpn 70837 alwin/2.247.247.252:4868 MULTI: Learn: 192.168.33.0/24 -> alwin/2.247.247.252:4868 nur scheint das VLAN des Tunnels nicht mit dem OpenWRT kreierten VLAN des Fritten-Switches zu können.
Wie gesagt, logge ich mich per ssh im VLAN-Netz 192.168.33.0/24 ein, egal ob vom Tunnel oder direkt an der Fritte, komme ich auch in das andere Netz und habe von da aus auch eine Rück-Verbindung "nach Hause".
Nur die Hin-Route ist beim VPN-Server 10.10.4.1 zu Ende und das wird so mit "netstat -r" auf der pfSense auch bestätigt.
Die Firewall ist derzeit eine Art Scheunentor, sollte also als Ursache ausscheiden und eine zusätzliche statische Route scheidet wohl auch aus, da die Routen auf dem OpenVPN-Server definiert werden.
Nun steht er da, der Rudi ratlos....
Gruß orcape
Das sieht nach OpenWRT aus...
Das dort immer obligatorisch aktivierte NAT im VPN Tunnel hast du deaktiviert ??
Das ist das was einem bei Site-to-Site fast immer ein Bein stellt !
Das dort immer obligatorisch aktivierte NAT im VPN Tunnel hast du deaktiviert ??
Laut Logs der Server-pfSense baut sich die Route zu 192.168.6.0/24 auch auf....
Relevant ist immer was in ihrer Kernel Routing Tabelle steht (Diagnostics). Dort sollten diese Netze immer auf das OVPN Tunnelinterface gemappt sein.
Hi aqui,
...nach langen Lösungs-Versuchen mit Änderung von Switcheinstellungen, mit nur 2 Interfaces im VLAN-Bereich, bei dem ich Port 1 der Fritte dem 2. LAN zugeordnet hatte, immer wieder nur die Route zum Netz 192.168.33.0/24.
Als letzter Versuch kam mir dann die Äußerung von @aqui in den Sinn, von wegen "intelligentem Subnetting".
Nun ja, große Veränderungen habe ich an meiner pfSense nicht vorgenommen, auf der mehrere OpenVPN-Instanzen werkeln und wo wohl auch die Ursache dieses Routingproblems lag.
Zumindest war dann mit der Änderung der Subnetzmaske auf 192.168.6.0/27, das Problem Geschichte.
Es hätte wohl auch einfach nur ein anderes Netz getan, aber hier kam wieder die Faulheit ins Spiel, denn an den Switch für die Kameras ist schlecht heran zu kommen, um dort dann die IP 's zu ändern.
Also danke noch mal, vieles wird gut....
Gruß orcape
Das ist das was einem bei Sit-to_Site fast immer ein Bein stellt !
War nur mal so ein "untauglicher Versuch", der mir eigentlich klar war, das es Blödsinn ist, aber.......nach langen Lösungs-Versuchen mit Änderung von Switcheinstellungen, mit nur 2 Interfaces im VLAN-Bereich, bei dem ich Port 1 der Fritte dem 2. LAN zugeordnet hatte, immer wieder nur die Route zum Netz 192.168.33.0/24.
Als letzter Versuch kam mir dann die Äußerung von @aqui in den Sinn, von wegen "intelligentem Subnetting".
Nun ja, große Veränderungen habe ich an meiner pfSense nicht vorgenommen, auf der mehrere OpenVPN-Instanzen werkeln und wo wohl auch die Ursache dieses Routingproblems lag.
Zumindest war dann mit der Änderung der Subnetzmaske auf 192.168.6.0/27, das Problem Geschichte.
Es hätte wohl auch einfach nur ein anderes Netz getan, aber hier kam wieder die Faulheit ins Spiel, denn an den Switch für die Kameras ist schlecht heran zu kommen, um dort dann die IP 's zu ändern.
Also danke noch mal, vieles wird gut....
Gruß orcape
👍
Case closed !
Case closed !
