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!

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.

GrandDixence

Gemäss:
https://ux.cnlab.ch/speedtest/Controller?page=UserReport&userid=**DELETED**
wird für den Internetanschluss der Firma (DELETED?) die öffentliche IPv4-Adresse DELETED des ISP Telecom Liechtenstein (https://fl1.li/de) verwendet. Unter https://DELETED antwortet ein VPN-Server, welcher unter der Verantwortung von roman.krapf@netsafe.ch steht.

Gemäss Traceroute ab einem einwandfrei funktionierenden EuroDOCSIS-Internetanschluss von UPC-Sunrise:

$ traceroute -I DELETED

traceroute to DELETED (DELETED), 30 hops max, 60 byte packets
1 * * *
2 46-126-136-1.dynamic.hispeed.ch (46.126.136.1) 9.590 ms 9.565 ms 9.558 ms
3 46.140.5.73 (46.140.5.73) 8.853 ms 8.846 ms 8.839 ms
4 ch-zrh03a-rc1-ae-53-0.aorta.net (84.116.200.233) 10.737 ms 10.730 ms 10.722 ms
5 ch-zrh01b-ra1-ae-1-0.aorta.net (84.116.134.142) 10.397 ms 10.389 ms 10.373 ms
6 ae-4.bar1.Zurich3.Level3.net (4.68.75.81) 21.304 ms 12.460 ms 12.421 ms
7 ae-2-2.bar2.Zurich3.Level3.net (4.69.148.18) 9.477 ms 10.885 ms 10.847 ms
8 TELECOM-LIE.bar2.Zurich3.Level3.net (213.242.82.86) 26.303 ms 25.466 ms 25.427 ms
9 217-173-230-0.cmts.powersurf.li (217.173.230.0) 24.448 ms 24.208 ms 24.169 ms
10 * * *
11 DELETED (DELETED) 26.890 ms 30.447 ms 30.409 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *

wandern die verschlüsselten Datenpakete des VPN-Tunnels beim HomeOffice an einem UPC-Sunrise-EuroDOCSIS-Internetanschluss durch das Backbone-Netzwerk von UPC-Sunrise (aorta.net) nach Zürich. In Zürich werden diese Datenpakete von Level3 übernommen. Level3 ist ein Tier1-Netzwerkanbieter.
https://de.wikipedia.org/wiki/Tier_(Netzwerke)

https://de.wikipedia.org/wiki/Level_3_Communications

Level3 ist ebenfalls ein Tier1-Netzwerkanbieter von Telecom Liechtenstein. So wechseln die Datenpakete von Level3 in das Backbone-Netzwerk von Telecom Liechtenstein (powersurf.li).

Ich messe mit Wireshark (-> siehe oben stehender Beitrag) am einwandfrei funktionierenden EuroDOCSIS-Internetanschluss von UPC-Sunrise per HTTPS eine Paketumlaufzeit von 26 ms zum VPN-Server 89.248.159.86. Somit könnten die vom IT-Dienstleister (Netsafe?) durchgeführten Ping-Messungen korrekt sein.

Um Peering-Probleme ausschliessen zu können, empfehle ich:

a) Die Wiederholung der Ping-Messungen ohne bestehenden VPN-Tunnel vom EuroDOCSIS-Internetanschluss von UPC-Sunrise zum Internetanschluss der Firma. Damit ein allfälliger negativer Einfluss des VPN-Tunnels ausgeschlossen werden kann. Dazu muss einseitig die Firewall temporär umkonfiguriert werden, damit die Firewall ein einkommendes Ping mit einem Pong beantwortet. Resultate dieser Ping-Messungen hier veröffentlichen.
https://de.wikipedia.org/wiki/Ping_(Daten%C3%BCbertragung)

b) Danach sollte die Netzwerkverbindung vom EuroDOCSIS-Internetanschluss von UPC-Sunrise zum Internetanschluss der Firma mit einem passenden Messwerkzeug (zum Beispiel: IPerf3) mit mehreren TCP-Messungen (über IPv4) ausgemessen werden. Resultate dieser IPerf3-Messungen hier vollständig veröffentlichen. Wichtig: Die Messungen sind wiederum ohne bestehenden VPN-Tunnel durchzuführen.

