6
L2TP (ipsec) Probleme von Client zu Server durch Linux-Gateway
Hallo zusammen,
folgende Konstellation:
Das Problem ist ich komme von den Clients seit zwei Monaten nicht mehr an den VPN Server. Die einzige Änderung welche ich durchgeführt habe waren updates (ganz normal apt-get) am Gateway und arbeiten an iptables, welche ich aber Rückgängig gemacht habe, aktuell ist iptables komplett deinstalliert zu Testzwecken.
Windows liefert mir:
Fehler "789": Der L2TP-Verbindungsversuch ist fehlgeschlagen, da ein Verarbeitungsfehler während der ersten Sicherheitsaushandlung mit dem Remotecomputer aufgetreten ist.
Alles andere funktioniert, der Windows 10 Rechner hat keine 3rd party firewall nur windows defender, der 8.1 läuft über GDATA Business.
Das VPN Zertifikat habe ich schon neu beantragt, beim Zielort ist alles in Ordnung. Auf dem Zielserver habe ich keine Zugriff.
Ich habe keine Ahnung wo ich nachforschen muss, es lief davor 2 Jahre tadellos.
Gruß und Dank,
Markus
folgende Konstellation:
Das Problem ist ich komme von den Clients seit zwei Monaten nicht mehr an den VPN Server. Die einzige Änderung welche ich durchgeführt habe waren updates (ganz normal apt-get) am Gateway und arbeiten an iptables, welche ich aber Rückgängig gemacht habe, aktuell ist iptables komplett deinstalliert zu Testzwecken.
Windows liefert mir:
Fehler "789": Der L2TP-Verbindungsversuch ist fehlgeschlagen, da ein Verarbeitungsfehler während der ersten Sicherheitsaushandlung mit dem Remotecomputer aufgetreten ist.
Alles andere funktioniert, der Windows 10 Rechner hat keine 3rd party firewall nur windows defender, der 8.1 läuft über GDATA Business.
Das VPN Zertifikat habe ich schon neu beantragt, beim Zielort ist alles in Ordnung. Auf dem Zielserver habe ich keine Zugriff.
Ich habe keine Ahnung wo ich nachforschen muss, es lief davor 2 Jahre tadellos.
Gruß und Dank,
Markus
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: 344193
Url: https://administrator.de/contentid/344193
Ausgedruckt am: 25.11.2024 um 06:11 Uhr
6 Kommentare
Neuester Kommentar
Ist am Draytek irgendeine Form von VPN-Server aktiviert? Wenn der selber VPN-Server ist, kann er möglicherweise die IKE-Pakete von außen möglicherweise nicht mehr nach innen forwarden und verschluckt sie.
Teste mal parallel auf dem Linux-Gateway mit
(XXX) durch den Namen des Interfaces ersetzen, welches mit dem Draytek verbunden ist, ob du eingehenden Traffic vom VPN-Server erhältst.
Wenn du keinen Traffic siehst, ist vermutlich der Draytek schuld, wenn du eingehende IKE-Pakete siehst, musst du dich mit tcpdump auf die interne Schnittstelle Richtung Switch verlagern und gucken, ob da was ankommt. So kannst du dann die Firewall oder andere Linux-Dienste ausschließen.
Teste mal parallel auf dem Linux-Gateway mit
tcpdump -i XXX -nn "host IPADRESSEDESVPNSERVERS" Wenn du keinen Traffic siehst, ist vermutlich der Draytek schuld, wenn du eingehende IKE-Pakete siehst, musst du dich mit tcpdump auf die interne Schnittstelle Richtung Switch verlagern und gucken, ob da was ankommt. So kannst du dann die Firewall oder andere Linux-Dienste ausschließen.
Am Draytek ist alles an VPN deaktiviert.
Die tcpdump ausgabe sieht so aus, ich hab die IP vom VPN Server mit "VPN" ersetzt:
Führe ich tcpdump mit -i intern aus dann ist die Ausgabe identisch.
Die tcpdump ausgabe sieht so aus, ich hab die IP vom VPN Server mit "VPN" ersetzt:
root@domdns:~# tcpdump -i extern -nn "host VPN"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on extern, link-type EN10MB (Ethernet), capture size 262144 bytes
15:46:07.052039 IP 10.10.1.223.500 > VPN.500: isakmp: phase 1 I ident
15:46:07.088000 IP VPN > 10.10.1.223.500: isakmp: phase 1 R ident
15:46:07.096594 IP 10.10.1.223.500 > VPN.500: isakmp: phase 1 I ident
15:46:07.134423 IP VPN.500 > 10.10.1.223.500: isakmp: phase 1 R ident
15:46:07.151414 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:07.251827 IP VPN.4500 > 10.10.1.223.4500: NONESP-encap: isakmp: phase 2/others R inf[E]
15:46:08.150601 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:09.150369 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:12.150425 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:15.150599 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:18.150370 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:21.150358 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:21.681286 IP VPN.4500 > 10.10.1.223.4500: NONESP-encap: isakmp: phase 2/others R inf[E]
15:46:24.150456 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:27.150416 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:30.150402 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:33.150449 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:36.150560 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:39.150737 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:42.150408 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:45.150693 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:48.150540 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:51.150466 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:54.152183 IP 10.10.1.223.500 > VPN.500: isakmp: phase 1 I ident
15:46:54.187846 IP VPN.500 > 10.10.1.223.500: isakmp: phase 1 R ident
15:46:54.197734 IP 10.10.1.223.500 > VPN.500: isakmp: phase 1 I ident
15:46:54.234959 IP VPN.500 > 10.10.1.223.500: isakmp: phase 1 R ident
15:46:54.255927 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:54.356896 IP VPN.4500 > 10.10.1.223.4500: NONESP-encap: isakmp: phase 2/others R inf[E]
15:46:55.244158 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:56.244180 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:46:59.244307 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:47:02.244155 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:47:05.321291 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:47:08.324417 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]
15:47:08.857374 IP VPN.4500 > 10.10.1.223.4500: NONESP-encap: isakmp: phase 2/others R inf[E]
15:47:11.324386 IP 10.10.1.223.4500 > VPN.4500: NONESP-encap: isakmp: phase 1 I ident[E]Führe ich tcpdump mit -i intern aus dann ist die Ausgabe identisch.
Dann scheint zumindest nicht die Firewall des Linux-Gateways verantwortlich zu sein - denn wenn du Traffic in beide Richtungen auf der internen Schnittstelle siehst, wird dieser ja ganz offensichtlich geforwarded.
Dein Cisco... Arbeitet der ebenfalls als Router/Firewall oder ist der einfach nur als L2-Switch konfiguriert?
Eventuell kannst du einmal mit Wireshark auf dem Client prüfen, ob der identische Pakete sieht wie dein Linux-Gateway?
Am Besten auf Client und Gateway parallel beobachten ob da Pakete verschwinden...
Dein Cisco... Arbeitet der ebenfalls als Router/Firewall oder ist der einfach nur als L2-Switch konfiguriert?
Eventuell kannst du einmal mit Wireshark auf dem Client prüfen, ob der identische Pakete sieht wie dein Linux-Gateway?
Am Besten auf Client und Gateway parallel beobachten ob da Pakete verschwinden...
Lösung: ?
Denkfehler: Wenn ich iptables deinstalliere um Fehler auszuschließen, kann ich natürlich nicht wirklich NAT-T nutzen, oder?
Also nur so kann ich mir das erklären.
Die genaue Ursache, weiß ich jetzt nicht, da ich ja von heute auf morgen mehrere Sachen angepasst habe, hoffentlich hat sich das jetzt erledigt.
Danke für die Hinweise LordGurke, zumindest habe ich mich jetzt wieder erinnert mehr mit Wireshark zu arbeiten :D
iptables -t nat -A POSTROUTING -o extern -j MASQUERADE Denkfehler: Wenn ich iptables deinstalliere um Fehler auszuschließen, kann ich natürlich nicht wirklich NAT-T nutzen, oder?
Also nur so kann ich mir das erklären.
Die genaue Ursache, weiß ich jetzt nicht, da ich ja von heute auf morgen mehrere Sachen angepasst habe, hoffentlich hat sich das jetzt erledigt.
Danke für die Hinweise LordGurke, zumindest habe ich mich jetzt wieder erinnert mehr mit Wireshark zu arbeiten :D
Ein "Hallo",
wenn auch nachträglich dazu.
Setz doch einfach mal CentOS auf und installiere Dir dann SoftEtherVPN als Server Version und den VPN Server
stellst Du dann in die DMZ rein und gut ist es.
Gruß
Dobby
wenn auch nachträglich dazu.
Setz doch einfach mal CentOS auf und installiere Dir dann SoftEtherVPN als Server Version und den VPN Server
stellst Du dann in die DMZ rein und gut ist es.
Gruß
Dobby
Hallo Dobby,
ich hab auf den VPN Server keinen Einfluss, der wird mir vom entsprechenden Anbieter so vorgegeben.
Mein eigener VPN Server, mit openVPN funktioniert einwandfrei ;)
Das Problem war, warum auch immer, eine fehlende Konfiguration am Gateway der dann nicht richtig "NAT-ten" konnte.
ich hab auf den VPN Server keinen Einfluss, der wird mir vom entsprechenden Anbieter so vorgegeben.
Mein eigener VPN Server, mit openVPN funktioniert einwandfrei ;)
Das Problem war, warum auch immer, eine fehlende Konfiguration am Gateway der dann nicht richtig "NAT-ten" konnte.
