IPv4/6 - Problem mit Zugriff

[geohei]

Ich war zu voreilig.

Auf beiden Seiten habe ich eine DDNS für die andere FB benutzt die IPv4 auflöst. M.a.W. haben beide FBs IPv4 Adressen für den VPN Tunnel Aufbau benutzt. Als ich auf einer Seite (und später zu Testzwecken auf beiden Seiten) die IPv6 Adresse eingetragen hatte wurde der Tunnel nicht mehr erstellt.

Geht es also etwa doch nur mit IPv4?

Wäre ggf in der Accesslist Zeile in Konfig zu ändern. VPN geht sonst beide Richtungen. Also Gegenseite sieht auch dein Client.

Die Accesslist bekommt man doch nur mittels der FRITZ!Box Fernzugang Software.
Diese Software ist bei einer LAN-LAN VPN Verbindung, wie ich sie jetzt möchte, ja gar nicht anwendbar da alles über das Web Interface der beiden FBs abgewickelt wird.

 

[geohei]

An meinem NAS geht es zumindest, VPN wird über IPv6 aufgebaut weil es beide Seiten können, und Inhalte im Tunnel sind IPv4.

Wie?
Ist VPN über IPv6 aufgebaut oder NAS-Client über IPv6?
Oder beides?

Was hast du bei den VPN Verbindungen der beiden FBs eingetragen?
Eine feste IPv6 oder eine IPv6 auflösende DDNS?

Ist habe jetzt weitere Tests gefahren.
FB VPN verbindet hier mit 2 dual stack Verbindungen definitiv nicht über IPv6!
Weder mit IPv6 fähiger DDNS, noch mit fester IPv6.

 

[Theo Tintensich]

Theoretisch müsste man durch einen Tunnel, der über eine IPv6-Strecke geht, auch IPv4-Daten tunneln können.
Denn das sind Netzwerk-Logisch zwei unterschiedliche Netzwerk-Strecken.

Das es nicht geht liegt wohl an der Konfiguration des Tunnels.
Dieser muss 'im Tunnel' natürlich auch ein IPv4-Netz aufbauen.

 

[geohei]

Ja, alles klar soweit, aber das ist jetzt FB unabhängige Theorie.
Praktisch gesehen ...wie übersetzt man das in die FB Einstellungen?
Als erstes müsste man wissen ob die FB IPv6 VPN Tunnels überhaupt unterstützt.
Bis jetzt habe ich noch niemanden gefunden der ds genau so mit 2 FBs gemacht hat.
Auch Google schweigt sich aus.
Die AVM Support Seiten sowieso.

 

[HabNeFritzbox]

Wegen der Accesslist, kannst auch dir ne Konfigvorlage im Texteditor bearbeiten und anpassen.

Ich verwende die FB selbst nicht für VPN, sondern mein NAS.

Die FB ignoriert für VPN die Priorisierung bzw. Trafficverteilung, und daher zerrt VPN bei voller Leitungsbelegung alles weg, so dass es bei VoIP Telefonie ggf. zu Aussetzern kommt ect.

 

[geohei]

Die accesslist behandle ich in einem separaten Thread.

Ich möchte vorerst einfach nur wissen ob ein FB VPN Verbindungsaufbau mittels IPv6 möglich ist.

Folgender Test:

Netz A (meins)
DDNS löst IPv4 und IPv6 auf (netz_a.dyn.org)
IPv4 ist public!

Netz B (Freund 1)
DDNS löst IPv4 und IPv6 auf (netz_b.dyn.org)
IPv4 ist public!

Netz C (Freund 2)
DDNS löst IPv4 und IPv6 auf (netz_c.dyn.org)
IPv4 ist nicht public, daher zeigt sie auf das Gateway des Providers und ist unbenutzbar!

Ich möchte jetzt Netz A/B und Netz A/C Verbindungen herstellen.
Netz A/C Verbindung ist das Problem da die IPv4 nicht public ist!

In der FB VPN .cfg von Netz A habe ich jetzt für Netz C folgende 3 Einträge händisch geändern. Sonst habe ich nichts angefasst; weder in der .cfg von Netz A, noch der von Netz B oder C.

remotehostname = "netz_c.dyndns.org"; # DDNS
remotehostname = "2001:1614:1242:d3f2::dead:beef"; # IPv6 mit ""
remotehostname = 2001:1614:1242:d3f2::dead:beef; # IPv6 ohne ""

Bei keinem der 3 Versuche gelingt der Verbindungsaufbau Netz A/C.

Wenn ich den gleichen Test mit Verbindung Netz A/B mache führen alle 3 Versuche erfolgreich zum VPN Aufbau.

Aus irgend einem Grund benötigt die FB VPN Verbindung eine public IPv4.

Was habe ich übersehen?

 

[HabNeFritzbox]

Im Browser schreibt man die IPs in [ ]

Schon probiert mit Hostnamen der nur AAAA Record hat?

 

[geohei]

Im Browser benutze ich ja auch [].
In der accesslist kann ich diese aber weglassen, wie der IPv6 Verbindungsaufbau Netz A/B zeigt.
Ich habe es jetzt trotzdem einmal mit den [] in der accesslist versucht (mit und ohne "").
Kein Verbindungsaufbau!

