VPN (IPSEC/ESP) bricht ab

[assachs]

Hallo,

ich versuche über Mobilfunk eine VPN-Verbindung zu verwenden (IPSEC, ESP). Die Verbindung wird erfolgreich aufgebaut und bricht nach genau 12 Minuten ab (nach kurzer Zeit wird sie automatisch neu aufgebaut und geht dann auch wieder).

Die Vodafone-Sim-Karte ist in einem LTE-Router und dieser ist per Kabel mit einem Laptop verbunden auf dem der VPN-CLient läuft. Verwende ich statt der Vodafon-Sim-Karte eine Telekom- oder O2-Simkarte geht es ohne Probleme.

Bei allen drei Providern erhalte ich eine private IPv4-Adresse. Ich gehe deshalb nicht davon aus, dass es ein grundsätzliches Problem mit NAT und dem VPN-Provider ist.

Traffic sehe ich auf UDP 4500.

Auf Port 500 habe ich keinen Traffic gesehen (bei keinem Provider; bin mir aber nicht 100% sicher).

Könnt ihr (@Vodafone) da noch etwas einstellen?

Grüße

Andreas

[reneromann]

Das Problem liegt eher am VPN-Server...

Denn wie lange die öffentliche IP-Adresse für dich gleich bleibt, steht nicht fest -- wenn aber der VPN-Server genau dies prüft, hast du eben genau diese Probleme.

[assachs]

Daran hatte ich auch schon gedacht. Leider habe ich keinen Zugriff am VPN-Server.

Über die Verbindung gingen auf jeden Fall die ganze Zeit Daten, so dass es schon noch in einer NAT-Session drin sein sollte. Außer sie hat eine maximale Zeit auch wenn sie nicht idle ist.

Es könnte sein, dass nach 12 Minuten der Key neu ausgetauscht werden soll. Da bin ich mir aber nicht sicher.

Da ich weder am Client noch am Server irgendwas einstellen kann, habe ich mit einer anderen VPN-Verbindung getestet. Leider mit anderer Software, aber auch IPSEC mit ESP. Blöderweiße konnte ich hier aber das Problem auch nicht nachstellen. Ich konnte hier aber auch keinen erneuten Schlüsselaustausch erzwingen. Ich muss mir erstmal einen anderen Client mit mehr Einstellmöglichkeiten besorgen. Da ich aber hiervon die Logfiles noch hatte:

die IP (und auch der Port) ist für 45 Minuten gleich geblieben. Länger ging mein Test nicht.

Aber vielen Dank für die Idee. Da kommt man dann doch noch auf andere Ideen, was man noch alles überprüfen kann 😉

[assachs]

Hallo,
ich habe weitere Untersuchungen gemacht:

Es scheint kein Problem mit dem IPSEC-Tunnel zu sein, sondern der VPN-Client baut parallel noch eine HTTPS-Verbindung als Control-Channel auf. Die Verbidung wird mit http-Keepalive aufgebaut und offen gehalten. Alle 2 Minuten wird ein TCP-Keepalive gesendet. Nach 12 Minuten wird die Verbindung zurück gesetzt (ich vermute von Vodafone).

Das folgende habe ich unabhängig vom VPN getestet.

Port 80/http:
Wenn über eine Verbindung keine Daten mehr gehen wird sie trotz längerem http-Keepalive nach ca. 30 Sekunden geschlossen.
Ich habe einen Client gefunden, bei dem ich TCP-Keepalives senden konnte. Das Schließen der Verbindung ist unabhängig davon. D.h. die TCP-Keepalives führen nicht zum Zurücksetzen des Timers und werden aus meiner Sicht ignoriert.
Wenn ich innerhalb der 30 Sekunden Daten übertrage, dann bleibt die Verbindung offen.

Port 443/https:
Ich habe leider keinen Client gefunden der TCP-Keepalive-Pakete senden kann. D.h. ich konnte nur mit komplett unbenutzten Verbindungen testen.
Nach 8 Minuten konnte ich einen neuen Request absetzen, die Verbindung war noch offen.
Nach 13 Minuten konnte ich keinen neuen Request absetzen, die Verbindung war zu.
Wenn ich regelmäßig Daten übertrage, dann wird die Verbindung offen gehalten.
Ich vermute, dass hier die TCP-Keepalives wie auch bei Port 80 ignoriert werden.

Ich vermute nun, dass dadurch der Control-Channel vom VPN-Client abbricht und er danach den Tunnel beendet und neu aufbaut.

@Vodafone:
könnt ihr bestätigen, dass TCP-Keepalives ignoriert werden?
wie sind die Idle-Timeouts für Port 80 und 443? passt das zu meinen Beobachtungen?
besteht die Möglichkeit, dass hier für mich ein anderes "Profil" oder ähnliches hinterlegt wird?

Grüße
Andreas

[reneromann]

Wenn du per DualStack-Lite unterwegs bist, wird da für dich kein anderes Profil o.ä. hinterlegt werden - da hast du schlichtweg Pech gehabt. Und TCP-Keepalive-Pakete müssen nicht zwingend beachtet werden, da sie nur "optional" sind. Es kann also durchaus sein, dass das CGNAT-Gateway von Vodafone die TCP-Keepalives ignoriert, wenn keine Daten über die Verbindung fließen.

Das wäre aber dann auch prinzipiell ein Designfehler in der VPN-Implementierung, über eine offenzuhaltende TCP-Verbindung, über die jedoch keine Daten fließen, die Prüfung zu machen, ob der Tunnel tot ist.

Wieder ein Grund mehr, der mich in meiner Meinung bestätigt, dass IPSec für Clientverbindungen völlige Grütze ist.

[assachs]

Hallo reneromann,

>Wenn du per DualStack-Lite unterwegs bist, wird da für dich kein anderes Profil o.ä. hinterlegt werden -

>da hast du schlichtweg Pech gehabt. Und TCP-Keepalive-Pakete müssen nicht zwingend beachtet werden, da sie

>nur "optional" sind. Es kann also durchaus sein, dass das CGNAT-Gateway von Vodafone die TCP-Keepalives

>ignoriert, wenn keine Daten über die Verbindung fließen.

Das habe ich auch schon befürchtet. Ich hatte nur einen alten Thread mit IPSEC-Problemen gefunden, bei dem ein Mitarbeiter gesagt hat, dass er was umstellen wird. Leider stand nicht dabei was umgestellt wird und auch nicht, ob es was geholfen hat. Das war so meine letzte Hoffnung. Richtig geglaubt hab ich daran aber nicht.

>Das wäre aber dann auch prinzipiell ein Designfehler in der VPN-Implementierung, über eine offenzuhaltende

>TCP-Verbindung, über die jedoch keine Daten fließen, die Prüfung zu machen, ob der Tunnel tot ist.

Da sagst du was. Mir kommt das auch sehr komisch vor. Leider bin ich bei diesem VPN nur Anwender und kann weder auf Server-Seite noch Client-Seite irgendwas ändern. Keine Ahnung, ob auch eine andere Form des Keepalives eingestellt werden könnte.

>Wieder ein Grund mehr, der mich in meiner Meinung bestätigt, dass IPSec für Clientverbindungen völlige

>Grütze ist.

Was ich noch rausgefunden habe: wenn ich Port UDP 4500 blocke, dann macht der VPN-Client einen Fallback auf ein SSL-VPN über TCP443

Zumindest war es ganz interessent die Verbindungen zu analysieren. 😉

Danke fürs Mitüberlegen