Portsperren bei UM

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Forumsregeln
  • Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
  • Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Was haltet Ihr von den Sperren?

Voll in Ordnung. Sicherheit ist ein wichtiges Thema und beeinträchtigt mich ja auch nicht
17
19%
Voll in Ordnung. Aber warum weiss ich nichts davon? Sollte man schon *irgendwo* mitteilen
16
18%
Unverschämtheit. Ich brauche die Ports für xxx (bitte ein Beispiel posten bzw. erklären)
10
11%
Unverschämtheit. Brauche die Ports nicht, aber finde es aus Prinzip nicht in Ordnung.
41
46%
Kenne Ports und die Bedeutung nicht. Kann mich darum nicht äussern
1
1%
Kenne nur Port-Wein, also mir egal. *Prost*
3
3%
Ist mir egal / Keine Meinung zu
1
1%
 
Abstimmungen insgesamt: 89

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 07:42

Das Problem scheint mir eher hier zu liegen:

Dual-Stack Lite: VPN-Probleme via MTU-Wert lösen
Dienstag, 25. Aug. 2015 15:24 - [ar] - Quelle:Eigene
Viele Anwender mit Internetanschlüssen die auf Dual-Stack Lite setzen haben Probleme mit VPN-Verbindungen. Oftmals reicht die Reduzierung des MTU-Wertes für eine stabile Verbindung jedoch aus.
Viele Kabel- und Internet-Anbieter setzten derzeit auf das Dual-Stack-Lite-System, um nicht mehr jedem Anwender eine eindeutige IPv4-Adresse zuordnen zu müssen. Mittels geteilten IPv4-Adressen und eindeutigen IPv6-Adressen ist die Nutzung des Internets quasi genauso möglich wie mit einer herkömmlichen eindeutigen IPv4-Adresse.
Etwas schwieriger ist das Unterfangen, wenn der Anwender auf speziellere Lösungen wie eine VPN-Verbindung zurückgreifen muss. VPN-Verbindungen werden genutzt um sichere Verbindungen zwischen zwei Punkten im Netzwerk zu erstellen. Häufigster Einsatzzweck ist das klassische Home Office mit einer sicheren Verbindung zum Arbeitgeber oder auch eine sichere Verbindung in ein Universitäts-Netzwerk, um auf interne Ressource zurückgreifen zu können.
Mittels teuren Business-Paketen können die Internetanbieter die Kunden, welche auf VPN-Verbindungen angewiesen sind, zusätzliche Gebühren abverlangen. In vielen Fällen reicht allerdings bereits die Reduzierung des MTU-Werts bei der VPN-Verbindung, um diese stabil zum Laufen zu bringen.
Der MTU-Wert (Maximum Transmission Unit) bestimmt, wie groß das genutzte Protokoll der Vermittlungsschicht inklusive des Sicherungsthreads ausfallen darf. Der Standardwert bei Ethernet-Verbindungen liegt bei 1.500, bei PPPoE-Verbindungen bei 1492.
Das Problem bei der Verwendung von IPv6-Adressen ist, dass die Header der Vermittlungsschicht 40 Bytes groß sind, durch das Dual-Stack-Lite-System die VPN-Verbindung allerdings von einer IPv4-Adresse mit nur 20 Bytes ausgeht. Dies führt dazu, dass 20 Bytes verloren gehen. Dies wiederum hat zur Folge, dass eine VPN-Verbindung in einigen Fällen zwar aufgebaut werden kann, Daten allerdings nicht komplett bei der Gegenstelle ankommen oder nicht interpretiert werden können.
Mittels der Begrenzung des MTU-Wertes auf einen manuell festgelegten Wert unterhalb des maximalen MTU-Wertes des eigenen Anschlusses lässt sich dieses Problem einfach umgehen.
Einen ersten Eindruck ob der MTU-Wert reduziert werden muss, gibt der TPC-Analyser der Website SpeedGuide.net.
Sollte der MTU-Wert nicht für Breitband optimiert sein, hat sich bei uns ein MTU-Wert von 1.300 bis 1.432 als nutzbar herausgestellt. Mit einem MTU-Wert von 1.300 sollten auch Dual-Stack-Lite-Nutzer eine vernünftige VPN-Verbindung realisiert bekommen.
Bei der Verbindung via OpenVPN lässt sich der MTU-Wert mittels Befehl in der Konfigurationsdatei einfach selbst einstellen:
Dies dürfte bei den meisten Anwendern das Problem einer nicht funktionierenden VPN-Verbindung beheben, ganz ohne teuren Business-Anschluss. Das Problem der nicht Erreichbarkeit von einzelnen Ports über die IPv4-Adresse wird mit dem MTU-Wert bei Dual-Stack-Lite-Anschlüssen allerdings nicht behoben.


Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 08:11

