13
TP-Link TL-ER6120 L2TP over IPsec hinter Fritzbox
Hallo zusammen,
Ich habe eine Fritzbox 7362 welche die Internetverbindung herstellt(TP-Link Router unterstützt nicht VDSL) und als DECT Basis fungiert.
An der FritzBOX(192.168.5.1/24) ist der TL-ER6120 über den WAN Port (als Static IP konfiguriert 192.168.5.2) angeschlossen. Die FritzBox ist im Internet über DDNS erreichbar.
Der TP-Link stellt sein eigenes Netz (192.168.0.0/24) zur Verfügung und dahin möchte ich eine VPN Verbindung über L2TP Ipsec realisieren.
Bis jetzt ist mir aber leider nur eine PPTP Verbindung gelungen. (Portweiterleitung TCP 1723 an den WAN Anschluss des TP-Link(192.168.5.2))
Folgende Konfigurationen habe ich bereits vorgenommen:
FritzBox Portweiterleitungen an 192.168.5.2(TP-Link Router):
UDP 1701 (L2TP)
UDP 4500 (IPsec)
UDP 500 (IKE)
Auch habe ich es schon probiert alles freizugeben (Exposed Host) aber das hat ebenfalls keine Wirkung gezeigt.
Konfigurationen auf dem TP-Link:
1. IP-Adresspool für L2TP angelegt
2. Als Mode "Server" und Tunnel "Client to LAN" + PSK und Benutzer
3.IPsec in den Generalsettings auf "Enabled" gesetzt.
Vom Intenet aus wenn ich nun über den DDNS Dienst den VPN Router ansprechen will funktioniert der Tunnelaufbau nicht.
Vom Netz der FritzBox aus kann ich den Tunnel wenn ich den TP-Link über die 192.168.5.2 anspreche aufbauen.
Woran kann das liegen? muss ich noch irgendwas an der FritzBox einrichten? VPN Passthrough? Wenn ja wie?
Bin für jede Hilfe dankbar
Gruß gigi
Ich habe eine Fritzbox 7362 welche die Internetverbindung herstellt(TP-Link Router unterstützt nicht VDSL) und als DECT Basis fungiert.
An der FritzBOX(192.168.5.1/24) ist der TL-ER6120 über den WAN Port (als Static IP konfiguriert 192.168.5.2) angeschlossen. Die FritzBox ist im Internet über DDNS erreichbar.
Der TP-Link stellt sein eigenes Netz (192.168.0.0/24) zur Verfügung und dahin möchte ich eine VPN Verbindung über L2TP Ipsec realisieren.
Bis jetzt ist mir aber leider nur eine PPTP Verbindung gelungen. (Portweiterleitung TCP 1723 an den WAN Anschluss des TP-Link(192.168.5.2))
Folgende Konfigurationen habe ich bereits vorgenommen:
FritzBox Portweiterleitungen an 192.168.5.2(TP-Link Router):
UDP 1701 (L2TP)
UDP 4500 (IPsec)
UDP 500 (IKE)
Auch habe ich es schon probiert alles freizugeben (Exposed Host) aber das hat ebenfalls keine Wirkung gezeigt.
Konfigurationen auf dem TP-Link:
1. IP-Adresspool für L2TP angelegt
2. Als Mode "Server" und Tunnel "Client to LAN" + PSK und Benutzer
3.IPsec in den Generalsettings auf "Enabled" gesetzt.
Vom Intenet aus wenn ich nun über den DDNS Dienst den VPN Router ansprechen will funktioniert der Tunnelaufbau nicht.
Vom Netz der FritzBox aus kann ich den Tunnel wenn ich den TP-Link über die 192.168.5.2 anspreche aufbauen.
Woran kann das liegen? muss ich noch irgendwas an der FritzBox einrichten? VPN Passthrough? Wenn ja wie?
Bin für jede Hilfe dankbar
Gruß gigi
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: 255864
Url: https://administrator.de/contentid/255864
Ausgedruckt am: 20.11.2024 um 03:11 Uhr
13 Kommentare
Neuester Kommentar
Moin,
dir fehlt in der Fritte die Weiterleitung des ESP-Protokolls(50). Wichtig: damit ist kein Port gemeint sondern das Protokoll mit der Nummer 50 !
Grundlagen zu IPSec VPNs werden hier ausführlich behandelt:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Außerdem kann es eventuell nötig sein das du in Windows eine Einstellung in der Registry setzen musst, wenn du den Windows-eigenen VPN Client benutzt und das VPN einen NAT-Router überwinden muss.
VPN Verbindung L2TP IPSec
Gruß jodel32
dir fehlt in der Fritte die Weiterleitung des ESP-Protokolls(50). Wichtig: damit ist kein Port gemeint sondern das Protokoll mit der Nummer 50 !
Grundlagen zu IPSec VPNs werden hier ausführlich behandelt:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Außerdem kann es eventuell nötig sein das du in Windows eine Einstellung in der Registry setzen musst, wenn du den Windows-eigenen VPN Client benutzt und das VPN einen NAT-Router überwinden muss.
VPN Verbindung L2TP IPSec
Gruß jodel32
Ok vielen Dank für die Antwort. und wie stelle ich das an??
na genau wie eine Portweiterleitung, anstatt TCP oder UDP wählst du stattdessen als Protokoll ESP aus und leitest dieses an die IP des TP-Link ...
Da hatte ich wohl tomaten auf den augen
Hab nun beides gemacht. Registry editiert und und esp Forwarding eingestellt. Jedoch kann die Verbindung noch immer nicht hergestellt werden noch eine idee?
Hab nun beides gemacht. Registry editiert und und esp Forwarding eingestellt. Jedoch kann die Verbindung noch immer nicht hergestellt werden noch eine idee?Jedoch kann die Verbindung noch immer nicht hergestellt werden noch eine idee?
Fehlermeldung des Clients ???Checke die eingestellten Phase 1 und Phase 2 Verschlüsselungsprotokolle für den IPSec-Tunnel sowohl auf dem TP Link als auch in den Firewall-Eigenschaften des Clientrechners. Dann natürlich noch die Firewall des TP-Link, die du am besten für deine Tests erst mal ausschaltest, dort müssen die entsprechenden Ports und Protokolle ebenfalls geöffnet sein.
Ansonsten häng dich mit Wireshark in den Netzwerktraffic, oder zeichne diesen mit der Fritte auf, dann findet sich das Problem ruckzuck
Gruß jodel
Jedoch kann die Verbindung noch immer nicht hergestellt werdenface-sad noch eine idee?
Ja, das war zu erwarten. Die FB supportet ja selber IPsec VPNs. Folglich "hört" und antwortet sie natürlich selber auf IPsec Pakete und ignoriert das Port Forwarding.Du musst auf der FB also zuallererst das VPN global deaktivieren, damit sie nicht immer denkt es ist für sie. Erst dann kann sie auch die L2TP Pakete an den TP-Link forwarden !
Grundlagen dazu findest du auch hier:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Zitat von @aqui:
> Jedoch kann die Verbindung noch immer nicht hergestellt werdenface-sad noch eine idee?
Ja, das war zu erwarten. Die FB supportet ja selber IPsec VPNs. Folglich "hört" und antwortet sie natürlich
selber auf IPsec Pakete und ignoriert das Port Forwarding.
Du musst auf der FB also zuallererst das VPN global deaktivieren, damit sie nicht immer denkt es ist für sie.
Wenn in der Fritte die VPN-Ports sowie das Protokoll weitergeleitet werden deaktiviert die Fritte Ihr eigenes VPN von selbst > Jedoch kann die Verbindung noch immer nicht hergestellt werdenface-sad noch eine idee?
Ja, das war zu erwarten. Die FB supportet ja selber IPsec VPNs. Folglich "hört" und antwortet sie natürlich
selber auf IPsec Pakete und ignoriert das Port Forwarding.
Du musst auf der FB also zuallererst das VPN global deaktivieren, damit sie nicht immer denkt es ist für sie.
bzw. man sollte natürlich sicherstellen das keine VPN-Profile auf der Fritte aktiviert sind.Gruß jodel32
Das lässt sich mit einem Wireshark Sniffer ja dann auch in Sekundenschnelle verifizieren ob diese 3 Protokolle von der FB dann an ihr LAN Interface und damit an den WAN Port des kaskadierten TP-Links weitergeleitet werden !
http://avm.de/nc/service/fritzbox/fritzbox-7390/wissensdatenbank/public ...
Passthrough bedeutet aber das es schon eine outbound VPN Verbindung geben muss ! Das ist bei dir aber NICHT der Fall da der VPN Aufbau inbound durchgereicht werden muss von der FB.
Fraglich ob dafür einfachs Port Forwarding reicht die eigenen IPsec Funktion damit zu deaktivieren.... Versuch macht bekanntlch klug und der Wireshark zeigt dir schnell ob das Forwarding auf der FB wirklich klappt !
http://avm.de/nc/service/fritzbox/fritzbox-7390/wissensdatenbank/public ...
Passthrough bedeutet aber das es schon eine outbound VPN Verbindung geben muss ! Das ist bei dir aber NICHT der Fall da der VPN Aufbau inbound durchgereicht werden muss von der FB.
Fraglich ob dafür einfachs Port Forwarding reicht die eigenen IPsec Funktion damit zu deaktivieren.... Versuch macht bekanntlch klug und der Wireshark zeigt dir schnell ob das Forwarding auf der FB wirklich klappt !
Es erscheint folgende Fehlermeldung mit Windows Boardmitteln:
"Fehler789: Verbindungsversuch fehlgeschlagen, da ein Verarbeitungsfehler während der ersten Sicherheitsaushandlung mit dem Remotecomputer aufgetreten ist."
Habe nun mit der Fritzbox den Eth0 Port aufgezeichnet(Port an dem der TP-Link hängt)
Jedoch kann ich nicht allzuviel mit dem Ergebnis anfangen....
Ich habe es nach der IP sortiert mit der ich versuche in das LAN rein zu kommen. (Einmal als Quelle und einmal als Ziel)
Quelle
Ziel
Das einzige was mir aufgefallen ist. ESP rein aber nicht raus....
"Fehler789: Verbindungsversuch fehlgeschlagen, da ein Verarbeitungsfehler während der ersten Sicherheitsaushandlung mit dem Remotecomputer aufgetreten ist."
Habe nun mit der Fritzbox den Eth0 Port aufgezeichnet(Port an dem der TP-Link hängt)
Jedoch kann ich nicht allzuviel mit dem Ergebnis anfangen....
Ich habe es nach der IP sortiert mit der ich versuche in das LAN rein zu kommen. (Einmal als Quelle und einmal als Ziel)
Quelle
Ziel
Das einzige was mir aufgefallen ist. ESP rein aber nicht raus....
Fraglich ob dafür einfachs Port Forwarding reicht die eigenen IPsec Funktion damit zu deaktivieren....
geht problemlos, würde ich ja nicht behaupten wenn ich's hier nicht laufen hätte Es erscheint folgende Fehlermeldung mit Windows Boardmitteln:
"Fehler789: Verbindungsversuch fehlgeschlagen, da ein Verarbeitungsfehler während der ersten Sicherheitsaushandlung mit dem Remotecomputer aufgetreten ist."
Wie vermutet ein Problem beim IKE Austausch (Phase 1)."Fehler789: Verbindungsversuch fehlgeschlagen, da ein Verarbeitungsfehler während der ersten Sicherheitsaushandlung mit dem Remotecomputer aufgetreten ist."
Laut deinem Log kommen die Pakete durch. Dann wirst du die, wie schon angemerkt, eingestellten Verschlüsselungsarten auf TP-LInk und Clientseitig in der Firewall (IPSec Einstellungen) abgleichen müssen. Wenn hier was nicht passt, kommt keine Verbindung zustande weil sich die Gegenstellen auf keinen gemeinsames Protokoll einigen können.
http://www.windowsecurity.com/articles-tutorials/firewalls_and_VPN/Wind ...
Und die Firewall auf dem TP-Link bitte erst mal ausmachen ...
Steht aber auch alles in Aquis Tutorial was oben verlinkt ist.
Gruß jodel32
WO ist der erste Sniffer Trace gezogen worden ?? Am Client ??
Ist das der Fall machst du vermutlich einen gehörigen Denkfehler !
Als Absender ist dort die 89.x.x.x und als Ziel die 192.168.5.2. Ist der Client in einem öffentlichen Netz (UMTS etc.) kann man als Ziel niemals eine private 192er RFC 1918 IP Adresse angeben !!
Diese IP Adressen werden im Internet nicht geroutet und schmeisst der Provider sofort weg:
http://de.wikipedia.org/wiki/Private_IP-Adresse
Jedr netzwerker weiss das.
Für den Client ist immer die öffentliche IP Adresse deine Fritzbox das Ziel !!
Logisch, denn die IP ist ja weltweit erreichbar und dir Fritzbox "sieht" dann diese Pakete die an ihrer IP Adresse ankommen und forwardet sie dann gemäss der Regel an den Port im lokalen Netzwerk.
Idealerweise konfiguriert man eine DynDNS Adresse an der FB wenn man hier wechselnde IP Adressen am WAN / Internet Port der FB hat um zu einem festen Hostnamen den man im Client dann angeben kann immer die richtige Ziel IP zu erreichen.
Normal wechseln die IPs durch die tägliche Zwangstrennung der Provider.
Welche aktuelle Ziel IP du auf deiner FB hast kannst du sehen wenn du aus dem netz an der FB mal mit deinem Browser auf die Adresse http://www.wieistmeineip.de surfst. Alternativ geht auch http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
DAS ist das richtige Ziel für den Client.
Das Ergebnis kannst du auch sehen, denn die ESP Pakete des Clients müssten analog so auch am Ziel ankommen und wie du sihest ist da rein gar nichts... Klar duchr die oben geschilderte Problematik deiner völlig falschen Ziel IP am VPN Client !!
Ist das der Fall machst du vermutlich einen gehörigen Denkfehler !
Als Absender ist dort die 89.x.x.x und als Ziel die 192.168.5.2. Ist der Client in einem öffentlichen Netz (UMTS etc.) kann man als Ziel niemals eine private 192er RFC 1918 IP Adresse angeben !!
Diese IP Adressen werden im Internet nicht geroutet und schmeisst der Provider sofort weg:
http://de.wikipedia.org/wiki/Private_IP-Adresse
Jedr netzwerker weiss das.
Für den Client ist immer die öffentliche IP Adresse deine Fritzbox das Ziel !!
Logisch, denn die IP ist ja weltweit erreichbar und dir Fritzbox "sieht" dann diese Pakete die an ihrer IP Adresse ankommen und forwardet sie dann gemäss der Regel an den Port im lokalen Netzwerk.
Idealerweise konfiguriert man eine DynDNS Adresse an der FB wenn man hier wechselnde IP Adressen am WAN / Internet Port der FB hat um zu einem festen Hostnamen den man im Client dann angeben kann immer die richtige Ziel IP zu erreichen.
Normal wechseln die IPs durch die tägliche Zwangstrennung der Provider.
Welche aktuelle Ziel IP du auf deiner FB hast kannst du sehen wenn du aus dem netz an der FB mal mit deinem Browser auf die Adresse http://www.wieistmeineip.de surfst. Alternativ geht auch http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
DAS ist das richtige Ziel für den Client.
Das Ergebnis kannst du auch sehen, denn die ESP Pakete des Clients müssten analog so auch am Ziel ankommen und wie du sihest ist da rein gar nichts... Klar duchr die oben geschilderte Problematik deiner völlig falschen Ziel IP am VPN Client !!
Ist nicht am client aufgezeichnet. Sondern auch von der fritzbox. Die fb habe ich natürlich uber ddns angesprochen. Die private ip ist der tplink router wohin die fb die anfragen weiterleitet. Der soll dann die vpn verbindung aufbauen. Ich glaub ich werd das unterfangen erst mal auf eis legen. Aber vielen lieben dank an euch
OK, dann nehm ich alles zurück und behaupte das Gegenteil...
Das sieht dann aber gut aus und es werkelt wie es soll. ISAKMP (IKE) und ESP werden ja sauber auf den TP-Link geforwardet !!
Alles gut also....
Was sagt den das Syslog beim TP-Link bei eingehender IPsec Verbindung ??
Warum auf Eis legen ?? Das bekommt man ganz sicher zum Fliegen.
Das sieht dann aber gut aus und es werkelt wie es soll. ISAKMP (IKE) und ESP werden ja sauber auf den TP-Link geforwardet !!
Alles gut also....
Was sagt den das Syslog beim TP-Link bei eingehender IPsec Verbindung ??
Warum auf Eis legen ?? Das bekommt man ganz sicher zum Fliegen.
