8
Open-VPN IpV4 Transport bricht nach ca. 2 Min. ab
Hallo Zusammen,
ein Windows Clientsystem mit Open-VPN (Aktuelle Version) bricht nach Herstellung der Verbindung den Transport von Daten einfach ab, so dass nichts auf der Serverseite zu erreichen ist. Nach einem Neustart der VPN-Verbindung geht es dann wieder für 2 Min.
Getestet habe ich das ganze mit einem Dauer Ping -t auf einen Server ist Remotenetzwerk. Das blöse an der Fehlersuche ist , dass alle anderen Clients eine stabile Verbindung hinbekommen und diese läuft. Auch der Client, der mir jetzt Sorgen macht, lief bis vor Weihnachten noch völlig normal! Irgendwas muss sich geändert haben, aber was? Windows-Updates wurden nicht eingespielt.
Der einzige Unterschied zwischen den den verschienden Clientnetzwerken ist, dass das Problem Netzwerk ans Internet angebuden ist über einen DS-Lite-Tunnel mit IpV6 bei 1und1 angebuden ist. Das war vorher aber auch schon so.
Was mir gerade noch aufgefallen ist, ist dass immer wenn der Transport nach 2 Min. abbricht auch keine Verbindung zu keiner Webseite mehr möglich ist... seltsam, in der Konfig VPN habe ich den Gatway nicht vorgegeben:
Hat jemand eine Idee? wo ich ansetzen kann? Ich denke, das Problem ist auf jeden Fall Clientseitig zu suchen!
ein Windows Clientsystem mit Open-VPN (Aktuelle Version) bricht nach Herstellung der Verbindung den Transport von Daten einfach ab, so dass nichts auf der Serverseite zu erreichen ist. Nach einem Neustart der VPN-Verbindung geht es dann wieder für 2 Min.
Getestet habe ich das ganze mit einem Dauer Ping -t auf einen Server ist Remotenetzwerk. Das blöse an der Fehlersuche ist , dass alle anderen Clients eine stabile Verbindung hinbekommen und diese läuft. Auch der Client, der mir jetzt Sorgen macht, lief bis vor Weihnachten noch völlig normal! Irgendwas muss sich geändert haben, aber was? Windows-Updates wurden nicht eingespielt.
Der einzige Unterschied zwischen den den verschienden Clientnetzwerken ist, dass das Problem Netzwerk ans Internet angebuden ist über einen DS-Lite-Tunnel mit IpV6 bei 1und1 angebuden ist. Das war vorher aber auch schon so.
Was mir gerade noch aufgefallen ist, ist dass immer wenn der Transport nach 2 Min. abbricht auch keine Verbindung zu keiner Webseite mehr möglich ist... seltsam, in der Konfig VPN habe ich den Gatway nicht vorgegeben:
#OpenVPN Client conf
tls-client
client
nobind
dev tun
proto udp
tun-mtu 1400
remote test.de 8001
pkcs12 hansmustermann.p12
cipher AES-256-CBC
auth SHA512
verb 3
remote-cert-tls server
verify-x509-name test.de name
mssfix 0Hat jemand eine Idee? wo ich ansetzen kann? Ich denke, das Problem ist auf jeden Fall Clientseitig zu suchen!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 637389
Url: https://administrator.de/contentid/637389
Printed on: April 16, 2024 at 22:04 o'clock
8 Comments
Latest comment
Hallo,
Gruß,
Peter
Zitat von @zeroblue2005:
ein Windows Clientsystem mit Open-VPN (Aktuelle Version) bricht nach Herstellung der Verbindung den Transport von Daten einfach ab, so dass nichts auf der Serverseite zu erreichen ist. Nach einem Neustart der VPN-Verbindung geht es dann wieder für 2 Min.
Und der VPN Server ist ein was, wo usw.? Genug Lizenzen frei? Was steht in den LOGs beim Client und beim VPN Server? Zertifikat abgelaufen?ein Windows Clientsystem mit Open-VPN (Aktuelle Version) bricht nach Herstellung der Verbindung den Transport von Daten einfach ab, so dass nichts auf der Serverseite zu erreichen ist. Nach einem Neustart der VPN-Verbindung geht es dann wieder für 2 Min.
Gruß,
Peter
Hallo Peter,
sorry
ist ein IP-Fire aktuelle Version. Clientpaket habe ich schon zisch mal neu erstellt und Zertifikate auch. Logs sagen nichts aus, weder Server noch Client. Verbidnung steht ja auch (Ist grün) Nur nach zwei Minuten gehen keine Daten mehr durch von der Clientseite. Verbindung bleibt bestehen, lässt sich auch von Serverseite anpngen, kann den Client also erreichen, aber eben nicht von der Clientseite in Richtung Remotenetzwerk.
sorry
ist ein IP-Fire aktuelle Version. Clientpaket habe ich schon zisch mal neu erstellt und Zertifikate auch. Logs sagen nichts aus, weder Server noch Client. Verbidnung steht ja auch (Ist grün) Nur nach zwei Minuten gehen keine Daten mehr durch von der Clientseite. Verbindung bleibt bestehen, lässt sich auch von Serverseite anpngen, kann den Client also erreichen, aber eben nicht von der Clientseite in Richtung Remotenetzwerk.
Den Parameter -mssfix auf 0 zu setzen ist recht kontraproduktiv. Im Default steht der auf 1450 und gibt die max. Tunnel MTU an. 1450 ist ein realistischer Wert der so gut wie alles abdeckt. Du erzwingst diesen Wert auf 0, sprich jegliche Session bekommt gesagt das man 0 Bytes im Tunnel übertragen kann. Recht sinnfrei sowas...zumal wenn man die Tunnel MTU auch manuell setzt.
Den Parameter solltest du also dringenst löschen damit der Default Wert gilt. Tunnel MTU ebenso. Normal muss man an diesen Default Werten nicht fummeln. Gleiches gilt für evtl. Settings in der Server Konfig.
Den Rest erklärt das hiesige OpenVPN Tutorial:
Merkzettel: VPN Installation mit OpenVPN
Den Parameter solltest du also dringenst löschen damit der Default Wert gilt. Tunnel MTU ebenso. Normal muss man an diesen Default Werten nicht fummeln. Gleiches gilt für evtl. Settings in der Server Konfig.
Den Rest erklärt das hiesige OpenVPN Tutorial:
Merkzettel: VPN Installation mit OpenVPN
Hallo Zusammen,
ich habe das Problem gelöst, man will es nicht glauben, aber wenn ich der Client Konfig den Parameter: Redirect Gateway mit gebe, dann läuft es! Laut Tracert wird nun die VPN als Gateway benutzt. Ich vermute mal das es ein Probleme mit dem DS-Lite bzw. IpV6 bzw. Routen gab, auf der Clientseite. Danke euch trotzdem ür euere Ansätze.
ich habe das Problem gelöst, man will es nicht glauben, aber wenn ich der Client Konfig den Parameter: Redirect Gateway mit gebe, dann läuft es! Laut Tracert wird nun die VPN als Gateway benutzt. Ich vermute mal das es ein Probleme mit dem DS-Lite bzw. IpV6 bzw. Routen gab, auf der Clientseite. Danke euch trotzdem ür euere Ansätze.
Das ergibt keinen Sinn.
Ob du nun selektiv einzelne Routen oder alles (Defaultgateway) durch den Tunnel routest hat mit DS-Lite nichts zu tun.
Könnte es sein, dass du den Client nicht mit erhöhten Rechten gestartet hast und deshalb die Routen nicht ordentlich gesetzt wurden?
Ob du nun selektiv einzelne Routen oder alles (Defaultgateway) durch den Tunnel routest hat mit DS-Lite nichts zu tun.
Könnte es sein, dass du den Client nicht mit erhöhten Rechten gestartet hast und deshalb die Routen nicht ordentlich gesetzt wurden?
Client Konfig den Parameter: Redirect Gateway mit gebe, dann läuft es!
Du hast Recht ! Diesen Riesen Fauxpas in deiner Client Konfig haben wir glatt übersehen im Eifer des Gefechts !Ohne solche Routing Anweisung kannst du allein nur den OVPN Server erreichen bzw. das interne OpenVPN IP Netz. Alles andere ist dann unroutebar und damit unereichbar.
Kannst du auch am Client immer selber sehen wenn du dir bei aktivem VPN Client einmal mit route print dessen aktuelle Routing Tabelle ansiehst ! 😉
Ob du dir mit dem Gateway Redirect einen (Performance) Gefallen getan hast musst du selber beurteilen, denn damit routet man ALLES in den VPN Tunnel. Auch allen lokalen Internet Traffic !
Aus Performance Gründen immer so eine Sache, denn es belastet den Tunnel massiv und bei schacher Kryptografie Hardware geht der Durchsatz in die Knie. Wenn das gewollt ist um allen Verkehr des Clients zu schützen...OK.
Wenn nicht solltest du besser auf eine Split Tunneling Konfig gehen indem du mit push route... in der Server Konfig nur dediziert die remoten Netze in den VPN Tunnel routets die du erreichen willst. Dann geht auch einzig nur dieser Traffic in den Tunnel und alles andere bleibt lokal !
Das o.a. Tutorial erklärt das im Kapitel: "Konfiguration OpenVPN Server" im Detail:
Merkzettel: VPN Installation mit OpenVPN
Danke aqui,
das passt schon bei dem Client. Das ist nur ein Rechner im Clientnetzwerk.
das passt schon bei dem Client. Das ist nur ein Rechner im Clientnetzwerk.
Dann können wir den Case ja ganz beruhigt schliessen... 😉