Einen reinen AAAA DDNS Hostname habe ich noch nicht ausprobiert. Aber was wäre der Unterschied zwischen diesem und einem IPv6 Eintrag wie in meinem Test? Der AAAA DDNS Eintrag tut ja sonst auch nichts anderes als eine IPv6 ausgeben, was ich ja mit dem direkten Eintrag der IPv6 übergehe (und somit vereinfache).

IMHO passiert hinter den Kulissen etwas was public IPv4 nötig macht.

 

[HabNeFritzbox]

Unterschied wäre, dass wenn der VPN Dienst sich an IP stört halt ein Hostname wäre. Bei nur AAAA gäbe es keine Option auf IPv4 zurück zugreifen.

Und kannst natürlich IP im DNS ändern ohne Config ändern zu müssen.

 

[geohei]

Der VPN Dienst stört sich aber nicht an der festen IPv6, wie der Test Netz A/B mit fester IPv6 in der VPN .cfg in Netz A für Netz B zeigt. Siehe Posting #26:

...
Wenn ich den gleichen Test mit Verbindung Netz A/B mache führen alle 3 Versuche erfolgreich zum VPN Aufbau.
...

Ich habe jetzt noch einmal einen ausführlichen Test gemacht. Da scheint mir wirklich etwas zu entgehen.

Nochmal zusammenfassend.

Netz A (meins)
DDNS löst IPv4 und IPv6 auf (netz_a.dyn.org)
IPv4 ist public!

Netz B (Freund 1)
DDNS löst IPv4 und IPv6 auf (netz_b.dyn.org)
IPv4 ist public!

Netz C (Freund 2)
DDNS löst IPv4 und IPv6 auf (netz_c.dyn.org). Auch wenn DDNS nur IPv6 auflöst ändert das nichts!
IPv4 ist nicht public, daher zeigt sie auf das Gateway des Providers und ist unbenutzbar!

DDNS = z.B. remotehostname = "netz_a.dyndns.org";
IPv6 = DDNS = z.B. remotehostname = "2001:1614:1242:d3f2::dead:beef";

1.
Netz A VPN Eintrag für Netz B : DDNS
Netz B VPN Eintrag für Netz A : DDNS
-> Verbindung : OK !!!
2.
Netz A VPN Eintrag für Netz B : IPv6
Netz B VPN Eintrag für Netz A : DDNS
-> Verbindung : keine
3.
Netz A VPN Eintrag für Netz B : DDNS
Netz B VPN Eintrag für Netz A : IPv6
-> Verbindung : OK !!!
4.
Netz A VPN Eintrag für Netz B : IPv6
Netz B VPN Eintrag für Netz A : IPv6
-> Verbindung : keine

5.
Netz A VPN Eintrag für Netz C : DDNS
Netz C VPN Eintrag für Netz A : DDNS
-> Verbindung : keine
6.
Netz A VPN Eintrag für Netz C : IPv6
Netz C VPN Eintrag für Netz A : DDNS
-> Verbindung : keine
7.
Netz A VPN Eintrag für Netz C : DDNS
Netz C VPN Eintrag für Netz A : IPv6
-> Verbindung : keine
8.
Netz A VPN Eintrag für Netz C : IPv6
Netz C VPN Eintrag für Netz A : IPv6
-> Verbindung : keine

Ich sehe wirklich keinen anderen Grund als dass beide IPv4s public sein müssen.

Zudem ist für mich nicht nachvollziebar, warum Test 2 nicht funktioniert. Ist doch nichts Anderes als Test 3, nur umgedreht? Ich habe das mehrmals überprüft.

 

[HabNeFritzbox]

Gibt es nur bei LAN Koppelung via VPN Probleme oder auch wenn Problem Box nur als einfacher Client genutzt wird?

 

[PeterPawn]

@geohei:
Ich habe zugegenermaßen keine Lust, den gesamten Thread zu lesen, ich verstehe ja noch nicht einmal, ob Du bei den Tests tatsächlich auf beiden Seiten die IPv6 einträgst (in welchem Format eigentlich), wenn da etwas von "IPv6" bei Dir steht ... auch ist "keine Verbindung" etwas wenig als Fehlermeldung. Was steht denn jeweils in der /var/tmp/ike.log der beiden Boxen?

Aber wenn ich Deine Ziele richtig verstehe, geht es doch nur darum, daß Netz A und Netz C überhaupt miteinander können und nicht darum, wer da die Verbindung aufbaut. Dann laß doch nur Netz C als Initiator arbeiten und mache Netz A (für die Verbindung zu Netz C) zum passiven Responder. Dann kann problemlos die IPv4-Verbindung über das CGN verwendet werden und Du bist das "IPSec over IPv6"-Problem erst einmal los.

Wenn es gar nicht um eine funktionierende Lösung geht, sondern nur um die prinzipielle Machbarkeit eines IPv4-/IPv6-Mixes beim VPN, vergiss meinen Einwand einfach.

