tiefe Bandbreite bei SSL-VPN trotz Higspeed-Anschluss

Nidi_0179 · 2021-03-10T16:19:03+00:00

Sunrise Community - Kunden helfen anderen Kunden rund um die Themen Fernsehen, Internet, Telefon und Mobile. Jetzt registrieren!

GrandDixence

Nidi_0179
Hört sich doch an, als würde das Bandwidth-Delay Product mangels Unterstützung von “TCP window scale option” aka “Large TCP Receive Window” hier voll bei TCP-Verbindungen (wie SSL-VPN) begrenzend zuschlagen. Ich bezweifle, dass die schlechte VPN-Performance durch Peering-Probleme verursacht wird.

https://community.sunrise.ch/d/5503-ebenfalls-seit-tagen-abartig-langsames-internet/3

https://community.sophos.com/utm-firewall/f/german-forum/86448/drosselung-des-internet-durch-die-utm

Paketumlaufzeit (RTT) mit Wireshark messen. In den Wireshark-Aufzeichnungen (*.pcap oder *.pcapng) die Zeitdifferenz zwischen Versand des TCP SYN und des Empfangs des TCP SYN+ACK beim Aufbau des VPN-Tunnels messen (Kontextmenü -> Zeitreferenz setzen).
https://de.wikipedia.org/wiki/Transmission_Control_Protocol#Verbindungsaufbau

Paketumlaufzeiten (RTT) > 25 Millisekunden sind für alle VPN-Tunneln ein “Performancekiller”! Die Paketumlaufzeit (RTT) ist für die Performance eines Internetanschlusses deutlich wichtiger als die maximale Datenübertragungsrate.
https://mobilecommunity.ch/wbb/index.php?thread/326-salt-fiber-oder-salt-unlimited-surf-f%C3%BCr-heimnetzwerk/&postID=2526&highlight=paketumlaufzeit#post2526

https://michael.stapelberg.ch/posts/2014-09-05-fiber7_performance/

Weiter sollte mit Wireshark die aktuelle Grösse des “TCP Receive Buffer” aka RWin kontrolliert werden. Wireshark gibt RWin als “Win=” in der Info-Spalte aus. Testlauf mit einem Download ab dem japanischen Server JAIST (RTT: 288 ms) für ein richtig grosses “Large TCP Receive Window” (> 10 Megabyte) durchführen:
https://ftp.jaist.ac.jp/

Danach mit dem bereits bekannten Bandwidth-Delay Product-Rechner die maximal mögliche Datenübertragungsrate von TCP-Verbindungen berechnen.
https://www.switch.ch/network/tools/tcp_throughput/

Zur Anwendung von Wireshark und zum Thema “Peering-Probleme” siehe die entsprechenden Hinweise in der “Allgemeinen Fehlersuche” (Beitrag Nr. 3):
https://community.sunrise.ch/d/8569-gigaconnect-aussetzer/25

Nidi_0179

Hallo Zusammen

die Nachfrage beim IT-Dienstleister hat ergeben, dass wir vor etwa einem Monat (wir haben neue Laptop bekommen) das Protokoll von UDP auf TCP umgestellt haben. Die Performance auf VPN wurde dadurch nicht besser. Wir haben davor Tests mit verschiedenen Providern gemacht (was in der Stadt SG so an freier WLAN verfügbar war) und kamen auf deutlich bessere Werte (50-100MBit/s war zu erreichen).

ich habe dem IT-Dienstleister den Link zu diesem Beitrag zugestellt, bin gespannt, ob er damit was anfangen kann.

hier noch die aktuellste Messung: (RTT ist unter dem von GrandDixence genannten Wert von 25ms)

Nino_52

Hi @GrandDixence,

was Du da schreibst, ist ja soweit interessant, NUR -
wenn ich das Posting @Nidi_0179 lese, habe ich meine Zweifel, dass er:

das alles versteht was Du hier auftzeigst
dass er damit sein Problem in den Griff kriegt

