nurbobald
Goto Top

VPN hinter Doppel-NAT

Hallo Experten,

ich bekomme keine VPN-Verbindung zu meinem TP-Link ER605 Router:

netzwerkdiagramm2

Der erste Router hat eine statische IP-Adresse auf der WAN-Seite und funkt alles drahtlos zu einer Wireless-Station, die im Bridge modus arbeitet und deren Ethernet-Seite die 192.168.0.2 als Adresse hat. Ich habe eine DMZ eingerichtet und alle Anfragen vom WAN an die 192.168.0.2 weitergereicht. Router 2. sieht als statische WAN-Adresse eben diese 192.168.0.2.

Zum Test habe ich in einem der Sub-Netze einen Web-Server laufen und nochmals eine Port-Weiterleitung auf dem 2. Router für Port 80 HTTP eingerichtet. Geht: Ich komme von Aussen, also WAN, durch beide router bis zum Web-Server.

Auf dem 2. Router habe ich diverse VPN-Server ausprobiert (OpenVPN, Wireguard, IKEv2) aber ich bekomme immer nur Time-Out Fehler auf dem Android-Handy, mit dem ich das teste. Ich sehe nichts in den Logs, nichtmal das ein Verbindungsversuch stattgefunden hat. Die VPN-Server laufen ja auf dem Router 2 und haben keine eigene IP-Adresse. Ich kann also auch keine Ports dahin weiterleiten.

Ich kann beide LigoDLBs in den bridge-Modus versetzen. Ich hatte gehofft, die benehmen sich dann wie ein extra langes Kupferkabel. Aber der ER605 kann damit keine PPPoE Verbindung mit meinem ISP aufbauen (Time-Out). Deshalb habe ich zwei router die bei NAT machen.

Hat jemand ein paar Ideen, wo ich suchen kann?


Vielen Dank,
nurbo

Hardware:
Router 1 und wireless bridge: LigoDLB
Router 2: TP-Link ER605 mit Omada SDN

Content-ID: 83161701689

Url: https://administrator.de/contentid/83161701689

Ausgedruckt am: 25.11.2024 um 09:11 Uhr

MysticFoxDE
MysticFoxDE 04.06.2024 aktualisiert um 23:45:36 Uhr
Goto Top
Moin @nurbobald,

ich bekomme keine VPN-Verbindung zu meinem TP-Link ER605 Router:

netzwerkdiagramm2

und wie sieht die IP-Konfiguration des TP-Link ER605 aus, denn diese wichtigen Infos, hast du auf dem Bildchen leider vergessen.

Der erste Router hat eine statische IP-Adresse auf der WAN-Seite

Das ist soweit OK und er hat so wie ich das auf dem Bildchen sehe, auch eine statische/feste IP (192.168.0.1) auf der LAN Seite ...

und funkt alles drahtlos zu einer Wireless-Station, die im Bridge modus arbeitet und deren Ethernet-Seite die 192.168.0.2 als Adresse hat.

... aber spätestens das verstehe ich nicht mehr so ganz, denn wenn die LigoDLB im Bridge-Modus läuft, verhält die sich eigentlich quasi wie ein Patchkabel und nicht wie ein Router, daher verstehe ich nicht so ganz ...

Ich habe eine DMZ eingerichtet und alle Anfragen vom WAN an die 192.168.0.2 weitergereicht. Router 2. sieht als statische WAN-Adresse eben diese 192.168.0.2.

... warum du am Router 1, den vom WAN kommenden Datenverkehr, per NAT an die Bridge weiterleitest. 😖
Denn diesen musst du bei der Konfiguration nicht an die LigoDLB-Bridge weiterleiten, sondern eher an die IP des TP-Link ER605 aus dem 192.168.0.x Netz. 😉

Zum Test habe ich in einem der Sub-Netze einen Web-Server laufen und nochmals eine Port-Weiterleitung auf dem 2. Router für Port 80 HTTP eingerichtet. Geht: Ich komme von Aussen, also WAN, durch beide router bis zum Web-Server.