EDIT: Ich konnte es mir nun doch nicht verkneifen, wenigstens in #30 so etwas ähnliches wie eine Systematik zu suchen. Was mir auffällt, ist erst einmal ein Widerspruch zum vorher irgendwo im Test geäußerten "IPv4 über IPv6-VPN-Tunnel funktioniert zwischen A und B" und den Ergebnissen in #30 auf. Denn von 8 Fällen funktionieren ja gerade einmal zwei. Ob dabei dann tatsächlich IPv6 zum Einsatz kommt, kann man - solange Du nicht mal eine komplette Konfiguration für beide Seiten hier einstellst als Beispiel für eine IPv6-Konfiguration - auch nicht sehen.

Wenn Du tatsächlich am Ende nur den "remotehostname" änderst und weiterhin beide Seiten die Verbindung aufbauen dürfen, dann kann es ja in Test 3 sogar so gewesen sein, daß da Netz A eine IPv4-Verbindung zur DynDNS-Adresse von Netz B aufgebaut hat. Netz B findet dann Netz A schon deshalb nicht, weil keines der Formate für eine IPv6-Adresse funktioniert ... das wäre auch eine mögliche Erklärung (die muß nicht zwangsläufig richtig sein). Wenn Du das tatsächlich klären willst, mußt Du schon dafür sorgen, daß da keine IPv4-Adressen benutzt werden können ... wenn Du das aber tatsächlich machst, wie in Test 4 und 8, klappt ja keine Verbindung mehr.

Also ist die Frage, ob da tatsächlich IPv6-Adressen in einer VPN-Konfiguration erfolgreich verwendet werden können, der alles entscheidende Test. Wenn ich es richtig verstanden habe, hast Du das noch nie abschließend geklärt. Erst wenn bei einer Deiner IP-Adressangaben in IPv6-Notation tatsächlich mal eine Verbindung zu einer Gegenstelle aufgebaut werden kann, erst dann kannst Du Dir einigermaßen sicher sein, was das Format angeht. Bis dahin ist das für mich alles "String" und in der Folge dann DNS-Name. Wenn man Zugriff auf den befragten DNS-Server hat, findet man das auch schnell heraus. Für eine IPv6-Adresse wird die Box schwerlich noch einmal eine A- oder AAAA-Abrfrage starten, wenn sie dieses Format nicht für einen DNS-Namen hält. Ansonsten hilft vermutlich auch die Protokoll-Datei der Box schon weiter, falls da etwas wie "host not found" drin steht.

 

[geohei]

Gibt es nur bei LAN Koppelung via VPN Probleme oder auch wenn Problem Box nur als einfacher Client genutzt wird?

Die Client Kopplung funktioniert, allerdings habe ich es nur mit Netz A getestet, welches IPv6 + public IPv4 hat.

Ich habe zugegenermaßen keine Lust, den gesamten Thread zu lesen, ich verstehe ja noch nicht einmal, ob Du bei den Tests tatsächlich auf beiden Seiten die IPv6 einträgst (in welchem Format eigentlich), wenn da etwas von "IPv6" bei Dir steht ... auch ist "keine Verbindung" etwas wenig als Fehlermeldung. Was steht denn jeweils in der /var/tmp/ike.log der beiden Boxen?

Wie oben beschrieben habe ich es mit IPv6 (mit und ohne "") und FQDN (DDNS, einmal mit IPv6 und non-plubic (DSLAM IPv4) IPv4 und dann mit IPv6 und leerem IPv4 Eintrag) versucht.

"Verbindung" entspricht dem "hergestellt" auf der FB Menüpunkt "Internet" neben "Fernzugang (VPN)"

Ich habe Telnet auf keiner der FBs aktiviert. Wenn du glaubst es bringt etwas werde ich es machen. Beim Log steht nur:

...
VPN error: netz_c, IKE-Error 0x2027
...

Aber wenn ich Deine Ziele richtig verstehe, geht es doch nur darum, daß Netz A und Netz C überhaupt miteinander können und nicht darum, wer da die Verbindung aufbaut. Dann laß doch nur Netz C als Initiator arbeiten und mache Netz A (für die Verbindung zu Netz C) zum passiven Responder. Dann kann problemlos die IPv4-Verbindung über das CGN verwendet werden und Du bist das "IPSec over IPv6"-Problem erst einmal los.

Dass es einen Initiator gibt wusste ich gar nicht. Dass einer der Teilnehmer die Verbindung aufbaut ist mir neu. Ich dache bei VPN LAN-LAN gäbe es bzgl. Hierarchie keine übergeordneten bzw. untergeordneten Rechner (passiver Responder)!? Wie erkenne ich den Initiatir bzw. konfiguriere diesen denn? Was ist CGN?

Wenn es gar nicht um eine funktionierende Lösung geht, sondern nur um die prinzipielle Machbarkeit eines IPv4-/IPv6-Mixes beim VPN, vergiss meinen Einwand einfach.

???
Es geht ume eine funktionierende Lösung.

EDIT: Ich konnte es mir nun doch nicht verkneifen, wenigstens in #30 so etwas ähnliches wie eine Systematik zu suchen. Was mir auffällt, ist erst einmal ein Widerspruch zum vorher irgendwo im Test geäußerten "IPv4 über IPv6-VPN-Tunnel funktioniert zwischen A und B" und den Ergebnissen in #30 auf. Denn von 8 Fällen funktionieren ja gerade einmal zwei. Ob dabei dann tatsächlich IPv6 zum Einsatz kommt, kann man - solange Du nicht mal eine komplette Konfiguration für beide Seiten hier einstellst als Beispiel für eine IPv6-Konfiguration - auch nicht sehen.