Das Ganze liegt doch der Tatsache zugrunde, dass ein HomeOfficeUser in der Regel nicht das Rüstzeug hat in die Tiefen der Kommunikationstechnik einzutauchen.
Zumeist ist die VPN-Tunnellösung durch die IT des Betriebes bereitgestellt. Der User kann wenig bis gar nichts an der Applikation ändern oder anpassen.
Wenn die IT-Lösung für erhähte Sicherheit gut aufgebaut ist, wird ein User nicht einmal einsehen können welcher Art der Tunnel überhaup ist!
Er wirde eine Maske haben, welche er auszufüllen hat. Der Tunnelaufbau wird anschliessend ohne sein weiteres Zutun automatisch erfolgen….
Darum ist es meines Erachtens ziemlich müssig über TCP oder UDP überhaupt zu diskutieren. Da wird die IT ihre eigenen Überlegungen gemacht haben und die Wahl ihren Anforderungen entsprechend aufgesetzt haben.
Das Problem der User ist ja nicht gangbare Wege zu Manipulation zu finden, sondern die Trägheit im HomeOffice ihrer Verbindung zum Host.

Gruss Nino

pato

Nidi_0179 Noch ein Zusatz zum RTT, wichtig ist die Zeit von deinem PC zum VPN Gateway. Falls der aber innerhalb der Schweiz ist, sollte der knapp unter 25 ms liegen (ausser es liegt irgendwo eine hohe Belastung vor).

pato

Häufig ist TCP die Default Einstellung, da sie einfacher durch Firewalls kommt (sieht aus wie normaler HTTPS Traffic).
Ich habe jedoch gerade noch folgenden Thread gefunden:
https://community.sophos.com/xg-firewall/f/discussions/121014/poor-ssl-vpn-performance-when-using-tcp
So wie es scheint gibt es einen Bug in diversen Sophos VPN Versionen, welche zu stark reduzierten TCP Geschwindigkeiten führt. Sollte ab den Versionen 18.0.2 und 17.5.14 vor wenigen Monaten behoben worden sein. Dies wäre sicherlich auch noch prüfenswert durch die IT.

Nidi_0179

Habe mal Pingzeiten gemessen:

Ping zum AD ist deutlich schlechter:

Latenzzeit 45ms:

werde über Mittag mal über einen anderen Provider testen

GrandDixence

pato
Die Aussagekraft der Ping-Messungen ist sehr hoch. Es wird modernes “Split Tunneling” eingesetzt.
https://de.wikipedia.org/wiki/Split_Tunneling

# route -4 print
Gibt unter Windows gerne Auskunft, ob der aktuell aktive VPN-Tunnel “Split Tunneling” einsetzt oder nicht.
https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-intelligent-contact-management-enterprise/20524-route-command.html

Ohne den Einsatz von “Split Tunneling” enthält die Routingtabelle einen Eintrag “Default route” (0.0.0.0/0) für den Transport der IPv4-Datenpakete durch den VPN-Tunnel.
https://de.wikipedia.org/wiki/Routingtabelle

https://en.wikipedia.org/wiki/Default_route

Aktive VPN-Tunneln werden unter Windows gerne als “virtuelle Netzwerkkarte” eingebunden.

Aus den Ping-Messungen kann ich entnehmen, dass die minimale Paketumlaufzeit (RTT) zum VPN-Server:

am EuroDOCSIS-Internetanschluss (UPC-Sunrise) < 27 ms
am Glasfaser-Internetanschluss (ISP unbekannt) < 8 ms

beträgt.

Nidi_0179
Die mit Ping gemessenen maximalen Paketumlaufzeiten (RTT) (zum Server 8.8.8.8) für den Internetanschluss von UPC-Sunrise (EuroDOCSIS) sind zu hoch.

Adaptive Ping-Messungen zum Server tick.switch.ch durchführen bei unbelasteten Internetanschluss. Siehe dazu die entsprechenden Hinweise in der “Allgemeinen Fehlersuche” (Beitrag Nr. 3):
https://community.sunrise.ch/d/8569-gigaconnect-aussetzer/25

Keine Ping-Messungen über WLAN/WiFi oder PowerLAN durchführen!

Hier Vergleichswerte von einem einwandfrei funktionierenden Internetanschluss von UPC-Sunrise (EuroDOCSIS 3.0; Bridge-Modus).

# ping -A -c 25000 tick.switch.ch
— tick.switch.ch ping statistics —
25000 packets transmitted, 25000 received, 0% packet loss, time 285846ms
rtt min/avg/max/mdev = 8.631/11.301/22.585/1.241 ms, pipe 2, ipg/ewma 11.434/11.084 ms

Ping-Messungen auf Anycast-Adressen (zum Beispiel: 8.8.8.8) sind generell nicht zu empfehlen:
https://de.wikipedia.org/wiki/Anycast

