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: 7920
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 31.08.2016, 21:53

SpaceRat hat geschrieben:Probier mal diese Configs:

6360:

Code: Alles auswählen

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "6490";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "6490.myfritz.net";
                keepalive_ip = 192.168.2.1;
                localid {
                        ipaddr = 192.168.13.1;
                }
                remoteid {
                        ipaddr = 192.168.2.1;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "x2SO8SrcZP79gm1Xn8agqHuHGvaPrjz487zCPpdV18g";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.13.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.2.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.2.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}

6490:

Code: Alles auswählen

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "6360";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "";
                localid {
                        ipaddr = 192.168.2.1;
                }
                remoteid {
                        ipaddr = 192.168.13.1;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "x2SO8SrcZP79gm1Xn8agqHuHGvaPrjz487zCPpdV18g";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.2.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.13.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.13.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}
In beiden Configs wären anzupassen:
Der Name der Gegenseite

Code: Alles auswählen

                name = "6490";
bzw.

Code: Alles auswählen

                name = "6360";
und der PSK:

Einen eigenen PSK generieren, z.B. hier und diesen dann in beiden Configs bei

Code: Alles auswählen

                key = "x2SO8SrcZP79gm1Xn8agqHuHGvaPrjz487zCPpdV18g";
einfügen.
Je länger, desto besser, Custom Length 99 sollte funktionieren.

In der Config der 6360 / DS-lite-Seite ist noch anzupassen:

Code: Alles auswählen

                remotehostname = "6490.myfritz.net";

Mit dieser Einstellung und folgender Änderung lief es bisher am besten:
statt mode = phase1_mode_idp; hatte ich mode = phase1_mode_aggressive; eingestellt.
Damit habe ich einmal sogar den Status des VPN Tunnels auf beiden Boxen für ein paar Sekunden grün gehabt.
Dabei wurde auch auf beiden Boxen lokales Netz und entferntes Netz korrekt angezeigt.
Leider ist der Tunnel nach ein paar Sekunden wieder zusammengebrochen.
Das habe ich bisher mit keiner anderen config hinbekommen.

Als die Verbindung stand, wurde auf der Oberfläche der 6360 (DSLite) unter den Intenetdaten hinter dem AFTR-Gateway
folgendes angezeigt: "IP4 MTU = 1280" Das habe ich bisher in der Oberfläche noch nie gesehen.
Nach dem Zusammenbruch des Tunnels wurde diese Info auch nicht mehr angezeigt.

Kann es wohl sein, daß mein Problem mit dem MTU-Wert zu tun hat?
Die 6360 hat ja noch die FW 6.33 drauf.
Bei der 6490 ist die FW 6.50 drauf.
In den vorherigen FW-Ständen bei der 6490 gabs vorher auch Probleme mit dem MTU-Wert beim SIXXS Tunnel, das lief nicht.
Der SIXXS Tunnel läuft erst seit der FW 6.50 sauber, wo der Bug behoben wurde.
Vielleicht ist das VPN Problem ja ähnlich gelagert und nach dem Update der 6360 ab dem 09.09.2016 auf FW 6.50 ist Problem behoben
und der VPN Tunnel läuft auf einmal???

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: 7920
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 01.09.2016, 07:54

Bei VF/KD scheint das VPN bei DSLite wohl schon zu funktionieren.

Laut Beschreibung war es nicht möglich, eine VPN-Verbindung zu einer DSLite Box aufzubauen, da der
Tunnelaufbau bei IPSEC in Phase 2 hängengeblieben ist. So stellt sich das bei mir ja auch dar.
Bei Kunden, die sich in Bezug auf dieses Problem gemeldet haben (die letzten 3-4 Wochen) wurde
Anscheinend von einem Mitarbeiter von VF/KD auf der Fritte ein Paramater gesetzt, wobei nach einem
anschließenden Neustart der Box zusätzlich zum DSLite noch eine IPV4 Adresse in der Oberfläche
der Box sichtbar war. Über diese IPV4 Adresse ließ sich dann der VPN Tunnel aufbauen.