Wo ist der Widerspruch?
Stimmt - von 8 Fällen auf 2 Netze verteilt laufen nur 2 Tests, und zwar mit Netz B (dem mit der IPv6 + public IPv4).
Die Konfiguration poste ich gerne nachem Deine Antwort auf den Initiator/Responder noch immer keinen Klarheit bringt.

Wenn Du tatsächlich am Ende nur den "remotehostname" änderst und weiterhin beide Seiten die Verbindung aufbauen dürfen, dann kann es ja in Test 3 sogar so gewesen sein, daß da Netz A eine IPv4-Verbindung zur DynDNS-Adresse von Netz B aufgebaut hat. Netz B findet dann Netz A schon deshalb nicht, weil keines der Formate für eine IPv6-Adresse funktioniert ... das wäre auch eine mögliche Erklärung (die muß nicht zwangsläufig richtig sein). Wenn Du das tatsächlich klären willst, mußt Du schon dafür sorgen, daß da keine IPv4-Adressen benutzt werden können ... wenn Du das aber tatsächlich machst, wie in Test 4 und 8, klappt ja keine Verbindung mehr.

Test 3 funktioniert ja (du schreibst es wäre zu keiner Verbindung gekommen)!

Ich verstehe die Idee hier nicht. Willst du mir sagen, dass die Eingabe einer festen IPv6 grundsätzlich in "remotehostname" nicht funktioniert, egal in welchem Format (mit oder ohne "")? Oder etwa dass das FB VPN überhaupt nicht mit IPv6 klar kommt?

Also ist die Frage, ob da tatsächlich IPv6-Adressen in einer VPN-Konfiguration erfolgreich verwendet werden können, der alles entscheidende Test. Wenn ich es richtig verstanden habe, hast Du das noch nie abschließend geklärt. Erst wenn bei einer Deiner IP-Adressangaben in IPv6-Notation tatsächlich mal eine Verbindung zu einer Gegenstelle aufgebaut werden kann, erst dann kannst Du Dir einigermaßen sicher sein, was das Format angeht. Bis dahin ist das für mich alles "String" und in der Folge dann DNS-Name. Wenn man Zugriff auf den befragten DNS-Server hat, findet man das auch schnell heraus. Für eine IPv6-Adresse wird die Box schwerlich noch einmal eine A- oder AAAA-Abrfrage starten, wenn sie dieses Format nicht für einen DNS-Namen hält. Ansonsten hilft vermutlich auch die Protokoll-Datei der Box schon weiter, falls da etwas wie "host not found" drin steht.

Werde mir das Log dann doch einmal ansehen ...

...
2015-01-25 14:59:13 avmike:unknown remote peer supported XAUTH
2015-01-25 14:59:13 avmike:unknown remote peer supported DPD
2015-01-25 14:59:13 avmike:unknown remote peer supported NAT-T RFC 3947
2015-01-25 14:59:54 avmike:unknown remote peer supported XAUTH
2015-01-25 14:59:54 avmike:unknown remote peer supported DPD
2015-01-25 14:59:54 avmike:unknown remote peer supported NAT-T RFC 3947
2015-01-25 15:00:24 avmike:netz_c: Phase 1 failed (initiator): timeout, checking ip address
2015-01-25 15:00:24 avmike:< cb_sa_create_failed(name=netz_c,reason=IKE-Error 0x2027)
2015-01-25 15:00:34 avmike:unknown remote peer supported XAUTH
2015-01-25 15:00:34 avmike:unknown remote peer supported DPD
2015-01-25 15:00:34 avmike:unknown remote peer supported NAT-T RFC 3947
2015-01-25 15:01:48 avmike:unknown remote peer supported XAUTH
2015-01-25 15:01:48 avmike:unknown remote peer supported DPD
2015-01-25 15:01:48 avmike:unknown remote peer supported NAT-T RFC 3947
2015-01-25 15:02:24 avmike:netz_c: no SAs found, stopping dyndnscheck
2015-01-25 15:03:26 avmike:unknown remote peer supported XAUTH
2015-01-25 15:03:26 avmike:unknown remote peer supported DPD
2015-01-25 15:03:26 avmike:unknown remote peer supported NAT-T RFC 3947
2015-01-25 15:04:06 avmike:unknown remote peer supported XAUTH
2015-01-25 15:04:06 avmike:unknown remote peer supported DPD
2015-01-25 15:04:06 avmike:unknown remote peer supported NAT-T RFC 3947
2015-01-25 15:05:59 avmike:unknown remote peer supported XAUTH
2015-01-25 15:05:59 avmike:unknown remote peer supported DPD
2015-01-25 15:05:59 avmike:unknown remote peer supported NAT-T RFC 3947
2015-01-25 15:06:52 avmike:unknown remote peer supported XAUTH
2015-01-25 15:06:52 avmike:unknown remote peer supported DPD
2015-01-25 15:06:52 avmike:unknown remote peer supported NAT-T RFC 3947

