[Problem] VPN zwischen zwei Fritzboxen, wobei eine hinter einem externen Router hängt

[Loewe81]

Servus zusammen,
ich möchte gerne einen VPN-Tunnel zwischen meiner Fritzbox zu Hause (normaler/direkter 1&1 Anschluss) und einer Fritzbox im Ferienhaus (hinter externem Router) aufbauen.
Folgende Details zu den zwei Fritzboxen
zu Hause
- Fritzbox 7390
- hat eine öffentliche IPv4 Adresse (also kein DS lite)
- ist über myFritz registriert
- internes Netz 192.168.0.0/24

Ferienhaus
- Fritzbox 7412
- der externe Router hat eine öffentliche IPv4 Adresse, welche auch per DynDNS aufgelöst/erreichbar ist
- Fritzbox ist mit diesem Router über das Netz 192.168.1.0/24 verbunden (der Router hat die .1 und die Fritzbox die .2), also KEIN IP-Client-Modus
- internes Netz 192.168.178.0/24

Sehe ich das richtig, dass die Fritzbox im Ferienhaus der VPN Initiator sein muss?
Über die Fritzbox-Oberfläche habe ich jeweils den DynDNS-Namen der anderen Seite eingegeben und das entsprechend "fremde" interne Netz. Auf beiden Fritzboxen natürlich das gleiche Passwort und nur bei der Fritzbox im Ferienhaus "VPN-Verbindung dauerhaft halten". Mehr kann man ja auch nicht einstellen.
Leider gibt es im Log auf beiden Seiten "IKE-Error 0x2027" Fehler.
Welche Einstellungen brauche ich also noch auf der Fritzbox im Ferienhaus? Oder Bedarf es noch weiteren Einstellungen am externen Router (wobei ich da nicht viel einstellen kann, da vom örtlichen Provider gestellt)?

Laut diesem Thread scheint dieses Setup ja prinzipiell möglich zu sein, ich habe mich allerdings trotzdem dazu entschieden einen extra Thread zu öffnen, um die Themen nicht zu vermischen.
Gibt es für solch eine Szenario eine Anleitung bzw. welche Bedingungen werden hierfür benötigt?
Oder habe ich noch wichtige Informationen vergessen?
Vielen lieben Dank für eure Hilfe!!!

LG Stefan

 

[jo_nas]

Sehe ich das richtig, dass die Fritzbox im Ferienhaus der VPN Initiator sein muss?

Ja, es klingt als wäre das vernünftig. Du kannst dir ja meine Konfiguration in dem von dir verlinkten Thread anschauen und natürlich dementsprechend die Daten ändern. Bei mir ist die 7390 der Initiator, das darf auch nicht verwechselt werden weil bei mir der Initiator (fast) den gesamten Traffik über den Tunnel schiebt und der Responder ja nur Pakete die zum Initiator sollen. Außerdem brauchst du bei diesem Setup nur einen DynDNS, nämlich den vom Responder.

Speichere die beiden Konfigurationen am besten in einem Ordner. Du kannst die dann auf der jeweiligen Fritzbox per Internet->Freigaben->VPN->VPN-Verbindung hinzufügen->[...] importieren.

Was du beachten musst:
- Du musst wahrscheinlich physisch den Import der VPN-Datei mit Drücken eines Knopfes auf der Fritzbox "bejahen".
- fqdn's dürfen soweit ich weiß einen beliebigen Namen haben, allerdings müssen die unterscheidbar sein.
- Statt "$key" denkst du dir ein langes zufälliges Passwort aus, muss man sich nicht merken können, am Ende steht da sowas: `key = "23498asdfiuKJDFIZ";`
- Vergiss die Semicoli nicht
- `name` kann sein, was du willst
- phase2localid <-> phase2remoteid werden einmal getauscht, weil das ja aus dem jeweiligen Standpunkt ist
- phase1ss, phase2ss können möglicherweise geändert werden, das hängt aber von der Fritzbox ab, wichtig scheint mir, dass sich die beiden Konfigs übereinstimmen