Wie bekomme ich jetzt den beim VPN Verbindungsaufbau max. ermittelten MTU Wert (der wird beim Verbindungsaufbau in Phase 1 automatisch ermittelt) um die fehlenden 20 Byte reduziert?

Kann man das irgendwie in der vpn config einstellen?

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 08:23

Und dann gibt es ja auch noch den MTU Bug bei den Fritten mit FW < 6.50 welcher ja auch für den nicht laufenden SIXXS Tunnel verantwortlich war.
Die 6360 hat nämlich noch OS 6.33 drauf.

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

tq1199
Glasfaserstrecke
Beiträge: 1816
Registriert: 07.02.2014, 09:05

Re: Portsperren bei UM

Beitrag von tq1199 » 02.09.2016, 08:35

Andreas1969 hat geschrieben:Wie bekomme ich jetzt den beim VPN Verbindungsaufbau max. ermittelten MTU Wert ...?
Erstelle mit deiner FB6360 (mit konfiguriertem VPN) eine support- und export-Datei und suche in diesen Textdateien, nach dem String "mtu".
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 09:21

Aber es reicht doch nicht, einfach den MTU Wert der Box um 20 Byte zu reduzieren.
Die Differenz bleibt ja dann trotzdem bestehen, da IPV4 ja weiterhin über IPV6 getunneltes wird, nur mit 20 Byte weniger.
Es müsste ja der MTU Wert des VPN Tunnels selbst reduziert werden.

MTU Wert Tunnel = MTU Wert Box - 20 Byte

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

tq1199
Glasfaserstrecke
Beiträge: 1816
Registriert: 07.02.2014, 09:05

Re: Portsperren bei UM

Beitrag von tq1199 » 02.09.2016, 09:25

Andreas1969 hat geschrieben: Es müsste ja der MTU Wert des VPN Tunnels selbst reduziert werden.
Hast Du den (aktuellen, d. h. standard-) MTU-Wert des VPN-Tunnels, gefunden?
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 09:37

Der wird doch bei jedem Tunnelaufbau zwischen den Boxen ausgehandelt.
Ich hatte eben auch einen Knoten im Kopf.
Die Lösung wäre doch, den MTU Wert der 6490 (IPV4) zu verändern, nämlich genau 20 Byte weniger, als der MTU Wert des AFTR'S über welches die 6360 (DSLITE) angebunden ist. Dann sollte der Tunnelaufbau auch klappen.

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 13:35

Ich habe mir das jetzt mal genauer angeschaut.
Beide Boxen haben einen MTU Wert von 1500.
Das IP4- AFTR hat allerdings nur eine MTU von 1460.
Das ist ja auch logisch, da IP4 von der 6360 in IP6 getunnelte ist (IP6 Protokoll = 40 Byte).
Da aber VPN eine Paküetgröße von 1500 - 20 (IP4 Protokoll) = 1480 Byte aushandelt, werden die Pakete fragmentiert und sind unbrauchbar.
Über das AFTR können ja nur 1460-20 = 1440 Byte Pakete unfragmetiert übertragen werden.
Um das zu umgehen, gibt es nur 2 Lösungen :
Entweder configuriert man die Tunnel MTU fest auf 1440 Byte, aber wie geht das?
Oder man passt den MTU Wert in der 6490 (IPV4 only) auf 1460 an, wie kann man das machen?

Dann sollte der Tunnel laufen.

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