In Zwischenzeit habe ich AVM auch angeschrieben. Ihre Antwort war nicht hilfreich, da 1:1 auf www.avm.de/vpn, die ich kenne:

...
Mindestens eine der beiden FRITZ!Boxen muss vom Internetanbieter eine
IPv4-Adresse aus dem öffentlichen Adressbereich für eine
LAN-LAN-VPN-Kopplung erhalten.

Mit freundlichen Grüßen aus Berlin,

--

Hallo.

Kann man einen VPN LAN-LAN Tunnel mit FB7490 FW06.20 mit native IPv6
aufbauen
ohne public IPv4 aufbauen (also nur mittels IPv6)?

Bitte jetzt keine fertigen Textblöcke schicken.
Bitte auch nicht auf die avm.de/vpn verweisen. Die kenne ich.

Danke!

Mit freundlichen Grüßen.

 

[PeterPawn]

Dass es einen Initiator gibt wusste ich gar nicht. Dass einer der Teilnehmer die Verbindung aufbaut ist mir neu. Ich dache bei VPN LAN-LAN gäbe es bzgl. Hierarchie keine übergeordneten bzw. untergeordneten Rechner (passiver Responder)!? Wie erkenne ich den Initiatir bzw. konfiguriere diesen denn?

Das kann man i.d.R. (so auch beim AVM-VPN) entsprechend konfigurieren, da es z.B. in einem "road warrior"-Szenario (wo also mindestens eine Seite keine statische IP-Adresse hat) ja keinen Sinn macht, wenn eine Seite gar nicht wissen kann, wo sie die andere findet. Theoretisch kann jede der beiden Seiten die Verbindung aufbauen ... es kann aber genauso die eine Seite (die besser erreichbar ist, das wäre bei Dir die mit IPv4) ausschließlich auf eingehende Verbindungen warten (Responder). Dann baut eben die andere Seite die Verbindung auf (Initiator). Auch bei gleichberechtigtem Verbindungsaufbau gibt es für eine konkrete Verbindung ja immer eine Seite, die diese initiiert hat, das ist eben die, die das erste Paket beim Verbindungsaufbau gesendet hat. Wenn das dann noch etwas unglücklich programmiert ist, wie es beim AVM-VPN offenbar der Fall ist, kann der versuchte Verbindungsaufbau von der ersten Seite sogar eine zwischenzeitlich installierte VPN-Verbindung (die von der zweiten Seite inzwischen aufgebaut wurde) nachträglich wieder aus dem Rennen werfen. Einen Responder konfiguriert man beim AVM-VPN ganz einfach durch Auslassen von "remotehostname" und "remoteip". Wenn die Box nicht weiß, wo die Gegenstelle zu suchen ist, kann sie auch keinen Aufbau einer Verbindung versuchen.

Was ist CGN?

http://de.lmgtfy.com/?q=CGN

Der erste Link nach dem Flughafen Köln-Bonn paßt schon ...

Es geht ume eine funktionierende Lösung.

Dann nimm die Lösung mit Verbindungsaufbau durch die Box mit DS-Lite-Anschluß und gut ist's.

Wo ist der Widerspruch?
Stimmt - von 8 Fällen auf 2 Netze verteilt laufen nur 2 Tests, und zwar mit Netz B (dem mit der IPv6 + public IPv4).

Wenn in diesem Fall dann die Box die Verbindung aufgebaut hat, die die andere Seite über den DynDNS-Namen gefunden hat (das müßte nach Deiner Nomenklatur Box A sein), dann sagt das ja nichts über die korrekte Übernahme der IPv6-Adresse als "Ziel" auf der Box B. Wenn diese IPv6-Adresse einfach als ungültiger DNS-Name aufgelöst wurde und damit Box B nicht wußte, wo Box A überhaupt zu suchen war, dann gibt es auch nicht die von mir erwähnte Kollision durch gleichzeitigen Verbindungsaufbau. Zur Thematik der Kollisionen gibt es irgendwo einen Parallel-Thread (irgendwas mit "LAN-LAN-Kopplung mit nur einer öffentlichen IPv4"), das schreibe ich nicht alles noch einmal.

Test 3 funktioniert ja (du schreibst es wäre zu keiner Verbindung gekommen)!

An welcher Stelle ? Ich schreibe, es wäre trotz der Angabe einer IPv6-Adresse in Box B (für die Adresse von Box A) zu einer Verbindung gekommen. Ansonsten bitte konkretes Zitat ...

Ich verstehe die Idee hier nicht. Willst du mir sagen, dass die Eingabe einer festen IPv6 grundsätzlich in "remotehostname" nicht funktioniert, egal in welchem Format (mit oder ohne "")? Oder etwa dass das FB VPN überhaupt nicht mit IPv6 klar kommt?

Das will ich damit nicht sagen, da ich es schlicht nicht weiß. Du aber offenbar auch nicht und obwohl Du Dir noch nicht einmal darüber im Klaren bist, ob die Angabe einer IPv6-Adresse überhaupt möglich ist und wenn ja, welches Format dann korrekt ist, nimmst Du Über-Kreuz-Tests mit DynDNS-Namen und IPv6-Adressen vor und leitest aus deren Ergebnissen ab, daß beide Seiten eine öffentliche IPv4-Adresse haben müssen, was definitiv falsch ist.