Es hilft wahrscheinlich, wenn du dir aufschreibst, welche IP's in meiner Config auf deine IP's passen sollen und dann nacheinander das durchgehst und abänderst. Wenn du das erfolgreich geschafft hast landest du bei dieser Situation:
- Du kannst die IP's jeweils von beiden netzen aus anpingen
- Du kannst nicht die Hostnamen im anderen Netz auflösen, weil ja in der Config unter accesslist steht, dass wir den DNS port 53 nicht über den VPN Tunnel schieben wollen.

Dinge die noch helfen könnten: fritz.box/html/capture.html. Den Großteil der Verkehrs kannst du mit der Routing Schnittstelle abgreifen. Dauert nach dem Klicken etwas bis der Paketdump funktioniert.

Leider kann ich dir zu IKE-Error 0x2027 nicht viel sagen, nur dass der mir schon sehr häufig über den Weg gekommen ist.


Viel Erfolg.

 

[Loewe81]

Danke jo_nas für die ausführliche Antwort.
Was soll ich sagen, es geht schon ohne weiteres zutun.
Ich hatte gestern parallel noch den Support vom örtlichen Provider des Ferienhauses angeschrieben. Dieser hatte mir zwar heute Nachmittag geantwortet, dass sie mir bei dem VPN-Problem nicht weiterhelfen können, aber zumindest deren "DMZ"-Option auf die korrekte IP (nämlich die 192.168.1.2) geändert hatten. Ich meine zwar, dass ich gestern diese Option mit beiden möglichen Fritzbox-IPs (192.168.1.2 & 192.168.178.1) ausprobiert habe, aber vielleicht hatte ich dann die richtige IP mit der falschen Fritzbox-Konfiguration aktiv. Auf jeden Fall habe ich seit gestern Abend an den Fritzboxen nichts geändert und als ich gerade nochmal drauf geschaut habe, war der Tunnel auf einmal oben.
Sprich ich kann von meinem lokalen Laptop zu Hause die interne IP der Fritzbox im Ferienhaus (192.168.178.1) pingen.
Bei der "DMZ"-Option des Providers steht das in der Beschreibung:

Die DMZ Funktion öffnet alle Ports für eine spezifische lokale IP Adresse, begrenzt damit den Datenverkehr nur an diese IP Adresse.

Ich hoffe damit geht dann der lokale Traffic bzw. Internet-Verkehr im Ferienhaus immer noch (kann ich ja gerade nicht testen).
Dazu habe ich dann auch nochmal eine abschließende Frage, in einigen Anleitungen von AVM steht, dass man noch angeben kann, welcher Traffic durch den Tunnel gehen soll. Also quasi split-Tunnel, wo nur IPs auf der "Gegenseite" durchgehen und z.B. Internet-Traffic lokal rausgeht. Oder alles durch den Tunnel, sprich auch Internet-Traffic, und die "Gegenseite" ist dann der Internet-Breakout.
Bei mir würde ggf. in Frage kommen, dass ich gerne im Ferienhaus den kompletten Traffic durch den Tunnel schicken möchte. Was müsste ich dafür einstellen und wo? Oder ist das in der GUI nur bei bestimmten Fritzbox-Modellen bzw. ab einer bestimmten FritzOS möglich? Oder muss ich das über eine cfg-Datei einspielen? Gibt es zu dieser cfg-Datei eine Dokumentation, welche Parameter es alles gibt und wann man diese wie zu benutzen hat?
Danke!

LG Stefan

 

[Micha0815]

dass ich gerne im Ferienhaus den kompletten Traffic durch den Tunnel schicken möchte. Was müsste ich dafür einstellen und wo?

Das lässt sich in der vpn.cfg und dort accesslist einstellen. Da gibt es imho auch einen älteren thread zu. "Gesamten Traffic über die VPN-Verbindung ..." oder so ähnlich.
LG

 

[jo_nas]

Bei mir würde ggf. in Frage kommen, dass ich gerne im Ferienhaus den kompletten Traffic durch den Tunnel schicken möchte

Spätestens da wärst du bei meiner Problematik angelangt: Das Henne-Ei-Problem. Wenn du den gesamten Traffic über den VPN schicken willst, wie soll der Tunnel denn am Anfang aufgebaut werden? Traffic, der nicht durch den Tunnel gehen soll ist ja dann verboten.

Lösung: Ausnahmen für Protokolle, die den Tunnel aufbauen. Deswegen steht in accesslist auch immer mindestens sowas hier: reject udp any any eq 500, der dafür sorgt, dass Protokolle die Port 500 nutzen, nicht durch den Tunnel dürfen. Und ISAKMP (Protokkoll zum Aushandeln des Tunnels) arbeitet standardmäßig über Port 500. Ähnliches gilt für Port 4500.

Das was ich gerade geschrieben habe ist allerdings kein Problem, Port 500 kann meinetwegen immer *nicht* über den Tunnel laufen. Das ist hier das Problem:

Ich möchte einen Tunnel aufbauen, und zwar soll erst über Port 53 (DNS) die IP des Responders herausgefunden werden (weil die wie bei dir dynamisch ist), dann soll der Tunnel aufgebaut werden, und abschließend soll der Traffic von Port 53 nun über den Tunnel gehen. Es ergibt sich also daraus die Problematik, dass Port 53 quasi zustandsabhängig ist: Ist kein Tunnel aufgebaut, braucht der Port 53 Zugang zum Internet ohne Tunnel; steht der Tunnel soll Port 53 darüber laufen. Das lässt sich so auch im vom Michael0815 zitierten Beitrag lesen.

Ich bin schon etwas weiter gekommen, aber es ist mühsam. Sobald ich was habe, werde ich das in diesem Thread schreiben.

 

[PeterPawn]

Was soll ich sagen, es geht schon ohne weiteres zutun.

Zufällig ... das kann sich auch ganz schnell wieder ändern.

Warum?

Die VPN-Implementierung in der 7390 ist eine ältere (iirc) - die hatte noch Probleme, wenn eine Verbindung aus beiden Richtungen aufgebaut werden sollte. Wenn eine Richtung in ein Timeout läuft, werden auch die bereits eingerichteten SA für die Gegenrichtung wieder abgeräumt. Daher MUSS man auf der 7390, die nur als "Responder" arbeiten soll, auch tatsächlich eine handgemachte Konfiguration verwenden, in der remote_hostname und remoteip NICHT gesetzt sind (das geht über das GUI nicht), damit diese Box gar nicht erst auf die Idee kommen KANN, eine eigene Verbindung aufbauen zu wollen. Ansonsten geht das - spätestens wenn es beide wieder (annähernd) gleichzeitig versuchen - doch wieder in die Hose.

---

Und zum Thema DNS-Abfrage bei "alles durch den Tunnel" ... eine Adresse, die schon bekannt ist, braucht man beim Aufbau einer VPN-Verbindung auch nicht mehr aufzulösen.

Wenn man das also so skriptet, daß zuerst die Adresse des Peers ermittelt wird, danach diese Adresse (zunächst mal) statisch auf der FRITZ!Box hinterlegt wird (die befragt aber nicht den multid, sondern die eingestellten DNS-Server für ihr WAN) und jetzt aktiviert man die VPN-Verbindung (das sind mehr als zwei Zustände - aktiviert und aktiv sind unterschiedliche Paar Schuhe), dann schafft man es vermutlich auch, daß dann für den VPN-Peer keine neue Abfrage benötigt wird. Außerdem könnte man auch gleich die remoteip eintragen, dann braucht's gar keine DNS-Abfrage (nach der ersten) mehr.