tq1199
Glasfaserstrecke
Beiträge: 1816
Registriert: 07.02.2014, 09:05

Re: Portsperren bei UM

Beitrag von tq1199 » 02.09.2016, 14:04

Andreas1969 hat geschrieben: Entweder configuriert man die Tunnel MTU fest auf 1440 Byte, aber wie geht das?
Oder man passt den MTU Wert in der 6490 (IPV4 only) auf 1460 an, wie kann man das machen?
Wenn das mit dem WEB-IF bzw. der VPN-config-Datei der FB nicht möglich ist, wäre es evtl. hilfreich, wenn Du anhand einer Sicherungsdatei (*.export-Datei) nachschauen würdest, wie bzw. wo der MTU-Wert für das VPN festgelegt ist.
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note


Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 17:21

So,
ich habe jetzt mal die Konfiguration und die Logs der Fritten auseinadergenommen.
Ich lag mit meiner Vermutung der fehlerhaften MTU Rate goldrichtig.
Hierbei handelt es sich um einen Bug in der FW der Boxen.
Die VPN Verbindung handelt den falschen MTU Wert aus.

Dadurch werden die Pakete fragmentiert und der Tunnel wird aufgrund einer falschen Paketlänge nach dem Aufbau sofort wieder abgebaut.

Wenn dieser Bug behoben ist, sollte auch die VPN Verbindung anstandslos laufen. Also ist eine VPN Verbindung zwischen 2 Boxen, auch wenn eine davon auf DSLITE läuft, möglich.
Es wäre natürlich eine Sauerei, wenn dieser Bug bekannt wäre und nicht behoben wird, damit die weiterhin die teureren Business Anschlüsse an den Mann bringen können.

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

F-orced-customer
Glasfaserstrecke
Beiträge: 1000
Registriert: 11.09.2012, 12:54

Re: Portsperren bei UM

Beitrag von F-orced-customer » 02.09.2016, 17:51

https://www.unitymedia.de/content/dam/d ... ymedia.pdf
Fragmentation MUST happen after [RFC6333] encapsulation and reassembly MUST happen before
decapsulation.
Wenn dann hat AVM hier den Bug.

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 18:07

Habe ich doch gesagt:
Ein Bug in der FW der Fritten,
wovon AVM eventuell noch keine Kenntnis hat.

Ich unterstelle ja auch nur Unitymedia und VF/KD, daß die diesen Fehler schon erkannt haben, und diesen bewusst nicht an AVM melden.

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Leseratte10
Glasfaserstrecke
Beiträge: 1423
Registriert: 07.03.2013, 15:56

Re: Portsperren bei UM

Beitrag von Leseratte10 » 02.09.2016, 21:28

So langsam wird es lächerlich. Wieso sollte UM auf Fehlersuche gehen in AVM-Geräten? Wie kommst du darauf dass UM den Fehler kennt? Wahrscheinlich ist der in neueren Firmware eh schon - genau wie der fast identische Sixxs-Bug - behoben.

hajodele
Kabelkopfstation
Beiträge: 4816
Registriert: 10.04.2013, 14:19
Wohnort: Kabelbw-Land

Re: Portsperren bei UM

Beitrag von hajodele » 02.09.2016, 21:59

Andreas1969 hat geschrieben:Habe ich doch gesagt:
Ein Bug in der FW der Fritten,
wovon AVM eventuell noch keine Kenntnis hat.

Ich unterstelle ja auch nur Unitymedia und VF/KD, daß die diesen Fehler schon erkannt haben, und diesen bewusst nicht an AVM melden.

Gruß Andreas
Warum meldest du ihn nicht einfach selbst?

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 22:03

Werde ich dieses Wochenende noch tun.
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 22:09