Ob tatsächlich direkt eine IPv6-Adresse angegeben werden kann (obwohl das als "remotehostname" schon Zweifel aufkommen läßt) bzw. ob der AVM-IKE-Daemon tatsächlich auch einen AAAA-Eintrag für die (aufgelöste) DynDNS-Adresse der Gegenseite akzeptiert (das wäre bei IPv6-only-Anschluß ja dann der einzige existierende/gültige/verwendbare DNS-Eintrag), weiß ich schlicht nicht. Aber das müßtest Du eben auch erst einmal sauber feststellen oder ausschließen, bevor Du auf Basis dieser Vermutung weitere Annahmen triffst ... jedenfalls solange Du diesen Umstand (daß es keine gesicherte Erkenntnis ist) bei Deinen weiteren Schlußfolgerungen nicht berücksichtigst.

 

[geohei]

Ich habe jetzt die non-public IPv4 auf dem DDNS Record herausgenommen und das ike.log hat sich geändert. Ein paar Mail pro Sekunde sehe ich jetzt das hier:

...
2015-01-25 15:24:58 avmike:netz_c: Phase 1 starting (renew)
2015-01-25 15:24:58 avmike:netz_c: Warning: source changed from xxx.yyy.zzz.ttt:500 to 127.0.0.1:500
2015-01-25 15:24:58 avmike:mainmode netz_c: selected lifetime: 3600 sec(no notify)
2015-01-25 15:24:58 avmike:netz_c: Error: id mismatch
2015-01-25 15:24:58 avmike:netz_c: mainmode.cpp:371: IKE-Error 0x1c
2015-01-25 15:24:58 avmike:netz_c: Phase 1 failed (responder): IKE-Error 0x1c
2015-01-25 15:24:58 avmike:netz_c: Warning: source changed from xxx.yyy.zzz.ttt:500 to 127.0.0.1:500
2015-01-25 15:24:58 avmike:netz_c: Phase 1 failed (initiator): IKE-Error 0x1c
2015-01-25 15:24:58 avmike:wolke_neighbour_renew_sa 0 SAs
2015-01-25 15:24:58 avmike:wolke_neighbour_renew_sa 0 SAs RENEW
...

Die IPv4 xxx.yyy.zzz.ttt ist jedoch weder meine, noch die non-public von Netz C ?!?!

 

[PeterPawn]

@geohei:
Offenbar hast Du ja meinen Vorschlag nicht verstanden oder willst ihn nicht umsetzen. Ich will es jetzt nicht nachstellen, leite aber aus der Tatsache, daß da einmal Phase1 als Responder (Zeile 6) und einmal als Initiator (Zeile 8) fehlschlägt (es ist ja auch höchst unwahrscheinlich, daß die Gegenstelle tatsächlich unter 127.0.0.1:500 erreichbar ist) ab, daß die Box, aus der dieser Log-Auszug stammt (leider muß man das auch irgendwie erraten), einerseits aus der Ferne angesprochen wird (das ist vermutlich die IPv4-Adresse des CGN-Gateways, was da von Dir als xxx.yyy.zzz.ttt beschrieben wird - ich tippe mal, die richtige Adresse ist irgendwas mit 987.876.765.654 oder so?) und andererseits immer noch selbst versucht, eine Verbindung aufzubauen.

Ich bin hier aber auch spätestens dann raus, wenn Du Dich nicht entschließen kannst, die jeweils verwendete VPN-Konfiguration der beiden VPN-Endpunkte und die dazu gehörigen Logs zu veröffentlichen (beim Maskieren bitte etwas mehr überlegen ... es macht schon Sinn, wenn man wenigstens noch ein Format erkennen kann), praktischerweise dann auch gleich noch die Dateien /var/tmp/ddnslog_n.txt und - wenn da nicht alle Einträge auf "complete" stehen - auch die Datei /var/tmp/ddnsstat.txt. Wenn die Box praktischerweise vor den entsprechenden Tests neu gestartet wird, hält sich auch der Umfang und die Anzahl der DynDNS-Logdateien in Grenzen und auch die ike.log wird nicht unmäßig groß, damit wird die Arbeit beim Maskieren geringer.

Ich sage es auch lieber vorher ... jede ike.log-Datei, die nicht spätestens beim "< add" für die Verbindung beginnt und erst nach dem Fehler endet, ist für mich unvollständig und wird ignoriert. Das ist nicht böse gemeint, aber ich habe auch einfach keine Lust mehr, immer nur zu raten und mir einen Wolf zu schreiben. Es hat garantiert nichts mit reiner Neugierde zu tun und dient i.d.R. auch nicht nur dazu, den Fragesteller irgendwie zu beschäftigen ... aber wenn ich mich erst rechtfertigen muß, warum ich irgendwas wissen will, spare ich mir einfach diese Nachfragen und ignoriere das Thema. Damit sage ich nicht, daß ich mich hier schon rechtfertigen mußte, aber die Angabe der sehr sparsamen und stark maskierten Protokoll-Datei und der Ankündigung "Die Konfiguration gibt es dann, wenn ich die Erklärung nicht verstehe." läßt mich aus unguten Erfahrungen auf wiederholt notwendige Roundtrips schließen und darauf habe ich einfach keinen Bock ... dafür gibt es schon genug andere Threads zum Thema "VPN mit CGN".

 

