TCP Retransmission in OpenVPN

schrotti12

Lt. Junior Grade
Registriert
Juli 2004
Beiträge
421
Hallo, ich habe ein seltsames Problem und bräuchte ein paar Stichworte, nach denen ich suchen kann.

Ich betreibe einen OpenVPN Server zu Hause hinter einer Firewall. Ports sind freigegeben und Routen sind eingerichtet. Ich kann mich mit dem Netz verbinden, komme auf die Server und das funktioniert alles. Nun ist mir aufgefallen, dass die Verbindung allerdings sehr träge ist und ich im kb/s Bereich unterwegs bin. Eine kurze Analsyse mit Wireshark hat gezeigt, dass bei einem SCP-Dateitransfer sehr viele "TCP retransmission" angefordert und durchgeführt werden. Das wäre ansich noch nicht so kurios.

Kurios is, dass die Verbindung normal schnell funktioniert, wenn ich sie ber eine SSH-Portweiterleitung laufen lasse. Sprich: Ich verbinde mich mit "ssh user@meingateway.com -L 12194:meinvpnserver.lan:1194" zuerst auf einen Host im Netz und verbinde mich nacher via OpenVPN auf "localhost" mit Port 12194 (auf dem "road warrior" pc) und die Verbindung läuft problemlos.

Ich habe bereits versucht die MTU runter zu drehen und zu evaluieren, welche da passen müsste. wenn wie in Absatz 2 beschrieben die Verbindung klappt, zeigt mir Wireshark eine Packetsize von 1474 an.

Hat jemand eine Idee, was ich da falsch mache?

Danke und lg
Andreas
 
TCP Server oder UDP?

Wenn UDP probiere mal serverseitig:
Code:
mssfix 1350
fast-io
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
 
Stinkt nach MTU Problem. Versuch mal, ob das Problem mit MTU 1300 verschwindet.
 
  • Gefällt mir
Reaktionen: Markchen und madmax2010
TCP-Verbindungen sind generell sehr langsam unter OpenVPN, offiziell wird zu UDP geraten, damit sind die Geschwindigkeitsprobleme Geschichte. Die eigentlichen Pakete im Tunnel können sowieso ungeachtet des Tunnel-Ports mit TCP versendet werden.
 
  • Gefällt mir
Reaktionen: Raijin und up.whatever
till69 schrieb:
TCP Server oder UDP?
Aktuell TCP. Aber ich werde glaub versuchen mal einen UDP Server aufzusetzten.

up.whatever schrieb:
Stinkt nach MTU Problem. Versuch mal, ob das Problem mit MTU 1300 verschwindet.
Server- oder Clientseitig? Ich habe versucht es im Server zu definieren und per "push" auf den Client zu bringen, aber die Verbindung war stets langsam. Ich glaube eben auch, dass es die MTU ist, aber ich verstehe die Konfiguration noch nicht vollständig. Lese mich da gerade ein.

_anonymous0815_ schrieb:
TCP-Verbindungen sind generell sehr langsam unter OpenVPN, offiziell wird zu UDP geraten, damit sind die Geschwindigkeitsprobleme Geschichte. Die eigentlichen Pakete im Tunnel können sowieso ungeachtet des Tunnel-Ports mit TCP versendet werden.
Klingt einleuchtend. Ich versuch mal die bestehende Config zu kopieren und als UDP zu verwenden. Ein Versuch ist es auf jeden Fall wert. Danke.
 
schrotti12 schrieb:
Server- oder Clientseitig?
An beiden Enden des Tunnels.
Ich kenne mich mit den Details der OpenVPN Config leider nicht aus, aber bei VPN hast du generell das Problem, dass die durch VPN übermittelten Pakete zusammen mit den ganzen Headern der VPN Verbindung (IP Header + TCP/UDP header + ggf. VPN-Protokoll spezifisches) immer noch durch deine Internetverbindung verschickt werden müssen. Da letztere auf MTU 1500 (bzw. 1492 mit PPPoE) begrenzt ist, sollte die MTU der VPN-Interfaces maximal diesen Wert minus VPN Overhead betragen, sonst werden zu große durchs VPN geschickten Pakete entweder fragmentiert oder komplett gedroppt. Letzteres sorgt dann für die beschriebenen Probleme.