Jetzt würde mich mal interessieren, wie die das umsetzten?
Wurde bei VF/KD schon PCP implementiert (bloß noch nicht für alle)?
Was wird da in der Box für eine IPV4 angezeigt, handelt es sich dabei um eine virtuelle Adresse, die per PCP auf dem AFTR erzeugt wird?
Das würde sich ja annähernd mit der letzten Mail von AVM decken.
Ich habe auch gelesen, daß es nur bei Kunden geht, die eine 6490 haben.
Das kann aber dann eigentlich nur mit der FW zu tun haben (PCP geht ja erst ab OS 6.50) und sollte
nach dem Ausrollen der 6.50 auf die 6360 dann dort auch möglich sein.

Das macht mir jetzt wieder etwas Hoffnung.


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: 7920
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 01.09.2016, 08:11

Hier mal ein Beispiel über eine solchve Konversation:


Hallo buchmannm,
sende mir bitte per privater Nachricht folgende Daten zu:

Username:
Vollständiger Name:
Kundennummer:
Anschrift:
E-Mail-Adresse:
Link deines Beitrags:

Sobald ich Deine Daten haben, melde ich mich hier wieder.
Grüße
Marcus

Ich habe deine Daten erhalten. Bitte starte Deinen Router neu und prüfe, ob die Probleme weiterhin bestehen.
Grüße
Marcus


Hallo Marcus,
vielen Dank für die schnelle Hilfe, VPN funktioniert nun
Viele Grüße
Marc

Das sind doch sehr schöne Nachrichten. Freue mich, dass ich Dir weiterhelfen konnte. Ich werde den Thread nun schließen
und wünsche dir noch einen schönen Sonntag!
Grüße
Marcus
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 » 01.09.2016, 08:40

Andreas1969 hat geschrieben:Bei VF/KD scheint das VPN bei DSLite wohl schon zu funktionieren.

Bei Kunden, die sich in Bezug auf dieses Problem gemeldet haben (die letzten 3-4 Wochen) wurde
Anscheinend von einem Mitarbeiter von VF/KD auf der Fritte ein Paramater gesetzt, wobei nach einem
anschließenden Neustart der Box zusätzlich zum DSLite noch eine IPV4 Adresse in der Oberfläche
der Box sichtbar war. Über diese IPV4 Adresse ließ sich dann der VPN Tunnel aufbauen.
Kein Hexenwerk:
Entsprechende Kunden werden bei KD/VF einfach auf "Dual Stack" umgestellt.

Als temporäre Problemlösung ist das durchaus geeignet:
Ich behaupte ja, daß 95% der Kunden überhaupt nicht merken ob sie "Dual Stack", "IPv6-only mit Übergangsmechanismus" oder "IPv4-only" haben.
Es wäre also ein Leichtes, bei Neuanschlüssen wie gehabt "IPv6-only+DS-lite" zu schalten, aber gleichzeitig auch nach Ankündigung und fehlendem Widerspruch immer wieder mal Bestandsanschlüsse ebenfalls auf "IPv6-only+DS-lite" umzuschalten.
Im Gegenzug könnte man nämlich problemlos jedem der es haben will echten Dual-Stack schalten.
Unitymedia ist ja nur ein relativ neuer Anbieter, die haben schon noch einige Millionen IPv4-Adressen bekommen, im Gegensatz zu den wirklich neuen Anbietern wie fl!nk oder NEW, die wirklich mit 1024 Adressen gerade mal genug für das Betreiben von CGN-Gateways und ein paar Geschäftskunden haben.

Das könnte Unitymedia also schon machen, tun sie aber nicht. Die hauen die IPv4 lieber an anderer Stelle raus ...
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: 7920
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 01.09.2016, 10:03

Eine Theorie hätte ich da noch:
Und zwar hat mich die Aussage stutzig gemacht, daß es nur bei der 6490 geht.

Dual-Stack läuft ja auch problemlos bei der 6360 usw.
Und die 6490 ist ja momentan die einzige Kabelbox, die das OS 6.50 drauf hat (PCP).

Wenn PCP vom Anbieter unterstützt wird und auf der Box aktiviert ist, würden die
benötigten Ports auf dem AFTR geöffnet.
Durch eine Änderung eines Parameters auf der Box, könnte die IP4 des AFTR´s, auf welchem die
entsprechenden Ports geöffnet sind, als IP4 Adresse auf der Oberfläche der Box angezeigt werden
und auch an den DYN-DNS-Dienst gemeldet werden.

