6
Netzwerk bzw VPN wird lahm
Servus zusammen,
Netzwerk (bzw die Verbindung) sieht so aus:
VM-Daten -> 1GBe -> Zyxel USG60W -> VLAN 1GBe -> VM OpenVPN_1 -> Zyxel USG60W -> Internet -> Fritte an VDSL -> VM OpenVPN_2 -> QNAP NAS
Internet an USG: 200mbit/s symmetrisch
Internet an Fritte 100/40mbit/s
Zyxel: P1: WAN, P3 192.168.0.252/24, P4: 192.168.3.1(VLAN)
VM-Daten (Server 2016): 192.168.0.7/24 GW: .252 (Zyxel)
OVPN_1 (CentOs7): 192.168.3.2/24 GW: .1 (VLAN auf Zyxel)
OVPN_2 (CentOs7): 192.168.200.200/24 GW: .1 (Fritte mit PFW 1194UDP)
QNAP: 192.168.200.201/25 GW: .1 (Fritte) bzw .200 für Ziel: 192.168.0.0/24
Tunnel: 10.10.10.x
Zyxel und QNAP haben die entsprechenden Routen eingetragen.
Von VM-Daten geht eine iSCSI-Verbindung zum QNAP NAS.
Windows Serversicherung startet und überträgt über 400GB über diese Verbindung. Konstant mit 8-10MB/s
Dann bricht irgendwann die Verbindung ein und es werden nur noch 700-800kB/s übertragen.
Test während niedriger Datenrate (Backup läuft noch)
Netioserver VM-Daten => Netioclient NAS ca 700kB/s, Empfang um die 4MB/s
Netioserver VM-Daten => Netioclient OVPN_2 ca 700kB/s, Empfang um die 4MB/s
Netio VM-Daten => Netio OVPN_1 in DMZ etwa 16MB/s in beide Richtungen (zu wenig hier müsste auch ~100MB/s kommen, aber zum "Tunnelfüllen" ausreichend, verursacht hier nicht das Problem)
Netio VM-Daten => beliebige andere VM ~240MB/s
Netio VM-Daten => beliebiger Client im 192.168.0.0/24 ~100MB/s
Abbruch des Backups alleine bewirkt nichts. Auftrennen iSCSI bringt nichts. Netio von VM-Daten zu NAS nach wie vor ~700kb/s Empfang ~4MB/s
Nach Reboot VM-Daten:
Netioserver VM-Daten => Netioclient NAS ca 9MB/s, Empfang um die 4MB/s (hier begrent die Asymetrische DSL Leitung).
Netioserver VM-Daten => Netioclient OVPN_2 ca 9MB/s, Empfang um die 4MB/s (wie erwartet)
Netio VM-Daten => Netio OVPN_1 in DMZ etwa 16MB/s in beide Richtungen (zu wenig s.o.)
Netio VM-Daten => beliebige andere VM ~240MB/s
Netio VM-Daten => beliebiger Client im 192.168.0.0/24 ~100MB/s
Irgendwas scheint sich im IP-Stack der VM-Daten zu verändern im Laufe der Zeit.
Paketlänge MTU beträgt laut TCPDUMP 1310, wird auch nix fragmentiert.
Die Fragen die sich mir auftun:
- merkt sich WIndows die langsame Verbindung (auf DSL Seite wird gesurft, auch Videos und ähnliches geschaut) und hält das dann gedrosselt? Allerdings ist die Verbindung erst gegen 14 Uhr heute Mittag langsam geworden, da war schon lange anderer "Datenmüll" auf der VDSL-Leitung. (Kinder heute nur 4h Schule).
- wie bekomme ich den IP-Stack der VM-Daten "resetted" so dass das Backup nicht abbricht ? Bzw für diese einzelne Verbindung? NETSH INT IP RESET ist nicht die Lösung.
- wie kann ich mir die aktuelle MSS für diese Verbindung (VM-Daten zum NAS) auf dem Windowsserver anschauen ? Kann mir zwar die MTU der NIC anzeigen lassen, aber damit komme ich nicht weiter.
Wenn einer der Provider drosseln würde, dürfte es ja nicht nach Reboot der VM-Daten wieder schneller werden (OVPN wird nicht unterbrochen dadurch)
Wenn jemand noch nen Ansatz hat, gerne her damit. Hier bin ich am Ende meines Wissens angekommen.
Ich hab das mal in Netzwerke Monitoring gepackt, weil ich keinerlei Idee habe, wo das sonst hingehören könnte.
Fehlen bestimmte Angaben ? Kann ich gerne nachliefern.
Grüße,
Henere
Netzwerk (bzw die Verbindung) sieht so aus:
VM-Daten -> 1GBe -> Zyxel USG60W -> VLAN 1GBe -> VM OpenVPN_1 -> Zyxel USG60W -> Internet -> Fritte an VDSL -> VM OpenVPN_2 -> QNAP NAS
Internet an USG: 200mbit/s symmetrisch
Internet an Fritte 100/40mbit/s
Zyxel: P1: WAN, P3 192.168.0.252/24, P4: 192.168.3.1(VLAN)
VM-Daten (Server 2016): 192.168.0.7/24 GW: .252 (Zyxel)
OVPN_1 (CentOs7): 192.168.3.2/24 GW: .1 (VLAN auf Zyxel)
OVPN_2 (CentOs7): 192.168.200.200/24 GW: .1 (Fritte mit PFW 1194UDP)
QNAP: 192.168.200.201/25 GW: .1 (Fritte) bzw .200 für Ziel: 192.168.0.0/24
Tunnel: 10.10.10.x
Zyxel und QNAP haben die entsprechenden Routen eingetragen.
Von VM-Daten geht eine iSCSI-Verbindung zum QNAP NAS.
Windows Serversicherung startet und überträgt über 400GB über diese Verbindung. Konstant mit 8-10MB/s
Dann bricht irgendwann die Verbindung ein und es werden nur noch 700-800kB/s übertragen.
Test während niedriger Datenrate (Backup läuft noch)
Netioserver VM-Daten => Netioclient NAS ca 700kB/s, Empfang um die 4MB/s
Netioserver VM-Daten => Netioclient OVPN_2 ca 700kB/s, Empfang um die 4MB/s
Netio VM-Daten => Netio OVPN_1 in DMZ etwa 16MB/s in beide Richtungen (zu wenig hier müsste auch ~100MB/s kommen, aber zum "Tunnelfüllen" ausreichend, verursacht hier nicht das Problem)
Netio VM-Daten => beliebige andere VM ~240MB/s
Netio VM-Daten => beliebiger Client im 192.168.0.0/24 ~100MB/s
Abbruch des Backups alleine bewirkt nichts. Auftrennen iSCSI bringt nichts. Netio von VM-Daten zu NAS nach wie vor ~700kb/s Empfang ~4MB/s
Nach Reboot VM-Daten:
Netioserver VM-Daten => Netioclient NAS ca 9MB/s, Empfang um die 4MB/s (hier begrent die Asymetrische DSL Leitung).
Netioserver VM-Daten => Netioclient OVPN_2 ca 9MB/s, Empfang um die 4MB/s (wie erwartet)
Netio VM-Daten => Netio OVPN_1 in DMZ etwa 16MB/s in beide Richtungen (zu wenig s.o.)
Netio VM-Daten => beliebige andere VM ~240MB/s
Netio VM-Daten => beliebiger Client im 192.168.0.0/24 ~100MB/s
Irgendwas scheint sich im IP-Stack der VM-Daten zu verändern im Laufe der Zeit.
Paketlänge MTU beträgt laut TCPDUMP 1310, wird auch nix fragmentiert.
Die Fragen die sich mir auftun:
- merkt sich WIndows die langsame Verbindung (auf DSL Seite wird gesurft, auch Videos und ähnliches geschaut) und hält das dann gedrosselt? Allerdings ist die Verbindung erst gegen 14 Uhr heute Mittag langsam geworden, da war schon lange anderer "Datenmüll" auf der VDSL-Leitung. (Kinder heute nur 4h Schule).
- wie bekomme ich den IP-Stack der VM-Daten "resetted" so dass das Backup nicht abbricht ? Bzw für diese einzelne Verbindung? NETSH INT IP RESET ist nicht die Lösung.
- wie kann ich mir die aktuelle MSS für diese Verbindung (VM-Daten zum NAS) auf dem Windowsserver anschauen ? Kann mir zwar die MTU der NIC anzeigen lassen, aber damit komme ich nicht weiter.
Wenn einer der Provider drosseln würde, dürfte es ja nicht nach Reboot der VM-Daten wieder schneller werden (OVPN wird nicht unterbrochen dadurch)
Wenn jemand noch nen Ansatz hat, gerne her damit. Hier bin ich am Ende meines Wissens angekommen.
Ich hab das mal in Netzwerke Monitoring gepackt, weil ich keinerlei Idee habe, wo das sonst hingehören könnte.
Fehlen bestimmte Angaben ? Kann ich gerne nachliefern.
Grüße,
Henere
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 398714
Url: https://administrator.de/forum/netzwerk-bzw-vpn-wird-lahm-398714.html
Ausgedruckt am: 20.04.2025 um 19:04 Uhr
6 Kommentare
Neuester Kommentar
Die Kardinalsfrage ist WIE die jeweiligen OVPN Tunnel Endpunkte ins Netzwerk eingebunden sind. Aus deiner Skizze ist das leider nicht ganz klar erkennbar.
Vermutlich sind sie "one armed" im lokalen Netz angeschlossen, oder ? Sprich also mit einem einzigen Bein im lokalen Netz.
Der gravierende Nachteil ist dann das RX und TX Traffic quasi gleichzeitig über eine NIC laufen muss und das an beiden Enden. On Top sogar noch in einen gerouteten VLAN.
Für ein VPN Design was auf Performance ausgerichtet ist kein besonders optimales Design.
Vermutlich rennst du in ein Buffer Bloating Problem. https://en.wikipedia.org/wiki/Bufferbloat
Mit 1310 Bytes MTU ist diese auch sehr klein gewählt. 1452 oder minimal 1400 sollten auch möglich sein. Die MTU musst du auf alle Fälle setzen auf den OVPN Tunnelenden.
Die grundsätzliche Frage die sich ja stellt in dem o.a. Design ist die warum du diesen sinnfreien Umweg über OVPN überhaupt nimmst ? Das müsste ja nicht sein.
Du hast auf der einen Seite die Zyxel USG und auf der anderen Seite die Fritte.
Beide sprechen IPsec VPN !!
Warum setzt du nicht ein LAN zu LAN VPN mit IPsec über diese beiden Geräte auf ? Das wäre doch das naheliegenste wenn du schon diese Komponenten im Einsatz hast die das ermöglichen.
Damit hättest du ein Pass through VPN statt one armed und würdes vor allem die so oder so beteiligten Endgeräte nutzen statt weiter eigentlich überflüssige "Durchlauferhitzer" dazwischen !
Keep it simple and stupid und damit auch performanter !
Vermutlich sind sie "one armed" im lokalen Netz angeschlossen, oder ? Sprich also mit einem einzigen Bein im lokalen Netz.
Der gravierende Nachteil ist dann das RX und TX Traffic quasi gleichzeitig über eine NIC laufen muss und das an beiden Enden. On Top sogar noch in einen gerouteten VLAN.
Für ein VPN Design was auf Performance ausgerichtet ist kein besonders optimales Design.
Vermutlich rennst du in ein Buffer Bloating Problem. https://en.wikipedia.org/wiki/Bufferbloat
Mit 1310 Bytes MTU ist diese auch sehr klein gewählt. 1452 oder minimal 1400 sollten auch möglich sein. Die MTU musst du auf alle Fälle setzen auf den OVPN Tunnelenden.
Die grundsätzliche Frage die sich ja stellt in dem o.a. Design ist die warum du diesen sinnfreien Umweg über OVPN überhaupt nimmst ? Das müsste ja nicht sein.
Du hast auf der einen Seite die Zyxel USG und auf der anderen Seite die Fritte.
Beide sprechen IPsec VPN !!
Warum setzt du nicht ein LAN zu LAN VPN mit IPsec über diese beiden Geräte auf ? Das wäre doch das naheliegenste wenn du schon diese Komponenten im Einsatz hast die das ermöglichen.
Damit hättest du ein Pass through VPN statt one armed und würdes vor allem die so oder so beteiligten Endgeräte nutzen statt weiter eigentlich überflüssige "Durchlauferhitzer" dazwischen !
Keep it simple and stupid und damit auch performanter !
Moin Aqui,
genau aus Performancegründen hab ich das so gemacht. Der VPN-Durchsatz der Fritte genauso wie der des Zyxel kommen bei weitem nicht auf den gewünschten Datendurchsatz. Die SOCs sind nicht dafür gebaut, daher nun in Software. War schon mal Thema in einer meiner Fragen.
Rechnerisch brauche ich ~10MB/s am OVPN-Server damit die Leitung gefüllt werden kann. Das ist ja hier der Fall.
Ich könnte beide OPVN_Server auch 2-beinig betreiben.
Die length 1310 ist nicht von mir vorgegeben, das ist die angezeigte Größe im TCPDUMP zwischen VM-Daten und OVPN_1.
Was mir gar nicht so in den Kopf will, warum läuft das ca 300-400GB ohne Probleme ? Und warum geht es wieder schneller, wenn ich den Windows-Server reboote ? Wenn es nach wenigen MB auftreten würde.... ok... aber erst nach der Masse an Daten ? Einzelne Kopierjobs per Explorer mit mehreren Gigybyte laufen auch komplett durch mit voller Bandbreite.
Ein deaktivieren der NIC am Server 2016 und reaktivieren macht keinen Unterschied.
Was mir aber hier auffällt..... IIIIIIIK !!!!
Ich deaktiviere die NIC der VM. Dennoch sehe ich im ResMon Netzwerktraffic ? Die Zahlen verändern sich, laut ResMon ist trotz deaktivierter NIC immer noch Traffic ?
Grüße, Henere
genau aus Performancegründen hab ich das so gemacht. Der VPN-Durchsatz der Fritte genauso wie der des Zyxel kommen bei weitem nicht auf den gewünschten Datendurchsatz. Die SOCs sind nicht dafür gebaut, daher nun in Software. War schon mal Thema in einer meiner Fragen.
Rechnerisch brauche ich ~10MB/s am OVPN-Server damit die Leitung gefüllt werden kann. Das ist ja hier der Fall.
Ich könnte beide OPVN_Server auch 2-beinig betreiben.
Die length 1310 ist nicht von mir vorgegeben, das ist die angezeigte Größe im TCPDUMP zwischen VM-Daten und OVPN_1.
Was mir gar nicht so in den Kopf will, warum läuft das ca 300-400GB ohne Probleme ? Und warum geht es wieder schneller, wenn ich den Windows-Server reboote ? Wenn es nach wenigen MB auftreten würde.... ok... aber erst nach der Masse an Daten ? Einzelne Kopierjobs per Explorer mit mehreren Gigybyte laufen auch komplett durch mit voller Bandbreite.
Ein deaktivieren der NIC am Server 2016 und reaktivieren macht keinen Unterschied.
Was mir aber hier auffällt..... IIIIIIIK !!!!
Ich deaktiviere die NIC der VM. Dennoch sehe ich im ResMon Netzwerktraffic ? Die Zahlen verändern sich, laut ResMon ist trotz deaktivierter NIC immer noch Traffic ?
Grüße, Henere
OK, das stimmt. Der VPN Durchsatz der FritzBüx ist grottenschlecht. Hatte die ct' ja auch kürzlich festgestellt. Sorry, das hatte ich nicht auf dem Radar.
Deshalb ist es sinnvoll das vorzugeben. Vor allem den MSS Wert auf den Interfaces ins lokale LAN.
Hier solltest du ggf. von den Endgeräten mal einen entsprechenden Ping machen und die max. MTU ermitteln
ping <Ziel_IP> -f -l 1492 und dann langsam runtergehen 1472, 1462, 1440, 1400 bis du die Paketgröße erreicht hast, die gerade nicht fragmentiert wird.
Kopierjobs mit Explorer sprich SMB/CIFS sind immer schlecht, da SMB nur sehr kleine Pakete verwendet und somit sehr uneffizient ist. Zudem beansprucht es dadurch massiv die Router Performance und von der VPN Kryptografie mal gar nicht zu reden. Dadurch das es aber bei kleineren Volumina fehlerlos klappt ist vermutlich dort nicht der Flaschenhals sondern woanders.
Firmware von allen beteiligten Komponenten auf dem aktuellen Stand ?
Ich könnte beide OPVN_Server auch 2-beinig betreiben.
Wäre sicher mal einen Versuch wert.das ist die angezeigte Größe im TCPDUMP
tcpdump kann sowas gar nicht anzeigen ! Das weiss ja nix von einem VPN Tunnel im Pfad, es sei denn die Tunnel Endpoints würden eine automatische TCP MTU Path Discovery machen, was OVPN aber nicht kann und macht.Deshalb ist es sinnvoll das vorzugeben. Vor allem den MSS Wert auf den Interfaces ins lokale LAN.
Hier solltest du ggf. von den Endgeräten mal einen entsprechenden Ping machen und die max. MTU ermitteln
ping <Ziel_IP> -f -l 1492 und dann langsam runtergehen 1472, 1462, 1440, 1400 bis du die Paketgröße erreicht hast, die gerade nicht fragmentiert wird.
Und warum geht es wieder schneller, wenn ich den Windows-Server reboote ?
Wie gesagt...vermutlich Buffer Bloating an den NICs. Kann aber auch ein Treiber Problem dort sein durch falsches Buffer Handling.Kopierjobs mit Explorer sprich SMB/CIFS sind immer schlecht, da SMB nur sehr kleine Pakete verwendet und somit sehr uneffizient ist. Zudem beansprucht es dadurch massiv die Router Performance und von der VPN Kryptografie mal gar nicht zu reden. Dadurch das es aber bei kleineren Volumina fehlerlos klappt ist vermutlich dort nicht der Flaschenhals sondern woanders.
Firmware von allen beteiligten Komponenten auf dem aktuellen Stand ?
Servus,
tcpdump auf das tun-if:
15:10:52.132129 IP VM-Daten.51531 > nas2.iscsi-target: Flags [.], seq 1672870:1674180, ack 529, win 258, length 1310
Da sehe ich die MTU von 1310.
SMB-copy war nur rein zum testen.
Firmware des NAS, der Fritte und des Zyxel sind aktuell.
Die beiden CentOS und der Server2016 sind VMs, Da ist nicht viel mit Treiber aktualisieren.
Die HV-Komponenten der VMs sind auf dem aktuellen Stand.
Von und zu VM-Daten kann ich Terrabyteweise Daten kopieren, durchgängig performant mit ~100MB/s. Wenn Treiber dann sollte doch da auch was auftreten, oder ?
Was mir auffällt, wenn ich die NIC der VM-Daten deaktiviere dauert es bis zu 10 Sekunden bis der Traffic am NAS gen Null geht. Also ist da noch ein Puffer der geleert werden muss.
Mein Spezel von der CW ist auch überfragt.
Henere
tcpdump auf das tun-if:
15:10:52.132129 IP VM-Daten.51531 > nas2.iscsi-target: Flags [.], seq 1672870:1674180, ack 529, win 258, length 1310
Da sehe ich die MTU von 1310.
SMB-copy war nur rein zum testen.
Firmware des NAS, der Fritte und des Zyxel sind aktuell.
Die beiden CentOS und der Server2016 sind VMs, Da ist nicht viel mit Treiber aktualisieren.
Die HV-Komponenten der VMs sind auf dem aktuellen Stand.
Von und zu VM-Daten kann ich Terrabyteweise Daten kopieren, durchgängig performant mit ~100MB/s. Wenn Treiber dann sollte doch da auch was auftreten, oder ?
Was mir auffällt, wenn ich die NIC der VM-Daten deaktiviere dauert es bis zu 10 Sekunden bis der Traffic am NAS gen Null geht. Also ist da noch ein Puffer der geleert werden muss.
Mein Spezel von der CW ist auch überfragt.
Henere
Da sehe ich die MTU von 1310.
Das stellt vermutlich einer deiner Endgeräte automatisch ein 
Ok, den Windowsserver kann ich wohl auch ausschliessen.
Jetzt bringt der Reboot nix mehr. War wohl mehr oder weniger Zufall.
Ich frage mich ob die beteiligten Provider drosseln ?
dt. Glasfaser und dt. Telekom.
Sobald ich meine Fritte neu einwählen lasse (andere ext IP bekomme), ist die Performance wieder so hoch wie zuvor. Mal schauen wie lange.
Hat jemand so etwas schon mal mitbekommen ?
Evtl falsch interpretierter Flooding-Schutz ?
Henere
Jetzt bringt der Reboot nix mehr. War wohl mehr oder weniger Zufall.
Ich frage mich ob die beteiligten Provider drosseln ?
dt. Glasfaser und dt. Telekom.
Sobald ich meine Fritte neu einwählen lasse (andere ext IP bekomme), ist die Performance wieder so hoch wie zuvor. Mal schauen wie lange.
Hat jemand so etwas schon mal mitbekommen ?
Evtl falsch interpretierter Flooding-Schutz ?
Henere