[geohei]

Um es kurz zu machen ... ich hab's !!!

Erst durch deinen "Wolf schreiben" kam ich auf Initiator/Responder, ike.log, ... was mir alles den Anstoss gab weiter zu wühlen! Es war also keineswegs umsonst! Dank Dir!

Zu Deinen Postings ...

Google Search CGN ist für Dich nicht das Gleiche wie für mich. Nix mit zweiter Hit ist es ...
Das Log war das meiner FB, also Netz A.
Die IP aus dem Log ... keine Ahnung. Passt zu rein gar nichts!
Ich hätte die Logs & Configs gepostet. Wäre kein Problem gewesen (mit maskieren usw.).

Was war es denn jetzt?

1. "remotehostname" versteht IPv4 (zwischen ""), also nicht nur FQDN. IPv6 geht allerdings nicht.

2. Bei Netz A habe ich "remotehostname" für Netz C entfernt. Das war eingentlich der ausschlaggebende Hinweis von Dir! Es wurde versucht eine Verbindung zu einer IPv4 zu machen die nicht existiert hat. Wenn eine IPv6 eingetragen war hat die nicht funktioniert. Das hat die ganze Verbindung lahm gelegt. Auf Netz C -> A Verbindungsaufbauversuche konnten das nicht wett machen.

3. Mir fiel auf, dass ich dann (wenn Netz A kein "remotehostname" hatte) meiner zwischen Netz A und C nur eine Verbindung bekam, wenn ich die Verbindung von C nach A (beispielsweise mittels ping) aufbaute. "always_renew = yes;" in Netz C hat das jetzt erübrigt!

So ... jetzt läuft's!

Vielen Dank nochmal!

Ich frage mich trotzdem jetzt, auf welchem Layer die Tunnel Kommunikation stattfindet; IPv4 oder IPv6? Ich könnte die IPv6 Negociation bei der Einwahl jetzt testweise auf Netz A abschalten um auch das noch zu überprüfen. Ich werde mir das für später aufheben

 

[PeterPawn]

"always_renew = yes;" in Netz C hat das erledigt!

Eine Möglichkeit - obwohl vermutlich dafür gedacht, das Rekeying einer abgelaufenen SA auch ohne aktuell zu übertragende Daten auszuführen -, aber "keepalive_ip" auf eine Adresse im LAN von "Netz A" zu setzen, ist eventuell die bessere. Das hängt allerdings etwas von den konkreten Umständen ab (z.B. beim Mobilfunk-Verbindungen kann es zu einem unerwartet hohen Volumen-"Verbrauch" führen) und sorgt gleichzeitig mit einem regelmäßigen "Ping" auch noch dafür, daß die Verbindung auf dem Provider-CGN (zur Suche komme ich gleich noch) garantiert aktiv bleibt. Ansonsten läuft das VPN mit hoher Wahrscheinlichkeit ja über UDP 4500 und da gibt es ja keine "echten Verbindungen", daher braucht es i.d.R. diese Keepalive-Pakete. Allerdings beherrscht die FRITZ!Box auch die IPSec-Option "Dead Peer Detection", bei der auf der Ebene von Phase1 die bloße Erreichbarkeit des IKE-Daemons der Gegenseite geprüft wird. In welchem Abstand das erfolgt, weiß ich nicht, bei keepalive_ip wird jedenfalls alle 4 Sekunden ein längeres (warum eigentlich, AVM ?) Ping-Paket gesendet.

Zur Suche:
Ich verwende FF35 in der englischen Version mit den folgenden Spracheinstellungen (sonst liefern zuviele Webseiten lokalisierte ausländische Inhalte, weil sie immer noch der Meinung sind, daß in D kein Englisch gewünscht sein darf):
Anhang anzeigen 80200
Damit erhalte ich dann mit dem lmgtfy-Link und mit der Suche über Google direkt (man kann selbstverständlich auch jede andere Suchmaschine verwenden, ich kenne nur keine, die ein lmgtfy-Äquivalent hat) folgende Ergebnisse:
Anhang anzeigen 80201
Wenn Du abweichende Ergebnisse erhältst (auch bei Verwendung des deutschen lmgtfy-Links) tut mir das zwar leid, ändert aber vermutlich (ich kenne ja die Ausgabe nicht) nur etwas an der Position des ersten passenden Artikels in der Ergebnisliste.
Ich wäre auch nicht auf die Frage gekommen, da Du ja selbst schon etwas von "Gateway des Providers" geschrieben hattest. Ich habe halt nur den richtigen Ausdruck für diese Technologie am DS-Lite-Anschluß verwendet und wollte Dich gar nicht verwirren.

Vielen Dank nochmal!

Keine Ursache ... schön, wenn es jetzt klappt.

Die Frage nach dem für den Tunnel verwendeten IP-Protokoll (4 oder 41) kannst Du ganz leicht mit einem Packet-Dump auf der "1. Internet-Schnittstelle" beantworten und brauchst dafür keine Experimente mit der Konfiguration machen. Auch die Ansage in der ike.log "source changed from ... to ..." sollte schon anhand der Adresse das verwendete Protokoll offenbaren, denn eigentlich müßte da irgendwann mal von 500 auf 4500 umgeschaltet werden, damit das CGN-Gateway beim NAT-T berücksichtigt werden kann.

 