c) Abzuklären, ob der VPN-Server (https://DELETED) nur IPv4 unterstützt oder ob dieser VPN-Server auch IPv6 unterstützt. Antwort bitte hier veröffentlichen.

Für die Ping-Messungen und IPerf3-Messungen siehe die Angaben in der “Allgemeine Fehlersuche” und den darin verlinkten Beiträge.
https://community.sunrise.ch/d/8569-gigaconnect-aussetzer/25

Ein guter Einstieg ins Thema “Peering-Probleme” bietet:
https://community.sunrise.ch/d/7741-lahme-verbindung-hohe-pings-zu-init7

Können Peering-Probleme ausgeschlossen werden, sollte die Fehlersuche (durch den IT-Dienstleister mit Hilfe von Wireshark) auf eine Fehlkonfiguration, Fehlfunktion oder Überlastung einer Netzwerkkomponente im Firmennetzwerk fokusiert werden. Unter der Bedingung natürlich, dass vorgängig kontrolliert wurde, ob alle Gute Performance-Regeln eingehalten werden:
https://community.sunrise.ch/d/4397-diagnose-tool-der-connect-box-sagt-ihr-heim-netzwerk-hat-derzeit-einige-probl/27

Nidi_0179

GrandDixence ich bin überrascht, dass mit der userid alle Informationen öffentlich zugänglich sind.
Leider kann ich das gepostete Bild nicht mehr löschen, schliesslich habe ich die IP-Adresse nicht zufällig geschwärzt. Bitte alle firmenspezifischen Informationen (Namen, IP-Adresse, Link zum cnlab etc.) im letzten Eintrag löschen, danke 🙂

GrandDixence

Nidi_0179
Ich kann meinen eigenen Beitrag nicht (mehr) editieren.

pato

@Daniele_Sunrise könntest du hier vielleicht eine kleine Bereinigung machen, wie durch Nidi gewünscht?

Daniele_Sunrise

@Nidi_0179 @GrandDixence @pato Ich habe soeben das Bild gelöscht und die Beiträge angepasst.

Liebe Grüsse
Daniele

Nidi_0179

FW temporär umkonfiguriert (Ping)
Ping-Messung (Internetanschluss von UPC-Sunrise zum Internetanschluss der Firma)
ohne VPN-Tunnel:

mit VPN-Tunnel:

=> kein negativer Einfluss vom VPN-Tunnel

Ping-Messung (Internetanschluss von UPC-Sunrise zum VPN-Server der Firma)

=> Mittelwert +/- gleich, aber viel höher als beim SAK-Anschluss (8ms, siehe Post vom 15.März)

Ping auf switch:

traceroute tick.switch.ch

verglichen mit traceroute “Firmenanschluss”

es auf, dass die ersten 12 .. 13 ms bereits bis zum 195.202.200.1 anfallen (UPC-Sunrise)

dann kommen nochmals 13ms beim Übergang auf TELECOM-LIE … dazu (Peering)

Aus meiner Sicht 2 Baustellen:

Modem/Technologie UPC-Sunrise-Anschluss
Peering auf Liechtenstein

Heisst unter dem Strich: für den User nicht lösbar

Ist insofern ärgerlich, dass ich ein 600/60er Abo habe:
für den allgemeinen Gebrauch habe ich die volle Bandbreite (passt)
aber zum Arbeiten auf dem Firmenserver sind nur 10/10 MBit nutzbar (ist schon langsam).

Wir sprechen hier ja nicht von ein paar Prozent Reduktion sondern von nur 16% Nutzbarkeit.

3 Möglichkeiten:

damit leben (unschön)
Anbieter wechseln
(will ich nicht, weil sonst alles funktioniert und UPC gewisse Vorteile im Gesamtpaket hat)
zusätzlichen zu UPC einen Anbieter für’s Arbeiten
(extra Kosten von CHF 600 - 800 pro Jahr, für 2 Tage pro Woche Home-Office)

Nidi_0179

Test (traceroute “Firmenanschluss”) beim Kollegen mit Sunrise Glas (1GB/1GBMBit-Abo)

2x Übergänge auf andere Netze (Peering) mit massiven Anstiegen
korrespondiert mit Ping zum VPN-Server: auch ca 26 .. 30ms

pato

Nidi_0179 Danke für die vielen Tests.
Es gibt hier noch ein etwas besseres Tool:
https://elifulkerson.com/projects/mturoute.php
Dort einfach die .exe Datei in ein Verzeichnis herunterladen, zum Beispiel c:\temp\ und dann über ein cmd mit dem Befehl:
c:\temp\mturoute.exe -f ipadressedeshosts
Sieht dann in etwa so aus:
`C:\Temp>mturoute.exe -f www.heise.de

ICMP Fragmentation is permitted. *
Speed optimization is enabled. *
Maximum payload is 10000 bytes. *
ICMP payload of 1472 bytes succeeded.
…- ICMP payload of 1473 bytes failed. (IP_REQ_TIMED_OUT)
Max ping: 1500 bytes.
`
Dieses Tool prüft die maximale MTU die mit/ohne Tunnel möglich ist.
Für weitere Tests ob MSS und TCP Sliding Window korrekt über den Tunnel funktioniert ist jedoch ein Wireshark Traffic Capture notwendig. Dies ist aber ein wenig heikel, da dort auch Geschäftsdaten (aber hoffentlich verschlüsselt) darin enthalten sein könnten. Ich weiss nicht ob du dies möchtest.

Nidi_0179

ich mache vorerst mal ein paar Test mit target - IP (mit CH-Provider)
Test (traceroute “METANET”) beim Kollegen mit Sunrise Glas (1GB/1GBMBit-Abo):

“Route” bleibt in CH: kein Peering zu FL1 => Zeit “halbiert”

Nidi_0179

mturoute -t (UPC -> Firma) ohne VPN

FW-Einstellungen:
Firma:

zu hause:

traceroute auf “Telefonanschluss” der Firma:

pato

Nidi_0179 Danke. Es sieht so aus als ob da noch eine Firewall oder ähnliches zwischen den letzten zwei IPs beim mturoute hängt. Nach ein bisschen probieren habe ich die gleichen Resultate bekommen. Jedenfalls ist da noch irgendwo ein Gerät welches die MTU auf mickrige 1006 bytes reduziert. Dann kommt noch der VPN Tunnel dazu und reduziert dieses nochmals um weitere 20-30 bytes.
Also nur schon deswegen hast du eher schlechte Geschwindigkeiten.
Was aber spannend ist, wenn ich die MTU hier teste http://www.letmecheck.it/mtu-test.php bekomme ich eine massiv bessere von 1491 (aber noch immer keine 1500). Abzüglich Header und Möglichkeit Division von 8, ergibt das eine Payload Size von 1456.
Spannend finde ich jedoch gewisse Unterschiede beim Modus mit -t und ohne.
Als erstes würde ich nun beim WAN Interface des Routers in Lichtenstein die MTU auf 1484 setzen. Dies führt zu einem kurzen Unterbruch, da mindestens das Interface, eventuell der Router, neu Starten muss. Dies sollte wenigstens die Fragmentierung etwas reduzieren und schonmal etwas helfen.
Zum Vergleich auf www.heis.de von meinem UPC Anschluss aus und wie es aussehen sollte:
`mturoute -t www.heise.de
mturoute to www.heise.de, 30 hops max, variable sized packets

ICMP Fragmentation is not permitted. *
Speed optimization is enabled. *
Maximum payload is 10000 bytes. *
1 +- host: 192.168.1.1 max: 1500 bytes
2 +- host: 84.74.192.1 max: 1500 bytes
3 +- host: 217.168.57.213 max: 1500 bytes
4 …-.- host: 84.116.200.241 not responding
5 +- host: 84.116.134.142 max: 1500 bytes
6 +- host: 4.68.75.81 max: 1500 bytes
7 +- host: 4.69.163.106 max: 1500 bytes
8 +- host: 212.162.24.58 max: 1500 bytes
9 +- host: 82.98.102.7 max: 1500 bytes
10 +- host: 82.98.102.23 max: 1500 bytes
11 .-.- host: 212.19.61.13 not responding
12 +- host: 193.99.144.85 max: 1500 bytes`

GrandDixence

Aus den nicht zensierten Angaben kann man entnehmen, dass die Path-MTU < 1500 Byte ist.
https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

Wegen der ausgiebigen Zensur ist nicht ersichtlich, wo genau die Path-MTU-Reduktion < 1500 Byte erfolgt. Diese Reduktion muss aber gemäss den nicht zensierten IP-Adressen im Firmennetzwerk oder beim ISP Telecom Liechtenstein erfolgen. Zensurbedingt ist auch keine Verifikation der durchgeführten Path-MTU-Messungen möglich.

Für mehr Informationen zum Thema “Path-MTU” siehe Gute Performance Regel Nr. 1 und Nr. 18.
https://community.sunrise.ch/d/4397-diagnose-tool-der-connect-box-sagt-ihr-heim-netzwerk-hat-derzeit-einige-probl/27

Nidi_0179

Performance unverändert:

Ergänzung:
aktuell ist MTU auf 1484 und Ping ist “on”
Mache über mittag mal den mturoute vom SAK-Anschluss aus
bin gespannt auf das Ergebnis 🙂

Nidi_0179

habe mal meine FW auf MTU 1350 gestellt (hab ich aus einem den vernetzten Beiträge)

dann bekomme ich:

LAN-Speed: (Schreiben gleich, lesen schlechter)

im Moment ist die Leitung eh langsam:

Nidi_0179

http://www.letmecheck.it/mtu-test.php liefert:

aber die Firme-FW ist auf MTU 1484 (siehe oben)

pato

Irgendwo ist noch irgendwas komisches, dass hier einschränkt.
Aktuell scheint aber deine Leitung in der Tat langsam, dort sollte es eigentlich stabile 600 Mbit/s liefern. Aktuell sind es also zwei mögliche Probleme.

« Vorherige Seite Nächste Seite »