Auf der Oberfläche der Box sieht es dann so aus, als wenn man echtes Dual-Stack hätte.
Die Box ist dann auch über IPV4 erreichbar.
Soweit zur Theorie.

Das hat mich jetzt noch auf eine neue Idee gebracht:

Der DYN-DNS-Dienst meldet mir für die DS-Lite Box ja nur eine IPV6-Adresse, VPN kann
damit aber nichts anfangen.
Ich werde heute Abend mal die configs dahingehend ändern, daß ich für localid und remoteid
anstelle der lokalen Adressen der Boxen wieder die DYN-DNS Adressen eintrage.
Nur mit dem Unterschied, daß ich die DYN-DNS Adresse der DSLite Box gegen die IPV4 Adresse des
AFTR´s ersetze.
Wenn das klappt, sollte der Tunnel zumindest solange aufgebaut werden, wie sich
die IP4-Adresse des AFTR´s nicht ändert.

Ich bin mal gespannt, ob das klappt.

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 » 01.09.2016, 11:35

Andreas1969 hat geschrieben:Ich werde heute Abend mal die configs dahingehend ändern, daß ich für localid und remoteid
anstelle der lokalen Adressen der Boxen wieder die DYN-DNS Adressen eintrage.
Nur mit dem Unterschied, daß ich die DYN-DNS Adresse der DSLite Box gegen die IPV4 Adresse des
AFTR´s ersetze.
Das wäre Blödsinn.

Die Fritz!Box benutzt die unter localid/remoteid eingetragenen Daten während der Phase 1 zur Aushandlung.
Dabei werden fqdn (Fully qualified domain names) aufgelöst und die resultierenden IP(v4)-Adressen abgeglichen.
Um genau diese Probleme mit der Namensauflösung zu vermeiden, habe ich dort einfach die sich nicht verändernde lokale IPv4 der jeweiligen Box als "ipaddr" eingetragen.
Das funktioniert auch einwandfrei, bei der Verbindung zwischen der Fritz!Box meines Vaters und meiner habe ich das schon ewig so.

Da würde ich es eher mit sowas wie user_fqdn (Also einer eMail) oder key_id probieren, auf jeden Fall irgendwas statisches, was nicht mit einer "Zappel-IP(v4)" abgeglichen werden muß/kann.
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: 7920
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Portsperren bei UM

Beitrag von Andreas1969 » 01.09.2016, 15:31

So, jetzt wird es langsam spannend:

use_nat_t = yes;
habe ich in beiden Configs mal auf
use_nat_t = no;
verändert.

Der Tunnelaufbau klappt jetzt.
VPN Status ist auf beiden Boxen grün.
lokales und entferntes Netz wird auch auf beiden Boxen
korrekt angezeigt.
Einziges Problem ist jetzt, dass keinerlei Daten
durch den Tunnel fließen.
Was kann das jetzt noch sein?
In beiden logs der Boxen steht auch VPN Verbindung erfolgreich aufgebaut.
Es laufen auch keine Fehler mehr rein.

Noch irgendjemand eine Idee?

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 » 01.09.2016, 15:54

Nun, es gibt ja 4 Möglichkeiten (2 Boxen, zwei Einstellungen yes|no = 2^2 = 4), spiel halt mal mit nat_t = yes|no auf beiden Seiten rum.
yes + yes
und
no + no
haste ja jetzt durch :)

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

Re: Portsperren bei UM

Beitrag von F-orced-customer » 01.09.2016, 16:08

Zuverlässiges und reproduzierbares IPSEC NAT-Setup ist nur mit IKEv2 möglich, AVM benutzt noch v1?

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

Re: Portsperren bei UM

Beitrag von SpaceRat » 01.09.2016, 16:17

F-orced-customer hat geschrieben:AVM benutzt noch v1?
Ja.
Und aggressive mode, wenn man's nicht manuell anpaßt.
Und IPv4-only zum Aufbau des Tunnels wie auch im Tunnel.

Ach ja: Und es kann keine Namensauflösung für das entfernte LAN.
Und keine überlappenden Netze ...
...

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 7920
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: 7920
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: 7920
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: 7920
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: 7920
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: 7920
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: 7920
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: 7920
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: 1424
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: 4819
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?

Antworten

Wer ist online?

Mitglieder in diesem Forum: Hoschiyama, Samsungstory und 5 Gäste