18
OpenVPN Verbindungsprobleme
Hallo,
ich habe eine Client-to-Client Verbindung mit OpenVPN eingerichtet.
Anfangs funktionierte alles fehlerfrei, nur jetzt nach ca. 2 Tagen habe ich sehr hohe Paketverluste im Tunnel.
Neuaufbauen des Tunnels auf beiden Seiten bringt keine Besserung.
Das Komische ist, ist der Tunnel nicht ausgelastet, gehen alle Pings erfolgreich durch (teilweise mit hohen Latenzen 600ms). Ist jedoch eine RDP Verbindung zusätzlich aktiv, bricht die Verbindung sehr häufig ab (auch die Pings gehen nicht mehr durch). Der Tunnel bricht dabei nicht zusammen und wird laut logfile auch nicht neu aufgebaut (weil er ja immer noch steht).
Ein manueller neu aufbau behebt das Problem für ca. 10 - 20 Sekunden.
Die Konfiguration ist über UDP und TUN.
Der Server hat das Betriebssystem Windows 10 Pro genauso wie der Client.
Mein Client ist über WLAN mit dem Internet Verbunden (Hotel)
Mein Server ist über LAN <=> Router <=> DSL-Router mit dem Internet Verbunden und Port 1194 ist freigegeben.
ich habe eine Client-to-Client Verbindung mit OpenVPN eingerichtet.
Anfangs funktionierte alles fehlerfrei, nur jetzt nach ca. 2 Tagen habe ich sehr hohe Paketverluste im Tunnel.
Neuaufbauen des Tunnels auf beiden Seiten bringt keine Besserung.
Das Komische ist, ist der Tunnel nicht ausgelastet, gehen alle Pings erfolgreich durch (teilweise mit hohen Latenzen 600ms). Ist jedoch eine RDP Verbindung zusätzlich aktiv, bricht die Verbindung sehr häufig ab (auch die Pings gehen nicht mehr durch). Der Tunnel bricht dabei nicht zusammen und wird laut logfile auch nicht neu aufgebaut (weil er ja immer noch steht).
Ein manueller neu aufbau behebt das Problem für ca. 10 - 20 Sekunden.
Die Konfiguration ist über UDP und TUN.
Der Server hat das Betriebssystem Windows 10 Pro genauso wie der Client.
Mein Client ist über WLAN mit dem Internet Verbunden (Hotel)
Mein Server ist über LAN <=> Router <=> DSL-Router mit dem Internet Verbunden und Port 1194 ist freigegeben.
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: 312158
Url: https://administrator.de/forum/openvpn-verbindungsprobleme-312158.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
18 Kommentare
Neuester Kommentar
Hallo,
Client to Client? Sicher?
Was für Internetverbindungen hast du denn (Download/Upload)?
Gemessen und keine bis zu Werbewerte bitte.
Wenn der Tunnel an sich steht, fällt ein Konfigurationsfehler ja flach.
Gruß
Client to Client? Sicher?
Was für Internetverbindungen hast du denn (Download/Upload)?
Gemessen und keine bis zu Werbewerte bitte.
Wenn der Tunnel an sich steht, fällt ein Konfigurationsfehler ja flach.
Gruß
Na ja wenn er einen Server dazwischen hat geht das schon. Ohne den natürlich technisch unmöglich. Vermutlich ist das so gemeint ?!
Wir raten mal.... Zu 98% eine falsche MTU im Tunnel ?!
Hi,
wie @aqui schon sagt, sicher MTU Problem. Wenn Du MTU 1500 fährst, ist das zu erwarten. Reduzier den MTU-Wert einmal auf 1340. Wenn es dann funktioniert kannst Du es in kleineren Schritten wieder erhöhen und testen bei welchem Wert der Packetverkehr instabil wird.
Gruß orcape
wie @aqui schon sagt, sicher MTU Problem. Wenn Du MTU 1500 fährst, ist das zu erwarten. Reduzier den MTU-Wert einmal auf 1340. Wenn es dann funktioniert kannst Du es in kleineren Schritten wieder erhöhen und testen bei welchem Wert der Packetverkehr instabil wird.
Gruß orcape
#OpenVPN Server conf
client
dev tun
proto udp
tun-mtu 1340
remote ovpn.agowa338.de 1194
comp-lzo
verb 3
client
dev tun
proto udp
tun-mtu 1340
remote ovpn.agowa338.de 1194
comp-lzo
verb 3
Hat jetzt leider etwas länger gedauert die mtu zu ändern (die RDP Verbindung fliegt ja permanent weg...)
Hat aber nicht wirklich geholfen.
Das Problem ist leider nach wie vor da.
Die mtu ist es vermutlich nicht. Die Verbindung fliegt selbst bei: "ping 10.8.0.1 -t -l 50 -f" unregelmäßig weg...
Hat aber nicht wirklich geholfen.
Das Problem ist leider nach wie vor da.
Die mtu ist es vermutlich nicht. Die Verbindung fliegt selbst bei: "ping 10.8.0.1 -t -l 50 -f" unregelmäßig weg...
50 Byte Length ist natürlich technischer Blödsinn. Sorry, aber als Netzwerker solltest du wissen das die minimale Ethernet Framesize 64 Byte ist !
Außerem solltest du nochmal definieren was genau du mit Client zu Client meinst ?!
Wir sehen das jetzt mal so mit einer Client OVPN Connection über einen Server in dessen Konfig eine Client zu Client Kommunikation erlaubt ist, richtig ?
Wenn du einen aktiven Tunnel hast was sagt denn ein ifconfig oder ipconfig wird dir dort die korrekte MTU angezeigt ?
Testweise kannst du mal tun-mtu 1380 durch das folgende Kommando ersetzen: link-mtu 1432 Das ist etwas sinnvoller, dann kümmert sich OVPN selber um die korrekte MTU.
Alternativ kannst du auch folgendes nehmen: mssfix 1420
Eins von beiden sollte greifen.
Außerem solltest du nochmal definieren was genau du mit Client zu Client meinst ?!
Wir sehen das jetzt mal so mit einer Client OVPN Connection über einen Server in dessen Konfig eine Client zu Client Kommunikation erlaubt ist, richtig ?
Wenn du einen aktiven Tunnel hast was sagt denn ein ifconfig oder ipconfig wird dir dort die korrekte MTU angezeigt ?
Testweise kannst du mal tun-mtu 1380 durch das folgende Kommando ersetzen: link-mtu 1432 Das ist etwas sinnvoller, dann kümmert sich OVPN selber um die korrekte MTU.
Alternativ kannst du auch folgendes nehmen: mssfix 1420
Eins von beiden sollte greifen.
Zitat von @aqui:
50 Byte Length ist natürlich technischer Blödsinn. Sorry, aber als Netzwerker solltest du wissen das die minimale Ethernet Framesize 64 Byte ist !
Ja, ist Schwachsinn, sollte eigentlich 500 heißen...50 Byte Length ist natürlich technischer Blödsinn. Sorry, aber als Netzwerker solltest du wissen das die minimale Ethernet Framesize 64 Byte ist !
Außerem solltest du nochmal definieren was genau du mit Client zu Client meinst ?!
Wir sehen das jetzt mal so mit einer Client OVPN Connection über einen Server in dessen Konfig eine Client zu Client Kommunikation erlaubt ist, richtig ?
Das sollte der Endzustand sein, aktuell gibt es aber die Probleme zwischen dem 1. Client und dem Server. Also noch keine Verbindung zu anderen Clients.Wir sehen das jetzt mal so mit einer Client OVPN Connection über einen Server in dessen Konfig eine Client zu Client Kommunikation erlaubt ist, richtig ?
Wenn du einen aktiven Tunnel hast was sagt denn ein ifconfig oder ipconfig wird dir dort die korrekte MTU angezeigt ?
ipconfig zeigt keine mtu an, aber:C:\Windows\system32>netsh interface ipv4 show interfaces
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
10 20 1500 connected Ethernet 2
16 25 1500 connected WLANTestweise kannst du mal tun-mtu 1380 durch das folgende Kommando ersetzen: link-mtu 1432 Das ist etwas sinnvoller, dann kümmert sich OVPN selber um die korrekte MTU.
Alternativ kannst du auch folgendes nehmen: mssfix 1420
Eins von beiden sollte greifen.
Leider keins von beiden.Alternativ kannst du auch folgendes nehmen: mssfix 1420
Eins von beiden sollte greifen.
ipconfig zeigt keine mtu an, aber:
Der Output ist sinnfrei, denn das sind die normalen Standardinterfaces 
Du hast vermutlichen keinen Tunnel aufgebaut, denn sonst würdest du dort das tun Interface sehen mit der MTU. Sieht man auch mit ipconfig. Logischerweise nur wenn der Tunnel etabliert ist. Kein Tunnel kein Interface...logisch !
Zeigt aber immer 1500 an...
Klar, denn das tun Interface ist ja gar nicht dabei !!Leider keins von beiden.
Dann hast du vermutlich ein Provider Problem. Manche Billigprovider filtern und/oder Rate limiten VPN Traffic bei einem billigen non Business Account !!Ggf. hier mal einen anderen UDP Port ausprobieren.
Zitat von @aqui:
Du hast vermutlichen keinen Tunnel aufgebaut, denn sonst würdest du dort das tun Interface sehen mit der MTU. Sieht man auch mit ipconfig. Logischerweise nur wenn der Tunnel etabliert ist. Kein Tunnel kein Interface...logisch !
"Ethernet 2" ist das tun Interface, du bist Linux Admin oder? Unter Windows ist das Interface immer vorhanden, selbst wenn kein Tunnel aufgebaut ist und Windows denkt es wäre eine LAN Verbindung, anders als bei Linux.ipconfig zeigt keine mtu an, aber:
Der Output ist sinnfrei, denn das sind die normalen Standardinterfaces Du hast vermutlichen keinen Tunnel aufgebaut, denn sonst würdest du dort das tun Interface sehen mit der MTU. Sieht man auch mit ipconfig. Logischerweise nur wenn der Tunnel etabliert ist. Kein Tunnel kein Interface...logisch !
Zeigt aber immer 1500 an...
Klar, denn das tun Interface ist ja gar nicht dabei !!Leider keins von beiden.
Dann hast du vermutlich ein Provider Problem. Manche Billigprovider filtern und/oder Rate limiten VPN Traffic bei einem billigen non Business Account !!Ggf. hier mal einen anderen UDP Port ausprobieren.
Unter Windows ist das Interface immer vorhanden, selbst wenn kein Tunnel aufgebaut ist
Igitt, ein Grund mehr gegen Winblows... Bei meinem Provider ist das nicht der Fall
Sicher ?? Woher weisst du das ? Arbeitest du selber da ?Geringe Chance besteht auch das deine Engeräte zu schwach sind was die Encryption angeht. Das wäre aber sehr sehr selten, denn auch ein uralter Linksys WRT54 Router schafft immer noch locker 3-5 Mbit und ein Tunnelabbruch oder Dropping von Frames im Tunnel passiert nie wenn sonst kein Linkabbruch passiert.
Ausnahme natürlich man macht so ein Unsinn wie Bridging über das VPN oder eine TCP Encapsulation aber das machst du ja nicht wenn man deine Schilderungen hier richtig interpretiert ?!
Ich denke wir drehen uns im kreis, hier einmal die vollständige Konfiguration:
Server:
Client:
Sollte doch so funktionieren oder?
Anderen Port kann ich leider nicht testen, weil das Forwarding von hier aus wegen der permanenten abbrüche nicht konfiguriert bekomme.
Server:
port 1194
proto udp
dev tun
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\server.crt"
key "C:\\Program Files\\OpenVPN\\config\\server.key"
dh "C:\\Program Files\\OpenVPN\\config\\dh2048.pem"
server 10.8.0.0 255.255.255.0
;ifconfig-pool-persist ipp.txt
;push "dhcp-option DNS 8.8.8.8"
;push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
mssfix 1420Client:
client
dev tun
proto udp
remote vpn.contoso.com 1194
resolv-retry infinite
keepalive 10 120
nobind
persist-key
persist-tun
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\notebook.crt"
key "C:\\Program Files\\OpenVPN\\config\\notebook.key"
remote-cert-tls server
comp-lzo
verb 3
mssfix 1420Sollte doch so funktionieren oder?
Anderen Port kann ich leider nicht testen, weil das Forwarding von hier aus wegen der permanenten abbrüche nicht konfiguriert bekomme.
Geringe Chance besteht auch das deine Engeräte zu schwach sind was die Encryption angeht
Denk ich nicht, auf beiden Seiten leistungsstarke Intel Prozessoren (i7 und i5) und mehrere GB Ram...Sollte doch so funktionieren oder?
Jein ! Ein gravierender Fehler am Server, denn dort fehlt das Push Kommando was das lokale LAN des Servers an die Clients pusht.
OK, das brauchst du nicht wenn du nur eine reine Client zu Client Kommunikation haben willst OHNE einen Zugriff auf ein lokales LAN.
mssfix brauchst du nur am Server !
Der Rest ist fehlerlos und richtig !
leistungsstarke Intel Prozessoren (i7 und i5)
OK...keine Frage das reicht für Gigabit in Wirespeed.
@script-kiddie: Youporn kannst du bis auf weiteres auch knicken, unter 02-FF-FF-FF-FF-FF gibt es kein Gateway, dein arp kann ich auch vergiften
@aqui: immer diese Kinder... Aber interessant, dass der Tunnel nicht zusammen gebrochen ist. Wireshark hätte ich schon früher verwenden sollen. Für nächstes mal richte ich mir einen Zweiten Tunnel mit TCP und Port 443 ein...
@aqui: immer diese Kinder... Aber interessant, dass der Tunnel nicht zusammen gebrochen ist. Wireshark hätte ich schon früher verwenden sollen. Für nächstes mal richte ich mir einen Zweiten Tunnel mit TCP und Port 443 ein...
Ich habe auch seit wenigen Tagen ein ähnliches Problem. Ich vermute sehr stark, dass es mit dem anniversary Update von Windows 10 zu tun hat, denn davor lief alles stabil und performant. Du verwendest auch Windows 10?
Besser nicht... !!!
TCP Encapsulation ist tödlich für die Performance. OpenVPN selber rät dringenst davon ab !
TCP Encapsulation ist tödlich für die Performance. OpenVPN selber rät dringenst davon ab !
Das mit TCP Encapsulation hab ich gelesen, aber ich möchte ja nur UDP Traffic (RDP) durch den Tunnel jagen, von dem her sollte das als Backup Tunnel gut genug sein, oder?
@temuco, das hab ich noch gar nicht installiert, aber danke für die Warnung
@temuco, das hab ich noch gar nicht installiert, aber danke für die Warnung
Ich habe das von mir kurz beschriebene Verhalten mit einem weiteren Notebook getestet, welches das "alte" Windows 10 hatte und keine Probleme mit OpenVPN verursachte. Windows 10 anniversary Update drauf und schon traten dieselben Probleme auf: RD bricht immer wieder ab, verbundene Netzwerke verlieren den Kontakt zum Server usw. Nach wenigen Minuten alles wieder OK, ohne dass OpenVPN irgend etwas protokolliert.
Zitat von @temuco:
Ich habe das von mir kurz beschriebene Verhalten mit einem weiteren Notebook getestet, welches das "alte" Windows 10 hatte und keine Probleme mit OpenVPN verursachte. Windows 10 anniversary Update drauf und schon traten dieselben Probleme auf: RD bricht immer wieder ab, verbundene Netzwerke verlieren den Kontakt zum Server usw. Nach wenigen Minuten alles wieder OK, ohne dass OpenVPN irgend etwas protokolliert.
Mir hat das letzte Win10 Update den Intel NIC Treiber zerschossen Ich habe das von mir kurz beschriebene Verhalten mit einem weiteren Notebook getestet, welches das "alte" Windows 10 hatte und keine Probleme mit OpenVPN verursachte. Windows 10 anniversary Update drauf und schon traten dieselben Probleme auf: RD bricht immer wieder ab, verbundene Netzwerke verlieren den Kontakt zum Server usw. Nach wenigen Minuten alles wieder OK, ohne dass OpenVPN irgend etwas protokolliert.
Jetzt darf ich momentan mit dem Windows Treiber herumhantieren weil die irgendwas an der Signatur geändert haben wie es scheint.
