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

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

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`

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.

Nidi_0179

tests am SAK 20/20-Anschluss:
(konnte nur über WLAN testen, ich hätte sonst die USB-C-Dockingstation von zuhause mitnehmen müssen, mein NB hat keinen RJ45-Anschluss mehr)

MTU auch 1006
LAN-Speed 22 bzw 18 Mbps (doppelt so hoch wie zu hause)

GrandDixence

Die Path-MTU von einem regulären EuroDOCSIS-Internetanschluss von UPC-Sunrise zum Rechner 89.248.158.86 beträgt 552 Byte. Die MTU-Reduktion von 1500 Byte auf 552 Byte erfolgt beim Router 217.173.230.1. Dieser Router schickt eine entsprechende ICMP-Mitteilung (Type 3: Destination Unreachable -> Code 4: Fragmentation required, and DF flag set):
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

$ ping -M do -s 1472 89.248.158.162 -c 3
PING 89.248.158.162 (89.248.158.162) 1472(1500) bytes of data.
From 217.173.230.1 icmp_seq=1 Frag needed and DF set (mtu = 0)
ping: local error: Message too long, mtu=552
ping: local error: Message too long, mtu=552

$ ping -M do -s 1472 217.173.230.1 -c 3
PING 217.173.230.1 (217.173.230.1) 1472(1500) bytes of data.
1480 bytes from 217.173.230.1: icmp_seq=1 ttl=53 time=26.6 ms
1480 bytes from 217.173.230.1: icmp_seq=2 ttl=53 time=27.2 ms
1480 bytes from 217.173.230.1: icmp_seq=3 ttl=53 time=27.2 ms

— 217.173.230.1 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 26.676/27.051/27.251/0.326 ms

Gemäss Whois gehört dieser Router zum IP-Adressbereich des ISP “Telecom Liechtenstein”.
https://www.heise.de/netze/tools/whois/

Somit ist dieses Problem bei der IT der Firma oder direkt beim ISP “Telecom Liechtenstein” zu platzieren.

$ traceroute -I 89.248.158.162
traceroute to 89.248.158.162 (89.248.158.162), 30 hops max, 60 byte packets
1 * * *
2 46-126-136-1.dynamic.hispeed.ch (46.126.136.1) 10.106 ms 10.736 ms 10.732 ms
3 46.140.5.73 (46.140.5.73) 9.228 ms 9.225 ms 9.221 ms
4 ch-zrh03a-rc1-ae-53-0.aorta.net (84.116.200.233) 12.236 ms 12.200 ms 12.196 ms
5 ch-zrh01b-ra1-ae-1-0.aorta.net (84.116.134.142) 11.534 ms 11.530 ms 11.526 ms
6 ae-4.bar1.Zurich3.Level3.net (4.68.75.81) 23.592 ms 14.380 ms 14.350 ms
7 ae-2-2.bar2.Zurich3.Level3.net (4.69.148.18) 12.866 ms 12.058 ms 11.428 ms
8 TELECOM-LIE.bar2.Zurich3.Level3.net (213.242.82.86) 25.186 ms 24.350 ms 24.324 ms
9 217-173-230-0.cmts.powersurf.li (217.173.230.0) 24.303 ms 24.704 ms 24.679 ms
10 * * *
11 89.248.158.162 (89.248.158.162) 27.189 ms 27.168 ms 27.147 ms

Eine MTU < 1000 Byte ist für einen Schweizer oder Liechtensteiner Internetanschluss klar inakzeptabel!

Nidi_0179

Danke für die Unterstützung.
ich werde mal bei FL1 reklamieren.
dazu Fragen:

wie bekomme ich bei SAK die doppelte Bandbreite mit dem gleichen MTU?
dieser Befehl “ping -M do -s 1472 217.173.230.1 -c 3” funktioniert unter Linux
gibt es das auch für WIN oder ein Tool, welches das kann?
kann ich diese Tests auch mit einer VM (mit Linux) machen, welches Linux wird empfohlen?

(ich würde das gerne nachvollziehen)

besten Dank 🙂

mein netz hat sich wieder beruhigt:

pato

Ich empfehle hier eher ein Linux USB Stick: https://linuxmint-installation-guide.readthedocs.io/en/latest/burn.html
Sonst kommen möglicherweise noch Virtualisierung Probleme dazwischen.

maxell182

Evtl kann man den Befehl über das WSL laufen lassen? Das ist ja eine Kernelschnittstelle.

Gruss maxell182

pato

maxell182 Also mit WSL 1.0 wollte es bei mir nicht, eventuell würde es mit WSL 2.0 aber funktionieren.

GrandDixence

dieser Befehl “ping -M do -s 1472 217.173.230.1 -c 3” funktioniert unter Linux
gibt es das auch für WIN oder ein Tool, welches das kann?

Ja, siehe den Wikipedia-Artikel zu “MTU”, welcher in meinem Beitrag vom 19.06.2021 21:21 Uhr referenziert ist.
https://community.sunrise.ch/d/14885-tiefe-bandbreite-bei-ssl-vpn-trotz-higspeed-anschluss/46

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

Mit einem Windows-Rechner:
<Windows-Taste>-<R>
“cmd” eingeben und “OK” betätigen.
$ ping -l 1472 -f 217.173.230.1 -n 3

-> Parameter “-l” -> klein “L” -> für length/Länge.

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/ping

https://de.wikipedia.org/wiki/Ping_(Daten%C3%BCbertragung)

Wer Lesen kann, ist klar im Vorteil…

pato

GrandDixence Der macht aber kein “-M do”, diese Funktion fehlt leider beim Windows Ping.

millernet

An meinem UPC Business Anschluss beträgt die maximal zulässige Segmentgrösse 1464 Bytes (ICMP MSS):
ping -D -s 1464 -c 3 89.248.158.86
PING 89.248.158.86 (89.248.158.86): 1464 data bytes
1472 bytes from 89.248.158.86: icmp_seq=0 ttl=50 time=53.149 ms
1472 bytes from 89.248.158.86: icmp_seq=1 ttl=50 time=50.779 ms
1472 bytes from 89.248.158.86: icmp_seq=2 ttl=50 time=48.021 ms

ping -D -s 1465 89.248.158.86
PING 89.248.158.86 (89.248.158.86): 1465 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

Gemessen über WLAN mit MacBook Air M1:

1 192.168.1.1 (192.168.1.1) 11.869 ms 4.335 ms 3.653 ms
2 xxxxxxx.static.cablecom.ch (xxxxxxxxxx) 4.470 ms 4.207 ms 5.108 ms
3 * * *
4 46.140.4.161 (46.140.4.161) 21.675 ms 15.961 ms 16.920 ms
5 carbrn101-be-2.aorta.net (84.116.211.17) 19.087 ms 18.062 ms 15.807 ms
6 ch-zrh03a-rc1-ae-53-0.aorta.net (84.116.200.233) 20.655 ms 16.096 ms 16.537 ms
7 ch-zrh01b-ra1-ae-1-0.aorta.net (84.116.134.142) 16.266 ms 16.945 ms 15.961 ms
8 ae-4.bar1.zurich3.level3.net (4.68.75.81) 21.037 ms 16.790 ms 26.949 ms
9 ae-2-2.bar2.zurich3.level3.net (4.69.148.18) 15.708 ms 16.940 ms 17.925 ms
10 telecom-lie.bar2.zurich3.level3.net (213.242.82.86) 30.073 ms 30.564 ms 32.045 ms
11 217.173.224.70 (217.173.224.70) 28.857 ms 31.724 ms 31.087 ms
12 217.173.224.69 (217.173.224.69) 30.416 ms 30.987 ms 29.980 ms
13 lag-en-vz-ipbb.ipc02.l-en-hb-037.bb.telecom.li (217.173.224.34) 30.970 ms 32.698 ms 34.267 ms
14 217.173.224.74 (217.173.224.74) 29.855 ms 33.623 ms 31.574 ms
15 89.248.158.86 (89.248.158.86) 42.666 ms 43.933 ms 42.660 ms

Aber: Auf den letzten Hop habe ich noch die vollen 1472 Bytes MSS

ping -D -s 1472 217.173.224.74
PING 217.173.224.74 (217.173.224.74): 1472 data bytes
1480 bytes from 217.173.224.74: icmp_seq=0 ttl=51 time=54.130 ms
1480 bytes from 217.173.224.74: icmp_seq=1 ttl=51 time=51.766 ms
1480 bytes from 217.173.224.74: icmp_seq=2 ttl=51 time=53.000 ms

Damit ist wohl die MTU der Firewall auf 1464 Byte + 28 Byte = 1492 Byte konfiguriert worden?

GrandDixence

millernet Damit ist wohl die MTU der Firewall auf 1464 Byte + 28 Byte = 1492 Byte konfiguriert worden?

Die MTU ab 217.173.230.1 wird dynamisch der Lastsituation entsprechen angepasst, einmal 552 Byte (meine Messung), bei der nächsten Messung 1492 Byte (Millernet’s Messung). Diese dynamische Anpassung der MTU hat fatale, negative Auswirkungen auf die Performance und Verfügbarkeit von jedem VPN-Tunnels auf den VPN-Server mit der IP-Adresse 89.248.158.86. Egal welcher Internetanschluss der/die FirmenmitarbeiterIn einsetzt!

Ein Beispiel einer solchen dynamischen Anpassung der MTU findet man unter:
https://www.lancom-forum.de/fragen-zur-lancom-systems-routern-und-gateways-f41/site2site-icmp-error-destination-unreachable-fragm-t18492.html

MSS ist ein Optionsfeld vom Netzwerkprotokoll TCP. UDP und ICMP kennen kein MSS!
https://de.wikipedia.org/wiki/Maximum_Segment_Size

Wenn hier die Rede von MTU ist, dann ist die MTU vom Netzwerkprotokoll IP gemeint.

Bitte die Begriffe MSS und MTU auseinander halten und klar unterscheiden. Danke!
https://www.dasblinkenlichten.com/the-basics-mtu-mss-gre-and-pmtu/

Noch einmal: Jeder Schweizer oder Liechtensteiner Internetanschluss ist mit einer Path-MTU von 1500 Byte zu betreiben. Siehe für mehr Informationen die (bereits genannten) “Gute Performance”-Regeln 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

Bei einer Path-MTU von 1500 Byte werden Pings mit einer Nutzdatenlast von 1472 Byte bei gesetztem “Do not fragment”-IP-Flag ordnungsgemäss beantwortet:

Windows:  # ping -f -l 1472 tick.switch.ch
Linux: # ping -M do -s 1472 -c 3 tick.switch.ch
MacOS: # ping -D -s 1472 -c 3 tick.switch.ch

GrandDixence

Amüsante Runde:

Parameter “-f” vom Boardmittel “ping” der Windows-Betriebssystemen hat die gleiche Wirkung (Versand eines “ICMP Echo Request” mit gesetztem “Do not fragment”-Flag) wie der Parameter “-M do” vom Boardmittel “ping” der Linux-Betriebssysteme. Wer es nicht glaubt, zeichnet den Netzwerkdatenverkehr auf und sieht sich die ICMP-Mitteilungen mit Wireshark an…

/f Specifies that echo Request messages are sent with the Do not Fragment flag in the IP header set to 1 (available on IPv4 only). The echo Request message can’t be fragmented by routers in the path to the destination. This parameter is useful for troubleshooting path Maximum Transmission Unit (PMTU) problems.
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/ping

$ man ping

-M hint
Select Path MTU Discovery strategy. hint may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag)

https://linux.die.net/man/8/ping

pato

GrandDixence Entschuldige, hast natürlich Recht. Hatte den “want” Teil gemeint, der könnte das Windows Ping nicht, das “do” jedoch geht natürlich.

millernet

GrandDixence Ja danke für die Korrektur.😁 Ich verdiene einige Layer über Ethernet und TCP/IP meine (vielen) Brötchen. CCNA wäre als schöne Grundlage schon länger in Planung. Aber die liebe Zeit…. die fehlt noch etwas.

pato

@Nidi_0179 Könntest du in den erweiterten Einstellungen nachschauen ob Support congestion signaling (ECN) aktiviert ist? Nach Sophos Forum kann dies ab und zu auch noch Probleme verursachen. Einfach zum Testen mal aus- oder einstellen. Falls Der ISP dies nicht unterstützt (UPC unterstützt es zum Beispiel nicht) bringt diese Funktion nichts.
Bei dir in der Firma, hängt da noch irgend ein Gerät, Modem/Router, an der Firewall zwischen der Wand Dose vom Internetanbieter?

Nidi_0179

pato Ich denke, dass es da noch einen Router zwischen FW und Wand-Dose hat.
zum Begriff “ECN” habe ich im Handbuch der SOPHOS XG nichts gefunden. 🙁

« Vorherige Seite Nächste Seite »