Nur braucht das dann auch noch etwas Lametta drumherum - schließlich muß man ein Abreißen der VPN-Verbindung ebenso mitbekommen, wie man dann erst mal die VPN-Definition wieder deaktivieren muß, damit man per DNS-Abfrage die neue Adresse des Peers ermitteln kann. Das KANN man machen (oder zumindest versuchen) ... aber das ist auch nicht ganz so einfach und will danach gut getestet sein, sonst hat man nur irgendwelchen instabilen Mist verzapft.

 

[Loewe81]

Nochmal wegen dem Traffic, der durch den Tunnel geht.
Da ich die Konfiguration nur über die Oberfläche, also ohne cfg-Datei, gemacht habe, wird standardmäßig nur der Traffic vom Remote-Netz durch den Tunnel geschickt, richtig?
Eigentlich möchte/brauche ich gar nicht allen Traffic durch den Tunnel, sondern nur von bestimmten Clients/Laptops. Sprich ich bräuchte einen Filter basierend auf der Source-IP. Und das kann ich dann nur über die cfg-Datei bewerkstelligen, richtig? Und wie würde es dann aussehen?
Gibt es eine Möglichkeit, die aktuelle Konfiguration in eine cfg-Datei zu exportieren, so dass ich diese dann nur noch erweitern muss? Oder muss ich mir die cfg-Datei immer komplett selber erstellen?
Danke!

LG Stefan

 

[jo_nas]

Und das kann ich dann nur über die cfg-Datei bewerkstelligen, richtig? Und wie würde es dann aussehen?

Ich bin mir ziemlich sicher, die Antwort darauf ist: Ja. Die Konfigurationsoberfläche ist ziemlich limitiert. Für alles Weitere braucht es entweder dieses Offline-Konfigurationstool das AVM anbietet, eine manuelle Config wie die bei mir, oder etwas Anderes als eine Fritzboxsoftware.

Ich glaube man kann eine Sicherungskopie der aktuellen Fritzboxkonfiguration irgendwo unter System erstellen, in dieser steht dann irgendwo was mit `vpncfg`. Leider ist alles schlecht bis garnicht dokumentiert oder ein alten Forenbeiträgen erarbeitet.

Die Quintessenz ist dahingehend dann der Parameter `accesslist`, der entscheidet maßgebend was durch den Tunnel soll und was nicht. Wichtig hierbei ist auch zu wissen dass dieses sogenannten Access Control Lists stateless sind, also die Regeln gelten immer. Unabhängig davon ob der Tunnel aufgebaut ist oder nicht (was ja das Problem wie in #5 beschrieben ist).

ich würde dir da erstmal empfehlen, die Suchfunktion vom Forum zu nutzen. Das wort accesslist ist eindeutig genug um Beispiele dahingehend zu finden. Oder google mit "site:ip-phone-forum.de <Stichwörter>" um Google auf diese Domain zu begrenzen.

 

[kleinkariert]

Das bekommst du bei Boxen ab 7.29 ohne Gefummel:



Für alle, die schon ewig kein VPN mehr per WebIF erstellt haben. ;-)

 

[jo_nas]

Uh, oh. Löst denn die Option "Gesamten Netzwerkverkehr über die VPN-Verbindung senden" auch DNS auf?

 

[B612]

bei Boxen ab 7.29 ohne Gefummel:

Nur gibt es die für seine 7390 und 7412 nicht.

 

[PeterPawn]

Leider ist alles schlecht bis garnicht dokumentiert oder ein alten Forenbeiträgen erarbeitet.

Kannst Du das bitte mal "spezifizieren", ob das nun "Bedauern" oder "Kritik" (wenn letzteres, an wem dann konkret) zum Ausdruck bringen soll? Man könnte das ja auch leicht mißverstehen und jetzt gespannt auf DEINE Dokumentation des Ganzen warten, die es nachfolgenden Lesern dann wieder viel einfacher macht, die richtigen Informationen zu finden. Solchermaßen mißinterpretiert zu werden, nagt dann bei mir auch wieder an den "credits", die Du Dir mit der Empfehlung für eine Suche erarbeitet hast.