Leseratte10 hat geschrieben:So langsam wird es lächerlich. Wieso sollte UM auf Fehlersuche gehen in AVM-Geräten? Wie kommst du darauf dass UM den Fehler kennt? Wahrscheinlich ist der in neueren Firmware eh schon - genau wie der fast identische Sixxs-Bug - behoben.
Ich glaube, da hast Du irgendetwas durcheinander geschmissen.
Das Problem ist zwar ähnlich gelagert, allerdings betraf das nur die 6490, seit Einführung vor ca. 1,5 Jahren.
Das wurde schließlich mit der 6.50 gefixed.
Bei der 6360 gab es dieses Problem nie.
Das VPN Problem zieht sich aber durch alle Boxen, unabhängig vom FW Stand.
Im Prinzip besteht das Problem schon, solange es
dieses verflixte DSLITE gibt.

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 22:26

Ausserdem habe ich AVM sämtliche Support-Daten, Logs und Konfigurationen aus den beiden Boxen zukommen lassen und die haben keinen Fehler festgestellt, bzw.
anhand der Daten nichts analysieren können. Das erweckt erst einmal den Eindruck bei mir, das der Support dort nicht allzu kompetent ist.
Würden die dieses Problem kennen, hätten die mir auch sicherlich mitgeteilt, daß die VPN-Problematik mit der OS 6.50 gefixed ist. Die wird ja momentan
für die ertsten Kunden schon ausgerollt und soll ab dem 9.9.2016 flächendeckend ausgerollt werden.
Allerdings prüfen die Kabelanbieter die FW-Stände Monatelang, bis die mal irgendwann wahnsinnig zeitverzögert ausgerollt werden.
Bei den ganzen Tests wird denen doch wohl aufgefallen sein, daß da irgend etwas nicht stimmt.
Warum sollte man was dran tun, sonst geht ja alles und die Kunden mit dem Problem können ja auf den Business Tarif wechseln. :zerstör:

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

F-orced-customer
Glasfaserstrecke
Beiträge: 1000
Registriert: 11.09.2012, 12:54

Re: Portsperren bei UM

Beitrag von F-orced-customer » 02.09.2016, 22:32

Wie soll AVM das Problem denn reproduzieren?

CLOSED, UNREPRODUCIBLE, NOTOURBUG oder als DUPLICATE vom Sixx Bug FIXED.

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 02.09.2016, 22:42

Das hätten die Anhand der erzeugten Support Daten der Boxen analysieren können.

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 03.09.2016, 00:00

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
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

F-orced-customer
Glasfaserstrecke
Beiträge: 1000
Registriert: 11.09.2012, 12:54

Re: Portsperren bei UM

Beitrag von F-orced-customer » 03.09.2016, 00:17

IPSEC ist einfach Schrott, hochkompliziert und fehleranfällig. Es gibt besseres VPN.

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 03.09.2016, 01:24

Das es kompliziert ist, will ich wohl nicht abstreiten.
Sicher ist es jedenfalls (extrem sicher).
In diesem Fall handelt es sich ja lediglich um ein Defizit auf der Box, sonst würde das ja einwandfrei laufen.

Also abwarten, die Mail an AVM ist raus.

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Portsperren bei UM

Beitrag von SpaceRat » 03.09.2016, 12:10

Dann sollte ein Raspberry Pi o.ä. hinter der DS-lite-Box aber wohl mit strongSWAN eine Verbindung hinkriegen ...

... ich sag ja immer wieder, gerade bei DS-lite ist die 6490 suboptimal, da sie nicht gefreetzt werden kann. Ansonsten bräuchte man nämlich nicht einmal den Pi ...
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7908
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 03.09.2016, 12:52

Mit einem Raspberry PI würde es definitiv gehen, da er in der Lage ist, die Fragmente zwischenzupuffern und wieder zusammenzusetzen.
Optimal ist das aber auch nicht, da da unnötig mehr Bandbreite verbraten wird.
Daher sollte man generell unfragmetiert arbeiten.
Leider beherrschen die Boxen das zwischenpuffern nicht.
Dafür würde auch der Prozessor und der Speicher unnötig belastet, bzw. wäre wahrscheinlich nicht ausreichend.

Wenn der Bug behoben ist und die Aushandlung des Tunnels läuft korrekt, ist doch alles OK und man benötigt keine zusätzliche Hardware.
Da möchte ich jetzt erst mal hin.

Gruß Andreas
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Antworten

Wer ist online?

Mitglieder in diesem Forum: rv112 und 10 Gäste