😵‍💫 ... das sollte so eigentlich nicht gehen.

Auf dem 2. Router habe ich diverse VPN-Server ausprobiert (OpenVPN, Wireguard, IKEv2) aber ich bekomme immer nur Time-Out Fehler auf dem Android-Handy, mit dem ich das teste. Ich sehe nichts in den Logs, nichtmal das ein Verbindungsversuch stattgefunden hat.

Wundert mich auch nicht wirklich, da diese anfragen an der Konfigurations-IP der LigoDLB-Bridge landen und nicht an der IP des zweiten Routers.

Die VPN-Server laufen ja auf dem Router 2 und haben keine eigene IP-Adresse. Ich kann also auch keine Ports dahin weiterleiten.

Ähm, aber selbstverständlich sollte dein TP-Link ER605 auch eine IP aus dem 192.168.0.x Netz haben und genau auf diese, musst du per NAT die Ports 500 (TCP & UDP) bei z.B. Verwendung von IKEv2 umlegen.

Ich kann beide LigoDLBs in den bridge-Modus versetzen.

Ähm, wie soll ich das jetzt verstehen, den weiter oben hast du ja das folgende geschrieben ...

... funkt alles drahtlos zu einer Wireless-Station, die im Bridge modus arbeitet ...

... sprich, wenn die LigoDLBs bereits im Bridge Modus laufen, dann kannst du die ja wohl kaum nochmals in den Bridge Modus umstellen.

OK, jetzt verstehe ich das Problem glaube ich etwas besser ... deine LigoDLBs laufen aktuell nicht im Bridge-Modus, sondern eher im Routing-Modus und dann macht das mit dem NAT auf die 192.168.0.2, auch wieder etwas mehr Sinn. 🙃

Ich hatte gehofft, die benehmen sich dann wie ein extra langes Kupferkabel.

Ja, wenn die LigoWave LigoDLB's im Bridge-Modus laufen, dann sollten die sich auch genau so verhalten.

Aber der ER605 kann damit keine PPPoE Verbindung mit meinem ISP aufbauen (Time-Out). Deshalb habe ich zwei router die bei NAT machen.

😯 ... ähm ... und warum möchtest du den nochmals eine PPPoE Verbindung am Router 2 aufbauen, wenn diese bereits schon auf dem Router 1 aufgebaut wird?

Hat jemand ein paar Ideen, wo ich suchen kann?

Ja definitiv.
Du solltest den ersten Router, wenn möglich in reinen DSL-Modem (PPPoE-Passthrough) umkonfigurieren, dann die LigoWave LigoDLB's wirklich in den Bridge-Modus stellen und dann solltest du am TP-Link ER605 auch direkt die PPPoE Verbindung zum Provider aufbauen, sprich die WAN Verbindung wird dann direkt am Router 2 terminiert und somit kannst du dir den ganzen NAT-Geraffel davor auch einfach sparen. 😉

Router 1 und wireless bridge: LigoDLB

Verstehe ich das Richtig, dass einer der beiden LigoWave LigoDLB's Geräte auch zugleich direkt am WAN hängt und die PPPoE Verbindung aufbaut?

Wenn ja, dann musst du wahrscheinlich, wenn du die LigoWave LigoDLB's im Bridge-Modus betreibst, Richtung WAN noch ein PPPoE Modem alla DrayTek Vigor 160er Serie davorhängen.
Ausser, die LigoWave LigoDLB's unterstützen im Bridge-Modus auch PPPoE-Passthrough, aber das glaube ich eher weniger.

Gruss Alex
MysticFoxDE
MysticFoxDE 04.06.2024 aktualisiert um 23:58:47 Uhr
Goto Top
Moin @nurbobald,

Router 1 und wireless bridge: LigoDLB

ich kennen die LigoDLB's nicht wirklich, daher habe ich auch vorhin eine Weile gebraucht um dein Konstrukt zu verstehen. 🙃
Habe mir soeben die LigoWave Gerätchen jedoch genauer angesehen, ich finde jedoch keines, welches auch einen integriertes VDSL Modem hat.

Wie und zu welchem Provider, baut also dein erster LigoDLB eine PPPoE Verbindung auf?
Hängt da etwa noch ein ISP-Modem/Router davor?

Gruss Alex
aqui
aqui 05.06.2024 aktualisiert um 13:14:50 Uhr
Goto Top
aber ich bekomme immer nur Time-Out Fehler auf dem Android-Handy
Oder kann es sein das du schlicht und einfach nur die falschen Protokollports für die verwendeten VPN Protokolle weitergeleitet hast?!
Alles was in solchen Kaskaden zum VPN Port Forwarding zu beachten ist findest du in diesem Tutorial:
VPN Port Forwarding in Router Kaskade
nurbobald
nurbobald 05.06.2024 um 19:18:04 Uhr
Goto Top
Danke für die vielen Hinweise. Ich bin jetzt eine Runde weiter und kann eine Verbindung aufbauen.

An einem weit, weit entfernten Ort hat mein ISP einen Glasfaserabschluss (ONT) an die Wand geschraubt. Daran hängt der erste LigoDLB. Dieser ist im Router-Modus konfiguriert und übernimmt PPPoE Einwahl und macht NAT. Das zweite Gerät hängt am ER605 und ist als Bridge konfiguriert. Mein Versuch, beide Geräte in den Bridge-Modus zu versetzen und damit zu einem sehr langen Patch-Kabel zu machen, ist leider gescheitert. Die PPPoE-Einwahl hat über diese Bridge nicht geklappt. Der ER605 meldet: "Sending PADI times out". Deshalb muss ich den ersten LigoDLB als Router betreiben und ihn die PPPoE-Einwahl machen lassen. Ich diskutiere das nochmal im LigoWave Forum/support.

Der ER605 hat 4 hardware-Ports. Eines davon ist als WAN konfiguriert, daran hängt der zweite LigoDLB (192.168.0.2):
Verbindung: Statisch
IP-Adresse. 192.168.0.2
Maske: 255.255.255.0
DNS: 192.168.0.1

Ich habe also die Konfigurationsadresse vom 2. LigoDLB als statische WAN-IP im ER605 eingestellt.

Der ER605 hat 5 interne Netze konfiguriert: 192.168.1.xxx bis 192.168.4.xxx. und 192.168.27.xxx für VPN. Die 192.168.1.xxx ist für die Netzwerk-Hardware und darin sind Router ER605 (192.168.1.1), Switche, APs und der Omada-SDN-Controller.

Mit Sicherheit kann ich von Aussen auf den Web-Server 192.168.2.9. Die HTTP Anfrage geht durch die DMZ des Ligo-DLB und durch das Port-Forwarding des ER605 durch.

Mit diesen Einstellungen kann ich nun auch den VPN Server im ER605 erreichen.

Name: MeinOpenVPN
Status: [X] Aktivieren
Zweck: [ ] Site-to-site VPN [X] Endgerät-to-site VPN
VPN-Typ: VPN-Server OpenVPN
Konto-Passwort: [X] aktivieren
Tunnelmodus: [ ]geteilt [X] vollständig
Protokoll: [X] TCP [ ] UDP
Serviceport: 1194
Authentifizierungsmodus:[ ] LDAP [X] Lokal
WAN: WAN
IP-Pool:192.168.27.10/28
Haupt-DNS:
Zweiter-DNS:

Ich hatte das Protokoll vorher auf UDP eingestellt, dass hat nicht geklappt. Ich kann die OpenVPN Verbindung aufbauen, sehe die Verbindung im Roúter. Das Mobilgerät bekommt z.B. die Adresse 192.168.27.10. Leider erreiche ich aber die anderen Subnetze nicht. Auch nicht, wenn ich den IP-Pool auf ein paar Adressen aus einem dieser Subnetze einstelle.