Nur gibt es die für seine 7390 und 7412 nicht

Kommt Zeit, kommt Rat - sagte meine Oma immer (und die lebt schon länger nicht mehr, hat es damit aber auch nicht mehr so eilig wie früher). Vielleicht muß man ja nur lange genug warten?

richtig?

Nein. Wäre das so, würdest Du ja nie eine Antwort erhalten, denn die erfolgt nun mal in der Gegenrichtung.

 

[B612]

Vielleicht muß man ja nur lange genug warten?

Ja bis zum Tod. Dann hat sich das Problem zwar nicht gelöst aber erledigt.

 

[jo_nas]

Kannst Du das bitte mal "spezifizieren", ob das nun "Bedauern" oder "Kritik"

Klar: Bedauern. Ich habe keine offizielle Dokumentation gefunden, die die Parameter genauer dokumentiert, und das ist schade. Alles haben - dankenswerterweise - Forenmitglieder in Beträgen oder Blogs erarbeitet. Ich meine eigentlich, dass ich mich damit klar genug ausgedrückt habe.

Falls du dich persönlich damit angegriffen haben solltest, möchte ich dir sagen, dass das nicht meine Absicht war. Auch nicht zum Beispiel mit Beiträgen in meinem Thread. Ich hatte nämlich schon da das Gefühl, dass du das persönlich nimmst.

Es ist nämlich so: Ich - und ich nehme auch an Lowe81 - haben jeweils ein Problem, das der jeweilige gelöst haben möchte und dafür auf Hilfe angewiesen ist. Von diesem Standpunkt aus, liegt Kritik also weder nahe, noch wäre sie konstruktiv.

Eine Dokumentation würde erfolgen, wenn mein Versuch ja erfolgreich oder gescheitert wäre. Was du mit "Credits" meinst, weiß ich nicht.

 

[PeterPawn]

Was du mit "Credits" meinst, weiß ich nicht.

Die Redewendung: "bei jemandem Kredit haben" bzw. "seinen Kredit verspielen" kennst Du nicht? Auch mit der Übersetzung "Anerkennung" oder "Achtung", die man verspielen kann bzw. an der es dann Abstriche gäbe, ergibt ja noch Sinn, oder?

---

Ich bin ja nur erstaunt, wenn jemand innerhalb von nicht mal einer halben Stunde in drei verschiedenen Beiträgen seinem "Bedauern" Ausdruck verleiht (13:33 Uhr hier, 13:36 Uhr und 13:47 Uhr im anderen Thread, auch wenn ich auf die Zeiten erst nachträglich geschaut habe), wie schlecht das doch alles dokumentiert ist (ohne zu erwähnen, von WEM er so eine Dokumentation jetzt eigentlich erwarten würde) und wie mühsam es für ihn war, diese Informationen für sich zusammenzutragen ... da kann man ja irgendwie schon den Eindruck gewinnen, daß Dich das überproportional beschäftigt hat und da Du es an allen drei Stellen geschafft hast (zumindest in meinen Augen), das "in der Schwebe" zu lassen, worauf sich das letztlich beziehen soll, dachte ich mir: Frag doch mal nach.

Ich hatte nämlich schon da das Gefühl, dass du das persönlich nimmst.

Wenn Du das meinst, was ich NACH dieser Frage hier im Thread geschrieben habe ... ja, kann schon sein. Es gibt eben auch hier immer wieder Leute, denen das, was angeboten wird, nicht reicht und die dann immer wissen, wie sie es VIIIEEEL besser machen würden - nur machen sie es eben dann doch (fast) nie.