[geohei]

"keepalive_ip" ist doch nur für Client-LAN VPN Verbindungen, oder? Wenn ja, dann ist es irreführend dass du es in diesem Zusammenhang erwähnst.

IPSec-Option "Dead Peer Detection" - ist dies für auch für LAN-LAN VPN Verbindungen? Gibt es eigentlich noch Optionen in der AVM VPN .cfg, die "versteckt" sind und nicht von der "FRITZ!Fernzugang einrichten" Software generiert werden?

Das mit "always_renew = yes;" verhällt sich leider auch nicht so wie erwartet. Wozu dient es eigentlich? Zum Erneuern des SA Zertifikates ("... das Rekeying einer abgelaufenen SA auch ohne aktuell zu übertragende Daten auszuführen ...")?

Was es bei mir für meinen Anwendungebereich macht ...

"always_renew = yes;" - Wenn ich den Router von Netz B oder C reboote, dann wird sofort eine Verbindung zu Netz A hergestellt.

"always_renew = no;" - Wenn ich den Router von Netz B oder C reboote, dann wird keine Verbindung zu Netz A hergestellt. Ich muss aus einem Gerät von Netz B bzw. C heraus ein Ping auf ein Gerät aus Netz A machen, dann erst wird die Verbindung hergestellt.

Wenn ich aber jetzt ein Reboot auf dem Router von Netz A mache werden alls 2 Verbindungen (zu Netz B und C) unterbrochen und nicht wieder aufgebaut. Erst ein Verbindungsaufbau aus Netz B oder C (entweder durch Router reboot oder ping aus dem entsprechenden Netz) stellt die Verbindung wieder her. Wie kann ich die Netz B/C VPN Konfiguration so ändern, dass die Verbindung erhalten bleibt (wenn das denn überhaupt geht). Ich möchte eine crontab ping Lösung von einem Gerät aus dem LAN Netz B/C erst einmal nicht in Erwägung ziehen, sondern es zuerst einmal mit der VPN Konfiguration versuchen.

 

[PeterPawn]

"keepalive_ip" ist doch nur für Client-LAN VPN Verbindungen, oder? Wenn ja, dann ist es irreführend dass du es in diesem Zusammenhang erwähnst.

Ich weiß ja nicht, woher Du dieses Wissen beziehst (Quellenangabe wäre nett), aber wenn ich Dich damit verwirre, dann tut es mir nicht einmal leid. Ich überlege mir i.d.R. schon vor dem Schreiben sehr genau, was ich eigentlich sagen will und das keepalive_ip paßt auch im Kontext einer LAN-LAN-Kopplung.

Wenn Du es einfach ausprobierst (ich habe schon geschrieben, was es bewirkt, warum sollte ich das erneut erläutern ... es ändert sich auch beim zweiten Mal nicht), hast Du die gesuchte Lösung auch ohne ein Ping von einem Gerät in Netz B oder Netz C und solange das dabei zusätzlich anfallende Volumen nicht stört, ist es eine einfache Lösung, die auch - neben den erwähnten Vorteilen bei NAT-Connections - noch einen umgehenden Aufbau einer IPSec-Verbindung bewirkt. Wenn Du es besser weißt oder es nicht probieren möchtest, laß es einfach sein.

Auch zu der - angenommenen - Bedeutung von always_renew habe ich schon etwas geschrieben. Solange ich keine neuen Erkenntnisse dazu habe, macht es nur wenig Sinn, auch das noch einmal zu wiederholen.

Wenn Du einfach einmal meine Erläuterung zu always_renew nimmst und auf das von Dir im letzten Absatz geschilderte Szenario anwendest, dann weißt Du auch, warum da keine Verbindung aufgebaut wird. Kleiner Tipp: Netz B und Netz C stellen keine Verbindung her, da sie aus ihrer Sicht noch gültige SA haben. Netz A stellt keine Verbindung her, weil die Box nicht weiß, wie sie Netz B und Netz C erreichen soll, wenn da kein remotehostname angegeben ist. Die SA bei den anderen Boxen würden erst ablaufen bzw. gelöscht werden, wenn Netz A tatsächlich von einer anderen IP-Adresse Kontakt mit ihnen aufnehmen würde (aufgrund eines gesetzten "initial contact"-Flags) oder wenn diese Boxen ihrerseits eine Möglichkeit haben, den "Tod" von Box A festzustellen. Ob tatsächlich DPD zum Einsatz kommt, kann ich von hier aus auch nicht sehen, die Protokolldateien sollten darüber Auskunft geben können. Allerdings weiß ich auch nicht, in welchen Intervallen die FRITZ!Boxen DPD machen, ich würde - nur anhand von Beobachtungen bei einigen meiner VPN-Verbindungen i.V.m. mit Restarts des Remote-Endpoints - auf deutlich mehr als 5 Minuten tippen. Ansonsten hilft auch da ein Packetdump bei der Klärung, wenn man es ganz genau wissen will.