Hier trotzdem die Vergleichswerte (EuroDOCSIS 3.0; Bridge-Modus):
# ping -A -c 10000 8.8.8.8
10000 packets transmitted, 10000 received, 0% packet loss, time 117323ms
rtt min/avg/max/mdev = 7.215/11.565/22.996/1.274 ms, pipe 3, ipg/ewma 11.733/11.494 ms

Die zwingend erforderliche, zeitaufwendige Aufbereitung der im Fernsehkabelnetz zu übertragendenen Datenpakete im CMTS und EuroDOCSIS-Kabelmodem erhöht die Paketumlaufzeit bei einem Internetanschluss über das Fernsehkabelnetz (EuroDOCSIS) um rund 8 Millisekunden gegenüber einem Glasfaseranschluss (FTTH + AON). => Auf die Grafik klicken oder tippen zum Vergrössern!

https://mobilecommunity.ch/wbb/index.php?thread/326-salt-fiber-oder-salt-unlimited-surf-f%C3%BCr-heimnetzwerk/&postID=2526&highlight=paketumlaufzeit#post2526

https://michael.stapelberg.ch/posts/2014-09-05-fiber7_performance/

=> Man vergleiche die Messwerte der Ping-Messungen von Beitrag Nr. 21 vom 15.03.2021 13:18 Uhr (Glasfaseranschluss) mit den Messwerten der Ping-Messungen von Beitrag Nr. 20 vom 15.03.2021 10:54 Uhr (EuroDOCSIS).

Die zu hohen Paketumlaufzeiten (> 25 ms) am EuroDOCSIS-Internetanschluss könnten durch eine mit den schnellen Datenübertragungsraten des Internetanschlusses überforderte Hardware-Firewall/Router verursacht werden. => Verletzung Gute-Performance-Regel Nr. 5.
https://community.sunrise.ch/d/4397-diagnose-tool-der-connect-box-sagt-ihr-heim-netzwerk-hat-derzeit-einige-probl/27

Weiter benötigt der VPN-Server und/oder VPN-Client beim Einsatz des EuroDOCSIS-Internetanschlusses zu viel Zeit für die Verarbeitung (zum Beispiel: Verschlüsselung, Entschlüsselung) der VPN-Datenpakete.

=> Man vergleiche die Zeitdifferenzen der Messwerte der Ping-Messungen vom AD zum 8.8.8.8. Die grossen Zeitdifferenzen der minimalen Paketumlaufzeiten vom AD gegenüber 8.8.8.8 (17 ms versus 5 ms) deuten darauf hin, dass die durch den VPN-Tunnel geschleusten Datenpakete beim Einsatz des EuroDOCSIS-Internetanschlusses (UPC-Sunrise) wahrscheinlich fragmentiert wurden. Beim Einsatz des Glasfaseranschlusses wurden die durch den VPN-Tunnel transportierten Datenpakete wahrscheinlich nicht fragmentiert. IP-Fragmentierung kostet viel Rechenzeit und ist deshalb Gift für die Performance!
https://de.wikipedia.org/wiki/IP-Fragmentierung

Kontrollieren, ob alle “Gute Performance-Regeln” eingehalten werden. Insbesondere Regel Nr. 1 (Bridge-Modus)!
https://community.sunrise.ch/d/4397-diagnose-tool-der-connect-box-sagt-ihr-heim-netzwerk-hat-derzeit-einige-probl/27

Nidi_0179

Test mit meinem Laptop beim anderen Privider:

Ping deutlich tiefer (Faktor 3-4), Latenz gleich

pato

Nidi_0179 Der Ping ist wichtig ohne aktives VPN, sonst hält sich die Aussagekraft stark in Grenzen.
Wichtig wäre ein Ping von dir, ohne VPN aktiv, zum VPN Gateway. Der müsste unter 25ms liegen für optimale Geschwindigkeit mit TCP.

Nidi_0179

pato Leider antwortet die Firewall (VPN-Gateway) nicht auf Ping, sowohl mit als auch ohne VPN (Sicherheitseinstellung) 🙁
mit aktivem VPN kann ich nur die Firmeninfrastruktur (Server etc.) anpingen.

pato