Bei TCP Verbindungen, die durch den Tunnel gehen, kann man das Problem umgehen, indem man den MSS Wert in den SYN Paketen beim Verbindungsaufbau auf einen kleineren Wert überschreibt, das scheint bei OpenVPN die angesprochen "mssfix" Option zu erledigen. Für alles was über TCP läuft sollte das ausreichend sein, also auch für deine SCP Verbindung.
Edit: Bei der mssfix Option bitte unbedingt darauf achten, dass der eingestellte Wert um mindestens 40 kleiner als die VPN MTU ist!

Bei UDP Paketen, die durch den Tunnel gehen, gibt es keine solchen Workarounds, hier hilft nur eine korrekte MTU Konfiguration und funktionierendes Path MTU discovery. Hier musst du also ggf. noch darauf achten, dass die entsprechenden ICMP Error Pakete nicht von einer Firewall blockiert werden.

Die vorgeschlagene MTU 1300 ist quasi die Nummer Sicher. Damit kannst du recht verlässlich annehmen, dass die VPN Pakete selbst mit sämtlichem Overhead auf jeden Fall noch kleiner als die MTU deiner Internetverbindung sind und unfragmentiert durchs VPN passen. Wenn das Problem auch mit ordentlich konfiguriertem MTU 1300 weiterhin besteht, ist es wahrscheinlich kein MTU Problem.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Raijin
Bei TCP VPN entsteht ein enormer Overhead an Traffic. TCP ist verbindungsorientiert und jedes eingehende Paket wird mit einem ACK-Paket quittiert.

Schickt man nun UDP-Anwendungen, die offenbar keine Quittierungen benötigen, weil verlorene Pakete egal sind, weil sie beim Neusenden veraltet wären, über ein TCP VPN, werden die UDP-Pakete indirekt eben doch quittiert, weil das VPN-Paket, in dem das UDP-Paket geraspelt wurde, quittiert und schlimmstenfalls eben auch nochmal geschickt wird. Eine bewusst ungesicherte UDP-Verbindung wird also unnötigerweise künstlich gesichert. Es entsteht sinnloser Overhead in der VPN-Verbindung.

Bei TCP-Anwendungen, die über ein TCP-VPN gehen, verstärkt sich dieser Effekt. Die Anwendung schickt ein Paket und erwartet dafür ein ACK. Das VPN kapseln beides und schickt sich jeweils nochmal gegenseitig ein ACK, um die VPN-Kapselpakete zu bestätigen. Doppelt gemoppelt hält besser, nicht wahr? Blöd wird es bei Paketverlusten, weil dann sowohl die Anwendung als auch das VPN ständig ein TCP-Retransmission auslösen. Am Ende führt das zum 4-fachen an TCP-bedingtem Traffic durch das doppelte hin und doppelte zurückbestätigen und neu senden.

Laaange Rede, kurzer Sinn: Wenn überhaupt nur dann ein TCP VPN einsetzen, wenn die Netzwerk- und Internet Internetverbindungen Hochstapler sind und keine Paketverluste auftreten. Sonst sieht das in WireShark genau so aus wie in #1 beschrieben, lauter TCP Retransmissions....


Im übrigen kann die MTU Innerhalb von OpenVPN nahezu beliebig groß gewählt werden, weil die MTU nur für das virtuelle TAP-/TUN-Interface gilt und NICHTS mit der MTU im physischen Netzwerk oder gar dem Internet zu tun hat. Genau genommen ist eine hohe MTU sogar ein Performance Tweak bei OpenVPN.
 
  • Gefällt mir
Reaktionen: _anonymous0815_
Raijin schrieb:
Wenn überhaupt nur dann ein TCP VPN einsetzen, wenn die Netzwerk- und Internet Internetverbindungen Hochstapler sind und keine Paketverluste auftreten.
Oder aber UDP geblockt wird, aus welchen Gründen auch immer.
Deshalb einen UDP Server als Standard und einen TCP als Backup.
 
  • Gefällt mir
Reaktionen: Raijin
Geile Autokorrektur am neuen Tablet ... Hochstapler Internetverbindungen... Den ganzen Tag schon tippe ich Fehler ohne Ende, ich könnte Katzen
 
  • Gefällt mir
Reaktionen: Bob.Dig
Eigentlich sollte da hochstabile stehen, aber Tablet sagt nein. Alter, was ich heute wohl sonst noch für Stoßstange gebastelt habe ohne es zu merken
 
  • Gefällt mir
Reaktionen: Bob.Dig
Also erstmal vielen Dank für die sachlichen und professionellen Hinweise. Ich werde es mit einer UDP Verbindung und in einem zweiten Profil mit reduzierter MTU versuchen.
 
Zurück
Oben