Ich versuche das Ganze jetzt einmal so zu erklären, daß es auch jeder versteht und um auch ein bisschen Licht ins Dunkle zu bringen.
Ich wollte mich nicht einfach damit zufriedengeben, daß die VPN-Verbindung nicht möglich ist, da ich ja mit meinem Notebook und mit einem Smartphone von der DSLITE Box aus den VPN Tunnel zur IPV4 Box aufbauen kann. Und da wird auch kein anderes Protokoll genommen.
Auf dem Notebook läuft der Fritz Fernzugang mit der erzeugten config Datei aus der Fritz! Fernzugangssoftware, womit auch die configs für die Boxen erzeugt werden und auf dem Smartphone habe ich den NCP VPN Client installiert. Beide Tunnel laufen tadellos.
Dann die berechtigte Frage:
Warum geht es da, und zwischen den beiden Boxen nicht ???
Um das Ganze zu analysieren musste ich mich auch erst einmal in die ganze Materie etwas einlesen.
Bei beiden Boxen wird das MSS Clamping-Verfahren (Maximum Segment Size) eingesetzt.
Dadurch wird der maximal mögliche MTU Wert automatisch ermittelt.
Dieser ist bei beiden Boxen 1500, IPV4 sowie DSLITE.
Jetzt kommt das wichtige:
Bei der IPV4 Box steht der MTU Wert 1500 komplett für IPV4 zur Verfügung, da ja IPV4 nicht getunnelt wird.
Bei der DSLite Box sieht es nun folgendermaßen aus:
IPv6: mtu 1500
IPv4: ds-lite only 2a02:908::b:4001 (de-pad09a-cr01.aftr.umkbw.net)
IPv4: ip 192.0.0.2 mask 0.0.0.0 gw 192.0.0.1 dhcp mtu 1460
Wie man hier sehen kann, ermittelt die Box die max. MTU von 1500, welche aber für IPV6 gilt.
Allerdings steht für IPV4 nur eine maximale MTU von 1460 zur Verfügung, das bekommt die Box
auch vom AFTR mitgeteilt, wie man in folgendem Log sehen kann:
21.08.16 16:26:46 Internetverbindung wurde erfolgreich hergestellt.
IPv4 wird über DS-Lite genutzt.
AFTR-Gateway: (de-pad09a-cr01.aftr.umkbw.net), IPv4-MTU: (1460)
Also weiß die DSLite Box, das für eine IPV4 Verbindung eine maximale MTU von 1460 möglich ist,
da sie ja auch für die lokalen IPV4 Clients eine MTU von 1460 zur Verfügung stellt.
Nun passiert beim Tunnelaufbau der beiden Boxen folgendes:
Beim aushandeln der maximal möglichen MTU meldet die IPV4 Box 1500, was ja auch richtig ist.
Allerdings greift die DSLite Box bei der übermittlung der max. möglichen MTU auf die per MSS Clamping-Verfahren ermittelten MTU zurück (1500 für IPV6) und nicht auf die vom AFTR-Gateway gemeldete MTU von 1460, welche auch für das lokale IPV4 Netz der DSLite Box gilt.
Genau das ist der Bug !!!
Die beiden Boxen einigen sich also beim Aufbau des Tunnels auf eine MTU von 1500.
Das kann man hier schön sehen:
XXXXXXXXXXXX.myfritz.net: pmtu 0 mtu 1500 dpd_supported dont_filter_netbios remote_nat
Richtig wäre aber eine MTU von 1460, da ja per IPV4 auf der DSLite Seite nicht mehr zur Verfügung steht.
Zur Erinnerung: IPV6 Protokoll = 40 Byte 1500-40=1460 Byte.
Durch diesen Umstand kommt es jetzt natürlich zur Fragmentierung der Pakete, welches eigentlich jeden Tunnel zerschießt.
Das kann man in folgendem Log sehr schön sehen:
2016-08-24 15:30:48 avmike:XXXXXXXXXXXX.myfritz.net
fehlerhafte Paketlaenge: Hdr-length > read-Data
Jetzt wird eigentlich auch der Rest logisch:
Vom Notebook und Smartphone klappt der Tunnel, da die Netzwerkadapter der Geräte von der DSLIte
Box für das lokale IPV4 Netz eine max. MTU von 1460 mitgeteilt bekommen.
Somit wird beim Tunnelaufbau eine max. MTU von 1460 ausgehandelt und die Paketdaten werden nicht mehr fragmentiert. Der Tunnel läuft sauber.
Wenn man nat_t deaktiviert, wird der Tunnel zwar aufgebaut, aber es fließen keine Daten.
Das ist auch logisch, da hier ESP als Protokoll portlos läuft und nicht in UDP gekapselt ist.
Dert Tunnel wird zwar aufgebaut, da beim Aushandeln der Verbindung keine großen Datenmengen fließen, aber die Nutzdaten werden verworfen, da sie fragmentiert sind.
Wenn nat_t aktiviert ist, bricht der Tunnel sofort wieder zusammen.
Das ist auch logisch, da hier ESP in UDT gekapselt ist und die Nutzdaten in den Tunnelaufbau mit reinfliessen.
Es gibt ja auch diverse Meldungen im Netz, daß der Tunnel zwar aufgebaut wird, aber keine Daten fließen.
Das ist genau der Fall, wenn auf mind. Einer Seite nat_t deaktiviert ist.
Dann gibt es Meldungen von Usern, die mit DSLite garkeine Probleme haben.
Das ist genau so richtig, die haben nämlich auf der IPV4 Seite, das scheint wohl Anbieterabhängig zu sein,
eine max. MTU, die kleiner ist, als die max. MTU, welche vom AFTR gemeldet wird. In diesem Fall also 1460 oder kleiner. Da läuft der Tunnel dann.
Was mich jetzt wirklich an dieser Geschichte wundert, ist, daß bisher niemand so richtig das VPN Problem mit DSLite Angegangen ist, da es ja schon länger besteht.
Alle Berichte hierzu, die man findet, enden irgendwann und es gibt keine Statusmeldung, ob das Problem gelöst wurde.
Alle diese Nutzer müssen wohl irgendwann resigniert haben.
Ich hoffe auch, daß das jetzt einigermaßen verständlich war.
Gruß Andreas
