Zugriff auf 2.VLAN vom OpenVPN-Client klappt nicht

Mitglied: orcape

orcape (Level 2) - Jetzt verbinden

15.04.2021 um 03:05 Uhr, 657 Aufrufe, 5 Kommentare

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...
openvpn-server - Klicke auf das Bild, um es zu vergrößern

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
Mitglied: aqui
LÖSUNG 15.04.2021, aktualisiert um 10:17 Uhr
Nein, das musst du natürlich nicht und wäre auch der ganz falsche Weg. Dieser Thread behandelt das gleiche Thema:
https://administrator.de/content/detail.php?id=665606&nid=1076083

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.
Bitte warten ..
Mitglied: orcape
15.04.2021 um 13:35 Uhr
Hi aqui,
und Danke erst einmal für Dein Feedback.
Die Routeneinträge sehen genau so aus, wie von Dir dargestellt...

Zur Erklärung...
interface - Klicke auf das Bild, um es zu vergrößern

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
Bitte warten ..
Mitglied: aqui
15.04.2021, aktualisiert 16.04.2021
Das sieht nach OpenWRT aus...
Das dort immer obligatorisch aktivierte NAT im VPN Tunnel hast du deaktiviert ??
nat - Klicke auf das Bild, um es zu vergrößern
Das ist das was einem bei Site-to-Site fast immer ein Bein stellt !
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.
Bitte warten ..
Mitglied: orcape
16.04.2021 um 14:21 Uhr
Hi aqui,
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.... ;-) face-wink
Gruß orcape
Bitte warten ..
Mitglied: aqui
16.04.2021 um 16:21 Uhr
👍
Case closed !
Bitte warten ..
Heiß diskutierte Inhalte
LAN, WAN, Wireless
Unterschiedliche IP-Adressbereiche im Netzwerk
achkleinVor 1 TagFrageLAN, WAN, Wireless17 Kommentare

Hallo, ich stehe vor einem Problem mit der WLAN-Verbindung zum Router (Fritzbox Cable 6490). Das verbundene Notebook hat die Adresse 192.168.0.164, Gateway ist 192.168.0.149: ...

Off Topic
Microsoft und der (leidige) Datenschutz
Franz-Josef-IIVor 1 TagAllgemeinOff Topic18 Kommentare

Hello Ich möchte vorausschicken, daß ich rein prinzipiell nichts gegen Microsoft habe, eher gegen die US-amerikanische Politik 😊 Microsoft bietet die Datenverarbeitung in der ...

Off Topic
32 bit Problem
brammerVor 1 TagAllgemeinOff Topic9 Kommentare

Hallo, also das ist mal ein Problem das ich auch haben möchte eine Aktie ist mehr Wert als das die Börsensoftware darstellen kann. brammer

Hardware
Thin- oder Zero-Client für RDP und Dual-Monitor im LAN gesucht
FestplattenaufzieherVor 1 TagFrageHardware9 Kommentare

Hallo, Kurzfassung meiner Frage: Ich suche Thin/Zero-Clients (4 Stück) mit Dual-Monitor-Unterstützung für den RDP-Zugriff auf PCs in einem LAN - idealerweise lautlos und relativ ...

Windows Server
Lizenzen für Virtualisierungshost
TakworianVor 11 StundenFrageWindows Server15 Kommentare

Hallo, ich werde demnächst einen HA-Cluster aus 3 x HP DL580 in Betrieb nehmen. Der Cluster wird unter Proxmox betrieben und es sollen diverse ...

Windows 10
Windows 10 2021-04 end of life?
gelöst Paedi12Vor 1 TagFrageWindows 103 Kommentare

Hi Leute! Ich bin gerade auf der Suche, wie lange die Windows Version 2021-04 unterstützt wird. Kann aber nichts finden. Hat jemand eine Ahnung, ...

Switche und Hubs
Netgear Switch Problem bei VLAN Konfiguration
gelöst meltersVor 1 TagFrageSwitche und Hubs15 Kommentare

Hallo, ich habe einen Netgear XS716T Switch zum Testen in Betrieb genommen, komme aber mit der VLAN Konfiguration nicht so ganz klar. Bislang habe ...

Router & Routing
Suche Tipps für Selfmade-Load-Balancing-Router auf HP MicroServer Gen10+
gelöst MagicChris86Vor 1 TagFrageRouter & Routing7 Kommentare

Hi Leute, ich habe einen HP MicroServer Gen10+ Performance übrig, der bei einer Kundin rausgeflogen ist, weil sie mehr Power brauchte für Desktopvirtualisierung für ...