Daß Deine Worte jetzt jeweils auch nicht gerade so gewählt waren, daß tatsächlich darin nur "Bedauern" über fehlende Dokumentation seitens des Herstellers zum Ausdruck kommen sollte/konnte und nicht etwa "Kritik" daran, daß das HIER so "schlecht bis gar nicht" dokumentiert und obendrein nicht irgendwo alles "zusammengefaßt" wäre, wirst Du sicherlich (wenn Du das noch einmal unter diesem Aspekt liest) auch nicht bestreiten ... aber danke für die Klarstellung.

Ich hatte auch ZUERST die beiden Beiträge im anderen Thread gelesen und danach dann noch Deinen Beitrag hier, aus dem ich zitiert habe - dieses "dritte Mal" war dann auch der Punkt, wo es mir "etwas drüber" erschien, daher hier die ERSTE Reaktion meinerseits. Die "relativ mühevolle Recherche" im anderen Thread verstehe ich dann (den Link, WARUM ich das nicht verstehe, habe ich dort ja präsentiert) eben auch noch nicht so richtig - auch wenn "relativ" natürlich genau das auch ist und da vermutlich jeder unterschiedliche Vorstellungen hat, wo die "Mühe" dann beginnt und wieviel davon "zumutbar" ist.

 

[Micha0815]

Nurmalso Die aktuell laufende VPN.cfg kann man/frau aus der *.export (oder auch support-datei) per copy&paste herausziehen und mit einem geeigneten Editor -ich bevorzuge notepad++ unter Windows- in Bezug auf die accesslist-Erweiterung hin und/oder anderes bearbeiten. Die verschlüsselten "Zeilen" können auch so belassen werden, um eine Testvariante als *vpn.txt zu importieren.

Die alte 7390 mag u.U. nicht sämtliche Änderungen, die möglich erscheinen ... iirc mag sie "editable=yes" in der cfg garnicht.

Die besondere Syntax in der accesslist bzgl. Kommata und Semikolon bei eigenständigen Erweiterungen sollte man vorab nachgelesen haben, bevor man/frau sich aussperrt

Ein Suche nach Responder Initiator bringt auch sehr schnell gute und fast fertige Vorlagen zutage

Und wenn ich in einer VPN-Config die 192.168.188.0/24 lese, rollen sich mir stets die Fussnägel auf, da das Netz üblicherweise dem Gastnetz einer FB (192.168.178.1) zugeordnet wird und eigentlich Tabu in einer LAN-LAN-VPN-Config sein sollte, da dadurch stets "Ärger" vorprogrammiert wird.
LG

 

[jo_nas]

Hm, wenn du das so meinst, kann ich dir sagen dass ich das so nicht sehe. Mir liegt es wirklich nur daran, eine Lösung für ein Problem zu finden, oder anderen dabei zu helfen soweit es mir möglich ist. Deswegen werde ich auch nicht auf die Erklärung darunter eingehen, zumal das auch OT wäre.

Nur eins: Wenn du das Gefühl bekommen hast, dass das Erstellen und Herausfinden der VPN-Konfigurationsdatei mühevoll war, dann liegst du richtig. Daraus abzuleiten, dass das als Kritk an diesem Forum oder Mitgliedern zu verstehen ist, wäre jedoch falsch: Mit Herstellerdokumentation wäre ich vielleicht nicht hier.

 

[Loewe81]

Zufällig ... das kann sich auch ganz schnell wieder ändern.

Ja, sieht leider so aus.
Der Tunnel ist wieder down
Bin jetzt auf cgf-Dateien umgestiegen, aber damit bekomme ich es auch nicht zum Laufen.
Anbei die zwei Inhalte:
Ferienhaus (7412 mit 6.87)

vpncfg {
    connections {
        enabled = yes;
        conn_type = conntype_lan;
        name = "vpn_name";
        always_renew = yes;
        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;
        localid {
            fqdn = "dyndns_externer_router";
        }
        remoteid {
            fqdn = "xxx.myfritz.net";
        }
        mode = phase1_mode_aggressive;
        phase1ss = "all/all/all";
        keytype = connkeytype_pre_shared;
        key = "xxx";
        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.0.0;
                mask = 255.255.255.0;
            }
        }
        phase2ss = "esp-all-all/ah-none/comp-all/pfs";
        accesslist = "permit ip any 192.168.0.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";
}

