markuswo
Goto Top

L2TP (ipsec) Probleme von Client zu Server durch Linux-Gateway

Hallo zusammen,

folgende Konstellation:

zeichnung1

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

Content-Key: 344193

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

Ausgedruckt am: 29.03.2024 um 15:03 Uhr

Mitglied: LordGurke
Lösung LordGurke 22.07.2017 um 14:52:36 Uhr
Goto Top
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
tcpdump -i XXX -nn "host IPADRESSEDESVPNSERVERS"  
(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.
Mitglied: markuswo
markuswo 22.07.2017 um 16:12:41 Uhr
Goto Top
Am Draytek ist alles an VPN deaktiviert.
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.
Mitglied: LordGurke
Lösung LordGurke 22.07.2017 aktualisiert um 16:18:22 Uhr
Goto Top
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...
Mitglied: markuswo
markuswo 22.07.2017 um 17:06:20 Uhr
Goto Top
Lösung: ?
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
Mitglied: 108012
108012 23.07.2017 um 02:35:35 Uhr
Goto Top
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
Mitglied: markuswo
markuswo 23.07.2017 um 17:15:33 Uhr
Goto Top
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.