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!

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. 🙁

pato

Nidi_0179 Ich tendiere aktuell auf diesen Router als mögliche Fehlerquelle. Eventuell hat der noch irgendwelche Firewall Funktionen aktiv oder sogar irgend eine Fehlkonfiguration oder ein Bug. Eventuell hilft aber auch schon ein Neustart. Falls du da weitere Details (was für ein Gerät) in Erfahrung bringen könntest können wir nachschauen ob wir noch weitere Tips finden.

Nidi_0179

pato ch befürchte, dass der Router alleine nicht das Problem ist:
auf einem 50/50-SAK-Anschluss habe ich gerade Folgendes gemessen:

Nidi_0179

Habe noch Tests mit dem 2. Internetzugang der Telefonanlage (Swisscom) gemacht:
- als Client-Zugang auf FL1 (VPN-Ziel) => gute Bandbreite, MTU 1500
- als VPN-Ziel (UPC-Client und Sunrise-Client) => gute Bandbreite, MTU 1500

so wie es aussieht ist die Kombination aus Quelle und Ziel für die Performance entscheidend

Nidi_0179

Hallo Zusammen
Die Entscheidung ist gefallen:
FL1 fliegt raus, wir nutzen zukünftig den anderen Internetzugang (wird bis Ende Monat umgerüstet)

Schade an der ganzen Sache ist, dass man diese Probleme erst im Betrieb feststellt und in der Regel keinen Anschluss mit einem 2. Provider hat, bei dem man Vergleichsmessungen machen kann (da hatten wir schon Glück)

Danke an Alle, die einen Beitrag geleistet haben.

« Vorherige Seite