zu Hause (7390 mit 6.87)

vpncfg {
    connections {
        enabled = yes;
        conn_type = conntype_lan;
        name = "vpn_name";
        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; // diese Zeile hatte ich auch schon komplett draußen
        remote_virtualip = 0.0.0.0; // diese Zeile hatte ich auch schon komplett draußen
        localid {
            fqdn = "xxx.myfritz.net";
        }
        remoteid {
            fqdn = "dyndns_externer_router";
        }
        mode = phase1_mode_aggressive;
        phase1ss = "all/all/all";
        keytype = connkeytype_pre_shared;
        key = "xxx";
        cert_do_server_auth = no;
        use_nat_t = yes;
        use_xauth = no;
        use_cfgmode = no;
        phase2localid {
            ipnet {
                ipaddr = 192.168.0.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";
}

Nachdem ich die zwei Dateien jeweils eingespielt habe, steht dann unter "Adresse im Internet" immer 0.0.0.0. Interessant ist auch, dass ich aktuell keine Timeout-Fehler mehr im Log sehe (auch keine anderen Fehler), als ob er gar nichts machen würde, was aber eigentlich zumindest bei der Fritzbox im Ferienhaus der Fall sein sollte, weil die ja auf always_renew=yes steht.
Wie könnte man den Fehler weiter analysieren?
Danke!

LG Stefan

 

[PeterPawn]

Woher soll jetzt die FRITZ!Box im Ferienhaus wissen, WO sie nach der 7390 suchen soll? Jetzt sind sie also beide "Responder" und keine wird (nein: KANN) die aktive Rolle übernehmen. Bei der 7390 ist das so korrekt (die würde die 7412 ja ohnehin nie erreichen können, da ist noch ein Türsteher zu überwinden), aber die 7412 sollte sich schon etwas mehr anstrengen, damit da wieder Schwung in die Beziehung Verbindung kommt ... vielleicht verrätst Du der ja doch, in welchem Etablissement sich die 7390 immer wieder mal herumtreibt (am besten die DynDNS-Adresse dort) und wo man ihr damit dann auch "auflauern" könnte.

Den Rest der Konfiguration habe ich gar nicht mehr angesehen - sollten da noch weitere Probleme schlummern, bemerkt man die auch noch früh genug.

 

[Loewe81]

Woher soll jetzt die FRITZ!Box im Ferienhaus wissen, WO sie nach der 7390 suchen soll? Jetzt sind sie also beide "Responder" und keine wird (nein: KANN) die aktive Rolle übernehmen.

Offensichtlich habe ich wohl einen Fehler begangen, der auch noch so banal und offensichtlich ist, dass er hier nicht näher erklärt werden muss. Und mit always_renew = yes; hatte ich zumindest geglaubt, dass dies der aktiven Rolle entspricht und remoteid die Ziel-Adresse (in dem Fall der DynDNS-Name) ist. Oder muss auch bei remoteip ein Wert eingetragen werden? Diesen habe ich auf 0.0.0.0 gelassen, weil dies zum Einen auch der Output vom "Fritz!Fernzugang einrichten"-Tool war und zum Anderen ein DynDNS-Name keine IP-Adresse ist und ich somit davon ausgegangen bin, dass ein solcher Wert für diesen Parameter syntaktisch falsch ist. Oder geht es hier gar nicht um diese Parameter und der vermeintliche Fehler befindet sich an ganz anderer Stelle?
Eine weitere poetische Umschreibung des Problems ist daher wohl unumgänglich.
Vielen lieben Dank an dieser Stelle für die Geduld mirgegenüber!

LG Stefan