Evtl. MTU Problem - Bräuchte mal einen Tipp...

[Raudi]

Hallo,

ich meinen Kabel Deutschland Tarif von Business 100 auf Business 100 Pro umgestellt, damit ich immer die gleiche IP bekomme. Daher haben die mein Hitron (Bridge Mode) gegen ein Compal getauscht.

Nun habe ich aber seit dem Austausch das Problem, dass ich über einen VPN Tunnel keine größeren Daten kopieren kann. Z.B. das Backup des Servers über den VPN funktioniert nicht mehr oder ich habe eben versucht ein Update eines ESXi Hosts durchzuführen und das klappte auch nicht.

Parallel habe ich noch einen normalen 200er Kabel Deutschland Anschluss an dem noch ein aktuelles Hitron hängt und ich habe den VPN einfach mal auf den Anschluss umgestellt. (1781EF+ mit 2 DSL Interfaces, einfach im VPN das Tag geändert) Das VMware Update klappte danach auf Anhieb und auch das Backup funktioniert wieder.

Ich vermute dass es irgendwas mit der MTU zu tun hat. An welcher Stelle sollte ich die MTU anpassen um die Pakete etwas zu verkleinern?

Bei einem Test mit "ping -l größe -f <öffentliche IP der VPN Gegenstelle>" kommt folgendes:

Ab 1473 Byte: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Ab 1431 Byte bis 1472 Byte: Zeitüberschreitung.
Bis 1430 Byte: Normale Ping Antwort.

Und wenn ich nun in der Firewall das ICMP über den 200er Anschluss raus schicke, bekomme ich bei 1472 Byte eine Antwort, was über den 100er Anschluss nicht klappt.

Wo passe ich die MTU am besten an? Ist das unter "Kommunikation/Protokolle/MTU-Liste..." die korrekte Stelle?

Oder könnte dass sogar noch ein anderes Problem sein?

Hat hier jemand Erfahrungen?

Viele Grüße
Stefan

[Raudi]

So, ich habe mal etwas getüftelt...

Nach dem ich in unter "Kommunikation/Protokolle/MTU" für die Gegenstelle eine MTU von 1430 eingetragen hatte konnte ich bis 1402 Byte pingen, bei allem darüber kam die Meldung es müsse fragmentiert werden. Achso 28 Byte Header vergessen, stimmt...

Dann habe ich also 1458 Byte als MTU angegeben und dann konnte ich bis 1430 pingen und bekam bei allen darüber die Meldung das fragmentiert werden müsse.

Also den VPN wieder umgestellt und ein Backup getestet. Klappt!

Eigentlich ist nun alles gut...

Oder hat noch jemand einen Hinweis für mich?

Ich denke mal ich werde meine Erfahrungen in der Kabel Deutschland Community schreiben, evtl. haben die ja ein Fehler in den Einstellungen des Compal Modems oder es ist wirklich generell so bei den Geräten, denn die Business Hotline hat da keine Informationen zu einer Speziellen MTU Größe.

Viele Grüße
Stefan

[Raudi]

In der Community schrieb einer dass ich über ein VPN gehen würde. Da habe ich mal geschaut und bei einem IP over Ethernet Tunnel bzw. MPLS muss man 42 Byte als Overhead bei der MTU abziehen, das wäre dann genau meine MTU von 1458...

Viele Grüße
Stefan

[GrandDixence]

Beim Einsatz von VPN-Lösungen über IPv4 mit zustandslosen Protokolle wie zum Beispiel:

- UDP => IPSec über NAT
- ESP (IP-Protokollnummer 50) => IPSec ohne NAT

muss auf jedem VPN-Endpunkt zwingend die zu verwendende MTU korrekt konfiguriert werden. Beim Einsatz von "Dual Stack Light" muss der MTU < 1433 auf beiden VPN-Endpunkte konfiguriert werden, wenn für die VPN-Verbindung IPv4 und ein zustandsloses Protokoll eingesetzt wird (z.B. IKEv1/IPSec oder IKEv2/IPSec).

VPN-Verbindungen mit dem Netzwerkprotokoll TCP benötigen keine händische MTU-Konfiguration auf dem VPN-Server bzw. VPN-Endpunkt, da dank dem Einsatz der Maximum Segment Size (MSS) die TCP- bzw. IP-Paketgrösse so gewählt wird, dass eine Aufteilung (Fragmentierung) der TCP- bzw. IP-Pakete nicht notwendig ist.

Zustandslose Protokolle wie UDP und ESP (IP-Protokollnummer 50) kennen keinen Mechanismus zur Feststellung der maximalen Paketgrösse. In den beschriebenen Fällen wird in der VPN-Verbindung eine Netzwerkkomponente (z.B. Firewall oder Router) eingesetzt, welche fragmentierte IP-Pakete blockiert oder wegen fragmentierten IP-Pakete Performance-Probleme verursacht. Bei LANCOM-Geräten muss die Firewall-Konfiguration /Setup/IP-Router/1-N-NAT/Fragmente kontrolliert werden.

Das MTU-Problem wird bei LCOS > 9.10 und IKEv2 durch den Einsatz der automatischen IKEv2-Fragmentierung gemäss RFC 7382 entschärft. Bei Dual Stack-Lite (DS-Lite) sollten für VPN-Tunneln mit IKE/IPSec ausschliesslich VPN-Endpunkte eingesetzt werden, welche IKEv2 und die automatische IKEv2-Fragmentierung gemäss RFC 7382 unterstützen.

[GrandDixence]

Bei einem Test mit "ping -l größe -f <öffentliche IP der VPN Gegenstelle>" kommt folgendes:

Ab 1473 Byte: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Ab 1431 Byte bis 1472 Byte: Zeitüberschreitung.
Bis 1430 Byte: Normale Ping Antwort.

Die MTU der Ethernetkarte beträgt 1500 Byte. Siehe auch:

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

Deshalb werden Pings > 1472 Byte Nutzdaten (effektiv > 1500 Byte) nicht akzeptiert. Bei > 1430 Byte werden die Pings vom Kabelmodem nicht versendet, da die MTU auf der Fernsehkabel-Schnittstelle offenbar 1458 Byte beträgt (Dual Stack Light?).

[Raudi]

Hallo,

wie ich bereits schrieb, kommt hier eine Art IP oder Ethernet Tunnel wie z.B. MPLS zum Einsatz, dieser hat 48 Byte Overhead:

Note: EoIP tunnel adds at least 42 byte overhead (8byte GRE + 14 byte Ethernet + 20 byte IP)

1500 minus 42 sind 1458, passt also...

Ich bekomme bei dem Anschluss auch keine normale Kabel-Deutschland Dynamische IP sondern irgendwie eine andere aus einem 185.19.x.x Pool, darauf habe ich nun sogar einen Reverse DNS... Ich denke mal daher der Aufwand, um eine IP aus einem anderen Bereich zu nutzen, der nicht für Dynamische Zugänge genutzt wird.

Schade nur dass die vom Support da keine Ahnung hatten, aber das Produkt mit der festen IP ist bei denen auch noch nicht so verbreitet...

Viele Grüße
Stefan