Für Ideen bleibe ich also dankbar. Manchmal hilft ja auch gutes Zureden face-wink

Gruß, Nurbo
aqui
aqui 06.06.2024 aktualisiert um 09:44:58 Uhr
Goto Top
Ich hatte das Protokoll vorher auf UDP eingestellt
So wie es generell und auch von OpenVPN dringend empfohlen wird! TCP schafft nur Probleme durch den größeren Header Overhead und den damit einhergehenden MTU Problemen. Es macht die so oder so schon grundsätzlich miese Performance von OpenVPN nochmals deutlich schlechter.
Wenn, sollte man immer UDP nutzen! Dann ist das natürlich entsprechend auch auf der Client Seite auf UDP umzustellen, das sollte klar sein!
Leider erreiche ich aber die anderen Subnetze nicht.
Das zeugt davon das etwas mit dem Routing am VPN Client nicht stimmt!
Wenn der VPN Tunnel aktiv ist am Client gib dort einmal ein route print ein (Winblows) und sieh dir die Routing Tabelle des VPN Clients bei aktivem Tunnel an!
Kannst du dort deine Zielnetze .1.0/24 und .4.0/24 sehen oder alternativ eine Default Route die auf die OpenVPN Server IP zeigt??
Ist alles korrekt konfiguriert müssten die IP Zielnetze an das OVPN Tunnelinterface geroutet werden.

Alle Details die bei einer OpenVPN Konfig und dem Client Setup wichtig sind beschreibt dir mit allen Details das hiesige OpenVPN Tutorial:
Merkzettel: VPN Installation mit OpenVPN
Bitte genau lesen und umsetzen. Diesbezüglich wäre es sehr hilfreich deine OVPN Client Konfig Datei zu kennen.
Manchmal hilft ja auch gutes Zureden
Vergiss das. Weisst du selber das das naiver Unsinn ist in der IT!
nurbobald
Lösung nurbobald 06.06.2024 um 10:53:52 Uhr
Goto Top
Hallo alle,
vielen Dank für die Hilfe. Das Problem ist gelöst. Ich habe die VPN ports in router 1 weitergeleitet. (In meinem Fall: eine DMZ zum zweiten router). Dort lauscht der VPN-Server auf dem WAN-Port. Es müssen keine Portweiterleitungen auf router 2 eingerichtet werden.

OpenVPN funktioniert bei mir nur mit Protokoll TCP. Mit dem Windows-Client funktioniert alles problemlos. Android und iOS hatten mit dem OpenVPN-Server des TP-Link ER605 (HW 2.0, FW 2.2.4, Omada-Controller version 5.13.30.20) Probleme, bis ich diesen workaround eingestellt habe:

TP-Link Forum: community.tp-link.com/en/business/forum/topic/653224

Kurzform:
Die Profildatei.ovpn mit Texteditor öffnen und die Zeile
comp-lzo no
ersetzen durch
comp-lzo

Im TP-Link-Forum ist eine Diskussion um die Sicherheit des workaround entbrannt, aber damit laufen die Android und iOS clients zu 90%. Leider gibt es immernoch einen Server, den nur der Windows-Client erreicht. Das alles sind jetzt aber wahrscheinlich VPN-Probleme die thematisch nicht mehr in diesen Thread gehören. Vielen Dank nochmals, Gruß, Nurbo
aqui
aqui 06.06.2024 aktualisiert um 12:30:05 Uhr
Goto Top
ersetzen durch comp-lzo
Keine gute Idee, dann damit macht man den Client und Server angreifbar über eine VORACLE Attacke. Gerade comp-lzo ist davon seit Langem akut betroffen!
https://community.openvpn.net/openvpn/wiki/VORACLE
Deshalb gilt schon seit Jahren als verantwortungsvoller Netzwerk Admin IMMER auf die lzo Compression zu verzichten! Es bringt so oder so rein gar nichts weil das Gros der Daten eh vorkomprimiert ist.
https://community.openvpn.net/openvpn/wiki/Compression