Nidi_0179 OOhhh hier könnte noch eine weitere Ursache der Performance zu finden sein.
Dies müsste aber dein Admin anschauen. Für MSS, PMTUD und TCP Sliding Window muss die Firewall korrekt auf gewisse ICMP Pakete antworten. Dies ist zwar nicht Ping, aber oftmals wird gleich alles ICMP blockiert. Dann funktionieren aber eben diese extrem wichtigen Features auch nicht mehr. Könnte mit einem Wireshark wie von GrandDixence festgestellt werden. Dazu kenne ich aber die Innereien einer Sophos zu wenig. Bei einer Cisco muss dies zum Beispiel erlaubt werden, damit dies korrekt funktioniert.
Details für deinen Admin hier: https://support.sophos.com/support/s/article/KB-000037153?language=en_US

Nidi_0179

Wenn die Einstellung der FW vor dem Server ein Performance-Thema sein soll, dann sei die Frage erlaubt, weshalb die VPN-Verbindung mit dem gleichen Laptop, auf den gleichen Server (FW) mit den gleichen Einstellungen/Protokoll etc. über einen anderen Provider deutlich schneller ist?

pato

Nidi_0179 Ich vermute hier mehrere Ursachen. Latenz Unterschiede zwischen den Anbietern (unterschiedliches Peering zum Beispiel) gepaart mit weiteren Einstellungen.

Nidi_0179

GrandDixence also der Reihe nach:

Connect Box ist im Bridge Mode
Tests wurden alle mit Kabel (kein WLAN, PowerLAN kommt mir nicht ins Haus) gemacht
An der Firewall kann’s nicht liegen, habe für Tests das Laptop mal direkt an der Connect Box angeschlossen
Die Statusmeldung der Connect Box sieht so aus:

finde keinen Punkt, der eine “Diagnose” aufrufen kann, die ein Resultat wie im Link https://community.sunrise.ch/d/4397-diagnose-tool-der-connect-box-sagt-ihr-heim-netzwerk-hat-derzeit-einige-probl zeigen würde
(Das Menu im Bridge Mode ist ziemlich bescheiden)
der andere ISP bei dem ich die Tests gemacht habe ist SAK
Downstream zeigt 24 verbundene Kanäle, Signalstärke 0 oder 1 dBmv, SNR 35 oder 36 db, Modulation 246qam
Upstream zeigt 6 verbundene Kanäle:
Konfiguration:
Quartierinstallation (Fernsehkabel): 2016/2017 wurde das ganze Quartier neu verkabelt. Bis dahin war es eine uralte Rediffusion-Installation

Nidi_0179

Ergebnisse vom Pingtest (letzte Nacht, es war niemand mehr online) :

der vorgeschlagene ping-Befehl liefert:

funktioniert hat:

heute Morgen (ist noch keiner online):
ohne aktiven VPN: “tick.switch.ch”:

mit aktivem VPN:
“tick.switch.ch”

VPN-Kanal:

Nidi_0179

Ping-Test VPN (ab 11.00 Uhr im vollen Betrieb)

Der Durchschnittswert ist praktisch unverändert.

Nidi_0179

Speed-Test + Pink-Test in der Firma (FL1 symetrisch 500MBit/s - Glasfaser) während Team-Meeting mit 16 Teilnehmern, wobei die Hälfte im Home-Office:
DELETED

Nidi_0179

Hallo Zusammen
unser IT-Dienstleister hat weitere Tests durchgeführt (Mitarbeiter zu Hause)

UPC - Giga - Gigabox (Fernsehkabel):
ping tick.switch.ch Minimum = 9ms, Maximum = 58ms, Average = 15ms
ping VPN (10.15.31.10) Minimum = 26ms, Maximum = 140ms, Average = 36ms
SAK (300/300 Glas) - Fritzbox
ping 8.8.8.8 Minimum = 4ms, Maximum = 14ms, Average = 4ms
ping VPN (10.15.31.10) Minimum = 8ms, Maximum = 33ms, Average = 9ms

pato

Nidi_0179 Das Peering (und eventuell die Technologie) von UPC zur Firma ist etwas langsamer (_26ms) als das von SAK (_8ms), dies macht wohl den Unterschied fürs VPN aus.

Nidi_0179

so wie es aussieht ist der Flaschenhals:

Connect Box / Giga Box + Fernsehkabel + UPC (bei mir bzw. beim Mitarbeiter vom IT-Dienstleister)
Sunrise Internet Box + Sunrise (beim Kollegen)
das heisst für den User gibt es keine Möglichkeiten etwas zu verbessern
Das hatte ich befürchtet 🙁

pato

Nidi_0179 Ich sehe im Moment nicht wirklich eine Möglichkeit auf deiner Seite. Eher vielleicht beim VPN Gateway selbst.

« Vorherige Seite Nächste Seite »