Fritzbox LAN-LAN Problem 7490 / 6490

Toggle sidebar Toggle sidebar
Upgrade 3CX to v18 and get it hosted free!
I

IaroonI

Neuer User
Mitglied seit
23 Mai 2018
Beiträge
13
Punkte für Reaktionen
0
Punkte
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
 
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.
 
Zuletzt bearbeitet:
PeterPawn schrieb:
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.
Zum Vergrößern anklicken....

Warum ist das eine schlechte Idee? Und was wäre denn dann eine gute Idee?

eisbaerin schrieb:
IMO ist da was falsch. Woher kommt die 2. Zeile in beiden cfg?
Zum Vergrößern anklicken....
Ich habe die zweite Zeile mal ergänzt, in der Hoffnung, dass das weiterhilft. Macht diese denn was kaputt?

eisbaerin schrieb:
Ist bei mir überall auf yes. Wieso bei dir nicht? Vielleicht beide Config noch mal neu machen.
Zum Vergrößern anklicken....

weil die Fritzboxen in meinem Fall dann erst gar keinen aktiven Tunnel aufbauen können. Neu gemacht habe ich die Configs schon mehrfach...
 
Zuletzt bearbeitet:
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.
 
Vielen Dank für eure Antworten!

eisbaerin schrieb:
Alles außer von 178 bis 189.
Zum Vergrößern anklicken....

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?

PeterPawn schrieb:
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
Zum Vergrößern anklicken....

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...
 
IaroonI schrieb:
Sind diese Adressen dann in Ordnung?
Zum Vergrößern anklicken....
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?
 
eisbaerin schrieb:
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.
Zum Vergrößern anklicken....

Welche Adressen meinst du genau?

eisbaerin schrieb:
Das use_nat_t hast du selber auf yes gestellt?
Zum Vergrößern anklicken....

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...
 
IaroonI schrieb:
Also ich habe die Box A jetzt zu 192.168.10.1 und die Box B auf 192.168.20.1 geändert.
Zum Vergrößern anklicken....

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
 
  • Like
Reaktionen: MuP
eisbaerin schrieb:
Na, die der FB selber im LAN.
Zum Vergrößern anklicken....

Das war für mich zu offensichtlich, dass ich nicht daran gedacht hatte, dass du darauf hinaus wolltest :D

Micha0815 schrieb:
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".
Zum Vergrößern anklicken....

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:

Micha0815 schrieb:
keepalive_ip = 192.168.10.1
Zum Vergrößern anklicken....

Alles klar, das werde ich noch ergänzen!

Micha0815 schrieb:
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.
Zum Vergrößern anklicken....

Ja würde ich auch genauso machen, ist hier beim anonymisieren verwechselt worden, aber meine echte Namensgebung berücksichtigt das ;)
 
IaroonI schrieb:
Das war für mich zu offensichtlich,
Zum Vergrößern anklicken....
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.
 
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?
 
Keine Protokolle - keine Ideen (von mir jedenfalls).
 
ü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.
 
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.
 
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 ...
 
Um antworten zu können musst du eingeloggt sein.
Kostenlos!
Jetzt holen

Neueste Beiträge

Kategorien

Wissenswertes

Statistik des Forums

Themen
248,983
Beiträge
2,307,834
Mitglieder
378,763
Neuestes Mitglied
arvidwinterfeld5

3CX jetzt einen Monat kostenlos testen

Die Verbindung, Zusammenarbeit und Kommunikation mit Ihrem Team und Ihren Kunden war noch nie so einfach. Nutzen Sie unsere kostenlose 30-Tage-Testversion und entdecken Sie die richtige Lösung für Ihr Unternehmen.

3CX start your free trial guy
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten