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

Unitymedia Portsperren bei UM

Diskutiere Portsperren bei UM im Internet und Telefon über das TV-Kabelnetz Forum im Bereich Internet und Telefon; Wie wäre es denn, wenn ich auf der 6490 folgende´n Bereich in der config: phase2ss = "esp-all-all/ah-none/comp-all/pfs"...

Was haltet Ihr von den Sperren?

  • Voll in Ordnung. Sicherheit ist ein wichtiges Thema und beeinträchtigt mich ja auch nicht

    Stimmen: 17 18,9%
  • Voll in Ordnung. Aber warum weiss ich nichts davon? Sollte man schon *irgendwo* mitteilen

    Stimmen: 16 17,8%
  • Unverschämtheit. Ich brauche die Ports für xxx (bitte ein Beispiel posten bzw. erklären)

    Stimmen: 10 11,1%
  • Unverschämtheit. Brauche die Ports nicht, aber finde es aus Prinzip nicht in Ordnung.

    Stimmen: 42 46,7%
  • Kenne Ports und die Bedeutung nicht. Kann mich darum nicht äussern

    Stimmen: 1 1,1%
  • Kenne nur Port-Wein, also mir egal. *Prost*

    Stimmen: 3 3,3%
  • Ist mir egal / Keine Meinung zu

    Stimmen: 1 1,1%

  • Umfrageteilnehmer
    90
  • Portsperren bei UM Beitrag #126
Wie wäre es denn, wenn ich auf der 6490 folgende´n Bereich in der config:

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";


folgendermaßen abändern würde:

phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.13.0 255.255.255.0";
"reject udp any any eq 500",
"reject udp any any eq 4500",
}


könnte das eventuell funktionieren?

Gruß Andreas
 
  • Portsperren bei UM Beitrag #127
Unitymedia muss das ja auch nicht unterstützen.
Die beiden Ports (4711 und 4300) sind ja auf dem AFTR schon geöffnet.
Die 6490 muss die beiden UDP Ports 4711 und 4300 ja nur auf sich selbst für eingehenden Verkehr öffnen anstelle der Ports 500 und 4500, die bei der Einrichtung von VPN standardmäßig geöffnet werden. Oder habe ich da jetzt was falsch verstanden?
Die Verbindung wird doch von der 6360 aus initiiert und nicht anders herum.

I. d. R. "überleben" auch UDP-source-Ports, ein NAT oder diverse gateways/routings, etc.

Aber auch wenn das AFTR-gateway andere UDP-source-Ports an die 6490 mitteilt, dann sind das noch keine (lauschende) destination-Ports auf der bzw. für die 6490 und somit muss m. E. die 6490 auch diese UDP-Ports nicht für ihren eingehenden Verkehr öffnen.

Wenn Du je einen PI an deinen FBen-cable hättest, dann könntest Du ja mal testen, ob bzw. was das AFTR-gateway, so an UDP-Datenpaketen ändert oder nicht ändert (z. B. ToS, etc.) .

Evtl. auch im IPPF mal btr. deiner Problematik nachfragen. Vielleicht hat ja schon mal jemand, die Konstellation mit "Initiator"- und "Responder"-FritzBox, auf gefreetzten Nichtcable-FritzBox getestet und sich angeschaut wie dann das Zustandekommen der VPN-Verbindung bzw. wie der VPN-Datenverkehr mit so einer Konfiguration ist.
 
  • Portsperren bei UM Beitrag #128
Ich habe bei AVM nochmal angefragt, ab wann den die Fritz Boxen VPN über IPV6 unterstützen werden?

Darauf habe ich folgende verwirrende Antwort erhalten :

XXX (AVM Support)

31. Aug., 16:00 CEST

Guten Tag Herr XXX ,

die FRITZ!Box 6490 Cable unterstützt vollumfänglich IPv4 und Ipv6. Ebenso ist am Unitymedia-Kabelanschluss IPv6 möglich und im Einsatz.

Retail-Geräte werden durch die Provider zum Teil anders provisioniert als Mietgeräte. In diesem konkreten Fall wird ein relevanter Parameter hier nicht gesetzt und es wird lediglich IPv4 angeboten. Die Optionen in der Benutzeroberfläche bieten somit die entsprechenden Tunnel-Protokolle an.

Wir arbeiten auf Basis der nun bekannten Schnittstellenbeschreibungen gemeinsam mit dem Provider an Optimierungen, um hier die optimalen Einstellungen zu finden und in Zukunft auch echten Dual Stack zu ermöglichen. Dies wird voraussichtlich im Herbst der Fall sein.

Freundliche Grüße aus Berlin
XXX (AVM Support)


Da komme ich jetzt nicht mit klar.
Wird VPN über IPV6 von den Fritten jetzt doch schon unterstützt?

Oder ist das jetzt verar...
Ab Herbst gibt es Echtes Dual Stack?
Was soll man davon halten?


Gruß Andreas
 
  • Portsperren bei UM Beitrag #129
FAQ-Antwort, Konserve aus Textbausteinen.
 
  • Portsperren bei UM Beitrag #130
Apropo:

Morgen ist Herbstanfang
Und heute ist nicht der 1. April

Also ab Morgen echten Dual Stack
Dann werde ich das mal ordern.


Gruß Andreas
 
  • Portsperren bei UM Beitrag #131
Probier mal diese Configs:

6360:
Code:
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:
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:
 name = "6490";
bzw.
Code:
 name = "6360";
und der PSK:

Einen eigenen PSK generieren, z.B. und diesen dann in beiden Configs bei
Code:
 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:
 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
 
  • Portsperren bei UM Beitrag #132
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
 
  • Portsperren bei UM Beitrag #133
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
 
  • Portsperren bei UM Beitrag #134
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 ...
 
  • Portsperren bei UM Beitrag #135
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
 
  • Portsperren bei UM Beitrag #136
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.
 
  • Portsperren bei UM Beitrag #137
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
 
  • Portsperren bei UM Beitrag #138
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 :)
 
  • Portsperren bei UM Beitrag #139
Zuverlässiges und reproduzierbares IPSEC NAT-Setup ist nur mit IKEv2 möglich, AVM benutzt noch v1?
 
  • Portsperren bei UM Beitrag #140
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 ...
...
 
  • Portsperren bei UM Beitrag #141
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
 
  • Portsperren bei UM Beitrag #142
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
 
  • Portsperren bei UM Beitrag #143
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
 
  • Portsperren bei UM Beitrag #144
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".
 
  • Portsperren bei UM Beitrag #145
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
 
  • Portsperren bei UM Beitrag #146
  • Portsperren bei UM Beitrag #147
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
 
  • Portsperren bei UM Beitrag #148
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
 
  • Portsperren bei UM Beitrag #149
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.
 
  • Portsperren bei UM Beitrag #150
http://www.unitymediaforum.de/viewtopic.php?p=355145#p355145
 
Thema:

Portsperren bei UM

Oben