.titleBar { margin-bottom: 5px!important; }

Fritzbox LAN-LAN Problem 7490 / 6490

Dieses Thema im Forum "AVM" wurde erstellt von IaroonI, 23 Mai 2018.

  1. IaroonI

    IaroonI Neuer User

    Registriert seit:
    23 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Hallo zusammen!
    Nachdem mir die Suche nicht geholfen hat, versuch ich es mal so.

    Ich habe 2 Fritzboxen

    Fritzbox A: 7490, IPv4 bei der Telekom mit IP 192.168.178.1
    Frittzbox B: 6490, DS-Lite bei UnityMedia mit IP 192.168.179.1

    Für diese hab ich mit dem Tool Fritz-Fernzugang Config-Dateien erstellt um eine VPN-Verbindung herzustellen.
    In beiden Fritzboxen wird diese Verbindung als funktionierend angezeigt und die IP-Adressen alle richtig erkannt.
    Die Verbindung steht dauerhaft.
    upload_2018-5-23_21-34-49.png

    Nun zu meinem Problem:
    Ich erreiche kein Gerät, auch nicht die entfernte Fritzbox.
    Ich habe schon den Parameter "use_nat_t" auf yes gestellt, aber wenn beide so eingestellt sind, kommt kein Tunnel zustande...
    Hat jemand eine Idee, woran das liegen könnte, bzw. wonach man suchen müsste, um das Problem einzugrenzen?
    Vielen Dank schonmal!

    Hier noch die Config-Dateien:
    Code:
    vpncfg {
            connections {
                    enabled = yes;
                    conn_type = conntype_lan;
                    name = "FritzTunnelNachB";
                    always_renew = no;
                    reject_not_encrypted = no;
                    dont_filter_netbios = yes;
            boxuser_id = 0;
                    localip = 0.0.0.0;
                    local_virtualip = 0.0.0.0;
                    remoteip = 0.0.0.0;
                    remote_virtualip = 0.0.0.0;
                    remotehostname = "";
                    localid {
                            fqdn = "namevonA.myfritz.net";
                    }
                    remoteid {
                            fqdn = "namevonB.net";
                    }
                    mode = phase1_mode_aggressive;
                    phase1ss = "all/all/all";
                    keytype = connkeytype_pre_shared;
                    key = "meinpasswort";
                    cert_do_server_auth = no;
                    use_nat_t = no;
                    use_xauth = no;
                    use_cfgmode = no;
                    phase2localid {
                            ipnet {
                                    ipaddr = 192.168.178.0;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2remoteid {
                            ipnet {
                                    ipaddr = 192.168.179.0;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                    accesslist = "permit ip any 192.168.179.0 255.255.255.0",
                     "permit ip any 192.168.178.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";
    }
    
    
    // EOF
    
    Code:
    vpncfg {
            connections {
                    enabled = yes;
                    conn_type = conntype_lan;
                    name = "FritzTunnelNachA";
                    always_renew = yes;
                    reject_not_encrypted = no;
                    dont_filter_netbios = yes;
            boxuser_id = 0;
                    localip = 0.0.0.0;
                    local_virtualip = 0.0.0.0;
                    remoteip = 0.0.0.0;
                    remote_virtualip = 0.0.0.0;
                    remotehostname = "namevonA.myfritz.net";
            keepalive_ip = 192.168.178.1;
            localid {
                            fqdn = "namevonB.myfritz.net";
                    }
                    remoteid {
                            fqdn = "namevonA.myfritz.net";
                    }
                    mode = phase1_mode_aggressive;
                    phase1ss = "all/all/all";
                    keytype = connkeytype_pre_shared;
                    key = "meinpasswort";
                    cert_do_server_auth = no;
                    use_nat_t = no;
                    use_xauth = no;
                    use_cfgmode = no;
                    phase2localid {
                            ipnet {
                                    ipaddr = 192.168.179.0;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2remoteid {
                            ipnet {
                                    ipaddr = 192.168.178.0;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                    accesslist = "permit ip any 192.168.178.0 255.255.255.0",
                     "permit ip any 192.168.179.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";
    }
    
    
    // EOF
    
     
  2. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,351
    Zustimmungen:
    571
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    192.168.179.0/24 ist bei einer FRITZ!Box eine eher schlechte Idee für die LAN-Konfiguration - da sollte man etwas anderes nehmen.
     
  3. eisbaerin

    eisbaerin IPPF-Promi

    Registriert seit:
    29 Sep. 2009
    Beiträge:
    6,413
    Zustimmungen:
    134
    Punkte für Erfolge:
    63
    Beruf:
    Ursa maritimus
    Ort:
    Nordpol
    #3 eisbaerin, 24 Mai 2018
    Zuletzt bearbeitet: 24 Mai 2018
    IMO ist da was falsch. Woher kommt die 2. Zeile in beiden cfg?

    Ist bei mir überall auf yes. Wieso bei dir nicht?

    Vielleicht beide Config noch mal neu machen.
     
  4. IaroonI

    IaroonI Neuer User

    Registriert seit:
    23 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Warum ist das eine schlechte Idee? Und was wäre denn dann eine gute Idee?

    Ich habe die zweite Zeile mal ergänzt, in der Hoffnung, dass das weiterhilft. Macht diese denn was kaputt?

    weil die Fritzboxen in meinem Fall dann erst gar keinen aktiven Tunnel aufbauen können. Neu gemacht habe ich die Configs schon mehrfach...
     
  5. eisbaerin

    eisbaerin IPPF-Promi

    Registriert seit:
    29 Sep. 2009
    Beiträge:
    6,413
    Zustimmungen:
    134
    Punkte für Erfolge:
    63
    Beruf:
    Ursa maritimus
    Ort:
    Nordpol
    #5 eisbaerin, 24 Mai 2018
    Zuletzt bearbeitet: 24 Mai 2018
    Alles außer von 178 bis 189.
    Ja, sonst hätte ich es nicht geschrieben.
    Und immer steht "use_nat_t" auf no?
    Mach sie noch mal neu und lösche nur auf der einen Seite den "remotehostname".
     
  6. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,351
    Zustimmungen:
    571
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    In neueren Versionen versucht AVM zwar "intelligenter", das Gastnetz irgendwie so zu setzen, daß es sich nicht mit anderen Netzen bzw. (lokalen) Routing-Einträgen beißt ... was aber noch nicht heißt, daß eine 6490 (hier eine mit 06.83) dann auch erkennt, wenn sich eine VPN-Verbindung mit dem Gastnetz nicht vertragen kann:
    Code:
    # ctlmgr_ctl l vpn settings/connection/list\(access_net,access_mask,activated\) | grep connection1; echo "------------------"; ctlmgr_ctl u interfaces | grep guest
            connection1     172.31.179.0    255.255.255.0   1
    ------------------
     guest_ip=172.31.179.1
     guest_netmask=255.255.255.0
    
    Die VPN-Verbindung ist aktiviert und wurde auch komplett (und klaglos) über das GUI eingerichtet (das Segment für's Gastnetz sucht die Box sich ja selbst) ... ob das in den neueren Versionen dann verbessert wurde und auch funktioniert, weiß ich nicht. Aber hier kann "Vorbeugen" eigentlich immer nur besser sein als "Nachhintenfallen" und daher nimmt man schlicht für die eigenen Netze keine Segmente, die auch vom Gastnetz belegt sein könnten.

    Früher standen sogar in den Handbüchern der Boxen noch entsprechende Hinweise ... darauf verzichtet AVM m.W. inzwischen (zumindest an der Stelle, wo man das als normaler Mensch suchen würde im Handbuch) - vielleicht weil man davon ausgeht, die Firmware wäre schon "sophisticated" genug, um derartige Probleme selbst zu beheben. Wenn das tatsächlich so sein sollte, müßte sie aber noch mächtig dazugelernt haben - die "change logs" der Versionen bis 06.87 (die derzeitige Release-Version der 6490) lassen davon jedenfalls nichts erahnen.
     
  7. IaroonI

    IaroonI Neuer User

    Registriert seit:
    23 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Vielen Dank für eure Antworten!

    Also ich habe die Box A jetzt zu 192.168.10.1 und die Box B auf 192.168.20.1 geändert.
    Sind diese Adressen dann in Ordnung?

    Verstehe ich das also richtig, dass mein Tunnel zwar steht, aber nicht funktioniert, weil die Fritzbox 192.168.179.X für ein nicht aktiviertes Gastnetz reserviert?

    Hier sind die neuen Config-Dateien:
    Code:
    vpncfg {
            connections {
                    enabled = yes;
                    conn_type = conntype_lan;
                    name = "FritzTunnelNachA";
                    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 {
                            fqdn = "adressevonA.myfritz.net";
                    }
                    remoteid {
                            fqdn = "adressevonB.myfritz.net";
                    }
                    mode = phase1_mode_aggressive;
                    phase1ss = "all/all/all";
                    keytype = connkeytype_pre_shared;
                    key = "meinpasswort";
                    cert_do_server_auth = no;
                    use_nat_t = yes;
                    use_xauth = no;
                    use_cfgmode = no;
                    phase2localid {
                            ipnet {
                                    ipaddr = 192.168.10.0;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2remoteid {
                            ipnet {
                                    ipaddr = 192.168.20.0;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                    accesslist = "permit ip any 192.168.20.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";
    }
    
    
    // EOF
    
    Code:
    vpncfg {
            connections {
                    enabled = yes;
                    conn_type = conntype_lan;
                    name = "FritzTunnelNachB";
                    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 = "adressevonA.myfritz.net";
                    localid {
                            fqdn = "adressevonB.myfritz.net";
                    }
                    remoteid {
                            fqdn = "adressevonA.myfritz.net";
                    }
                    mode = phase1_mode_aggressive;
                    phase1ss = "all/all/all";
                    keytype = connkeytype_pre_shared;
                    key = "meinpasswort";
                    cert_do_server_auth = no;
                    use_nat_t = yes;
                    use_xauth = no;
                    use_cfgmode = no;
                    phase2localid {
                            ipnet {
                                    ipaddr = 192.168.20.0;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2remoteid {
                            ipnet {
                                    ipaddr = 192.168.10.0;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                    accesslist = "permit ip any 192.168.10.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";
    }
    
    
    // EOF
    

    Ich kann die neue Config leider erst Montag testen, da ich Zugriff nur via Teamviewer habe und dieser erst ab nächster Woche zur Verfügung steht...
     
  8. eisbaerin

    eisbaerin IPPF-Promi

    Registriert seit:
    29 Sep. 2009
    Beiträge:
    6,413
    Zustimmungen:
    134
    Punkte für Erfolge:
    63
    Beruf:
    Ursa maritimus
    Ort:
    Nordpol
    Ja.
    Es müssen dann aber auch die Adressen in der FB entsprechend für das LAN angepaßt werden. Das kontrolliert die FB IMO nicht.

    Ich hoffe das war vorher schon der Fall.

    Das use_nat_t hast du selber auf yes gestellt?
     
  9. IaroonI

    IaroonI Neuer User

    Registriert seit:
    23 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Welche Adressen meinst du genau?

    Nein, das war so. Dann hab ich das wohl beim ersten mal auch selber geändert. Dann hattest du wohl damit Recht ;)
    Aber ich hatte trotzdem das Problem, dass der Tunnel mit "yes" gar nicht erst zustande kam...
     
  10. eisbaerin

    eisbaerin IPPF-Promi

    Registriert seit:
    29 Sep. 2009
    Beiträge:
    6,413
    Zustimmungen:
    134
    Punkte für Erfolge:
    63
    Beruf:
    Ursa maritimus
    Ort:
    Nordpol
    Na, die der FB selber im LAN.
     
  11. Micha0815

    Micha0815 Aktives Mitglied

    Registriert seit:
    25 Feb. 2008
    Beiträge:
    2,710
    Zustimmungen:
    91
    Punkte für Erfolge:
    48
    Beruf:
    Stauberater
    Darauf bezog sich das ändern der IP. Nicht nur in der vpn.cfg sondern auch die FBs selbst ;), was ebend vorab geschehen sollte, bevor die VPN.cfg eingespielt wird. Sämtliche Clients müssen sich danach ja auch via DHCP und/oder IP-Zuweisung in den lokalen FB-Netzen neu "einfinden" u.a. auch der "administrierende Teamviewer".

    Btw würde ich der Initiator FB-B (192.168.20.1) hinter dem DS-Lite neben
    Code:
    remotehostname = "adressevonA.myfritz.net";
    noch direkt darunter ein
    Code:
    keepalive_ip = 192.168.10.1;
    mitgeben. Die Namensgebung "FritzTunnelNach...." würde ich genau umgekehrt eintragen, damit auf der lokalen FB das Ziel/der Ursprung der VPN-Verbindung ersichtlich ist. Das dient nur der Übersichtlichkeit, falls mehrere LAN2LAN-Verbindungen eingetragen sind.
    LG
     
    MuP gefällt das.
  12. IaroonI

    IaroonI Neuer User

    Registriert seit:
    23 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Das war für mich zu offensichtlich, dass ich nicht daran gedacht hatte, dass du darauf hinaus wolltest :D

    Ja damit hab ich mich gestern den ganzen Tag auseinandergesetzt... Ich hab auch sowas wie z.B. einen Raspberry im Netz, auf dem Skripte laufen, in denen auch die IP's geändert werden mussten :confused:

    Alles klar, das werde ich noch ergänzen!

    Ja würde ich auch genauso machen, ist hier beim anonymisieren verwechselt worden, aber meine echte Namensgebung berücksichtigt das ;)
     
  13. eisbaerin

    eisbaerin IPPF-Promi

    Registriert seit:
    29 Sep. 2009
    Beiträge:
    6,413
    Zustimmungen:
    134
    Punkte für Erfolge:
    63
    Beruf:
    Ursa maritimus
    Ort:
    Nordpol
    Jo, wir haben hier aber solche und solche Leute im Forum. (Aber mehr solche als solche ;) )
    Und man weiß nie wo die den Fehler machen, oder was für sie selbstverständlich ist.
    Deshalb hielt ich es für wichtig zu erwähnen.
     
  14. IaroonI

    IaroonI Neuer User

    Registriert seit:
    23 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Hallo zusammen, ich hab die neuen Config-Dateien eingebaut, aber es funktioniert immer noch nicht.

    FritzBox A zeigt folgdenes Verhalten:
    Die Verbindung wird kurzzeitig hergestellt aber dann wieder abgebrochen. Folgende Fehler tauchen auf:
    "IKE-Error 0x2027 - "timeout"".
    "IKE-Error 0x203d - "phase 1 sa removed during negotiation"".
    VPN-Verbindung zu FritzTunnelNachB wurde getrennt. Ursache: 3 IKE server

    FritzBox B zeigt immer folgenden Fehler: "IKE-Error 0x2027 - "timeout"".

    Jemand da noch eine Idee?
     
  15. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,351
    Zustimmungen:
    571
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Keine Protokolle - keine Ideen (von mir jedenfalls).
     
  16. IaroonI

    IaroonI Neuer User

    Registriert seit:
    23 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    #16 IaroonI, 27 Mai 2018
    Zuletzt bearbeitet: 27 Mai 2018
    was hättest du denn gerne für protokolle?
     
  17. Shirocco88

    Shirocco88 Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    730
    Zustimmungen:
    48
    Punkte für Erfolge:
    28
    üblicherweise werden avmike.log der beiden Boxen nach Restart (zuerst Responder-Box, dann Initiator-Box) benötigt;
    dieses Logfile ist u.a. in der Supportdaten-Datei http://fritz.box/?lp=support enthalten.

    einfach beide Logfiles anhängen oder in CODE-Tages packen.
     
  18. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,351
    Zustimmungen:
    571
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Wenn ich jetzt sehr "unbestimmt" antworte: "Dieselben, wie in den anderen VPN-Threads auch ...", dann verbinde ich damit auch die Hoffnung, daß Du Dir (solltest Du das noch nicht getan haben, wobei Du dann zumindest in der Theorie vermutlich auch wüßtest, welche Protokolle bei VPN-Problemen zum "Standard" gehören und ansonsten immer "abgefragt" werden) ein paar andere Threads zu diesem Problem (VPN mit einem "nicht direkt erreichbaren" Peer) zu Gemüte führst. Wirklich neue und einmalige Probleme mit solchen VPN-Konstellationen sind vermutlich eher eine sehr, sehr rare Ausnahme ... da müßten schon ein paar ganz außergewöhnliche Umstände zusammenkommen und davon war bisher eigentlich nichts zu lesen.

    Als einsamen "hint" nenne ich trotzdem noch die Dateinamen "ike.log" und "ike.old" ... aber es ist (nach meiner Überzeugung jedenfalls) auch oft genug "aufgezählt", was zu einer (fundierten) Analyse alles notwendig ist und da braucht es sogar das Event-Log (mit den entsprechenden Nachrichten natürlich nur) in "voller Schönheit", damit man die Nachrichten anhand ihres Zeitstempels den Meldungen aus dem VPN-Protokoll zuordnen kann.
     
  19. IaroonI

    IaroonI Neuer User

    Registriert seit:
    23 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Hier die hoffentlich richtigen Support-Daten:
     

    Anhänge:

  20. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,351
    Zustimmungen:
    571
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Fast ... aber man muß das dann auch auf beiden Seiten mit einem Neustart beginnen (den passiven Responder zuerst starten, das wäre hier die 7490), weil man im Protokoll praktisch nichts mehr sieht. Es gibt keinerlei Information (zumindest sehe ich sie nicht), was die 6490 hier veranlassen sollte, dreimal pro Sekunde irgendeine neue SA aushandeln zu wollen. Da, wo es sich vielleicht wieder "settlen" könnte (ab 21:11:04 Uhr) ... da ist dann das Protokoll in beiden Boxen auch schon zu Ende. Die letzten 10-20 Zeilen (ab Neustart P1) sehen dann "normal" aus ... der Rest davor ist ein einziges Durcheinander und man kann nicht erkennen, ob die Boxen jemals die Chance hatten, "vernünftig" miteinander zu reden.

    Abgesehen davon fehlen die (oben von mir erwähnten) Informationen aus dem Event-Log (man muß auch sehen können, wann der IKE-Daemon einen Verbindungsversuch aufgegeben und neu gestartet hat).

    Es macht jedenfalls gar keinen Sinn, wenn hier in der 7490 innerhalb derselben Sekunde eine SA eingerichtet wird (hier mal die "232" als Beispiel):
    Code:
    2018-05-27 21:10:18 avmike:FritzTunnelToB: Phase 2 ready
    2018-05-27 21:10:18 avmike:< cb_sa_created(name=FritzTunnelToB,id=232,...,flags=0x00022003)
    2018-05-27 21:10:18 avmike:FritzTunnelToB: start waiting connections
    2018-05-27 21:10:18 avmike:FritzTunnelToB: NO waiting connections
    2018-05-27 21:10:18 avmike:FreeIPsecSA: spi=e52efe47       protocol=3 iotype=2
    2018-05-27 21:10:18 avmike:< cb_sa_deleted(name=FritzTunnelToB,id=232,what=2)
    2018-05-27 21:10:18 avmike:FreeIPsecSA: spi=3a78       protocol=4 iotype=2
    2018-05-27 21:10:18 avmike:< cb_sa_deleted(name=FritzTunnelToB,id=232,what=2)
    2018-05-27 21:10:18 avmike:FreeIPsecSA: spi=36bf4119       protocol=3 iotype=1
    2018-05-27 21:10:18 avmike:FreeIPsecSA: spi=ec65       protocol=4 iotype=1
    
    und diese dann auch gleich wieder abgeräumt wird, ohne daß es einen erkennbaren Grund dafür gäbe. Eine Erklärung wäre z.B. ein "initial contact" ... dann sollen die SAs tatsächlich verworfen werden. Hier sieht das aber eher so aus, als würde dieser Prozess des Entfernens alter SA permanent laufen und jede neu eingerichtete SA gleich wieder abräumen ... die erste Message mit "initial contact" ist dann praktischerweise wieder am Ende des Logs.

    Mein Rat wäre es also, die Boxen noch einmal synchronisiert zu starten (Reihenfolge siehe oben) und dann (zeitnah) das Protokoll auszulesen. Dabei braucht man dann aber auch den Beginn des Protokolls (zu erkennen an den "add"-Zeilen), ansonsten hat man gar keinen Schimmer, wie die Boxen in diese hektische Betriebsamkeit mit 3-4 SAs per second verfallen konnten.

    ======================================================

    Wobei man Dir in einigen Konstellation mit DS-Lite bei UM wohl ohnehin keine echte Hoffnung machen kann, denn da könnte wohl wieder die MTU für den (DS-Lite-)Tunnel nicht stimmen bzw. die längeren Pakete werden ggf. wieder an der kleineren MTU des Tunnels scheitern - das ist nämlich auch eine weitere fehlende Information, über welche FRITZ!OS-Versionen wir hier überhaupt reden.

    Das Thema "Unitymedia und AVM-VPN" ist auch mehrfach besprochen (hier und im inoffiziellen UM-Forum) - wobei ein paar Fakten für das Problem sprechen (die Timeouts sind ja nicht richtig übertragene Pakete und da wären zu große Pakete, die dann gedroppt werden, eine passende Erklärung) und andere wieder dagegen. Im 6490-Protokoll sieht man ja, daß die Box für den Tunnel eine MTU von 1460 annimmt ... das würde - da für den zusätzlichen IPv6-Header bei DS-Lite eigentlich 40 Bytes benötigt werden - wieder passen.

    Ich würde hier trotzdem mal mit "ping" und "don't fragment" die MTU des DS-Lite-Tunnels (für IPv4 natürlich) ausloten ...