VPN zwischen FB6490 und FB7xxx geht nicht

[omodebach]

Man muss mit der Windows-Software eine entsprechende Konfigurationsdatei erzeugen und in dieser dann die Proposals für die IPsec Phase 2 anpassen.

Bezieht sich die Aussage auf die hohe CPU Auslastung oder die grundsätzliche Möglichkeit zur LAN-to-LAN Kopplung zweier Fritzboxen. Mit phase2ss = "esp-all-all/ah-none/comp-all/pfs" bekomme ich ja eine grundsätzliche Verbindung.

Ja, das bezieht sich auf die IKE Fehler 0x2027, 0x202d und welche da (zumindest bei mir) fröhlich in den Logs auftauchen, wenn man die Proposals nicht manuell anpasst. Mit "esp-all-all/ah-none/comp-all/pfs" fliegen mir die IKE-Fehler nur so um die Ohren :kratz:

Auf die CPU-Last dürfte das weniger Auswirkungen haben, da die Verschlüsselung ja auch weiterhin nicht in Hardware, sondern softwareseitig in der CPU stattfindet,

Gruß,
Oliver

 

[Andreas1969]

Ja, das bezieht sich auf die IKE Fehler 0x2027, 0x202d und welche da (zumindest bei mir) fröhlich in den Logs auftauchen, wenn man die Proposals nicht manuell anpasst. Mit "esp-all-all/ah-none/comp-all/pfs" fliegen mir die IKE-Fehler nur so um die Ohren

Das war ja auch genau mein Problem.
Es war so schlimm, dass erst garkeine Nutzdaten durch den Tunnel flossen. Der Tunnel ist direkt nach dem Aufbau wieder in sich zusammengebrochen.

Ich Hab's bisher mit Deinem Vorschlag noch nicht getestet, das macht mit jetzt Mut, dass es vielleicht doch funktionieren könnte.

Mal schauen, am WE werde ich mich der Sache nochmal annehmen.

Gruß Andreas

 

[johnripper]

Man muss mit der Windows-Software eine entsprechende Konfigurationsdatei erzeugen und in dieser dann die Proposals für die IPsec Phase 2 anpassen.

Bezieht sich die Aussage auf die hohe CPU Auslastung oder die grundsätzliche Möglichkeit zur LAN-to-LAN Kopplung zweier Fritzboxen. Mit phase2ss = "esp-all-all/ah-none/comp-all/pfs" bekomme ich ja eine grundsätzliche Verbindung.

Ja, das bezieht sich auf die IKE Fehler 0x2027, 0x202d und welche da (zumindest bei mir) fröhlich in den Logs auftauchen, wenn man die Proposals nicht manuell anpasst. Mit "esp-all-all/ah-none/comp-all/pfs" fliegen mir die IKE-Fehler nur so um die Ohren :kratz:

Auf die CPU-Last dürfte das weniger Auswirkungen haben, da die Verschlüsselung ja auch weiterhin nicht in Hardware, sondern softwareseitig in der CPU stattfindet,

Gruß,
Oliver

Danke für die Antwort. Ich habe zwischenzeitlich deine und meine Proposal Varianten in Phase 2 versucht und in beiden Fällen nicht einen unbegründeten IKE o.ä. Fehler gesehen.

Lediglich das Lastproblem habe ich noch, aber das wird sich wahrscheinlich nicht so schnell lösen sein. Ich muss hierzu nochmal recherchieren, ob es "vorteilhafte" und "nachteilhafte" Einstellungen gibt.

 

[Andreas1969]

Meinst Du dann würde eventuell auch die Verbindung zwischen einer IPV4 und einer DSLITE Box laufen?

Da standardmäßig NAT Traversal aktiviert wird, würde ich davon ausgehen. Versuch macht kluch :zwinker:

Gruß,
Oliver

Hallo Oliver,

der Versuch ist leider in die Hose gegangen.
Die VPN Verbindung ist nicht zum Laufen zu bekommen.

Mit Deinem Vorschlag treten weiterhin folgende Fehler auf:

DSLITE BOX
VPN-Fehler: xyz.myfritz.net, IKE-Error 0x2027

IPV4 BOX
VPN-Verbindung zu zyx.myfritz.net wurde getrennt. Ursache: 3 IKE Server

Also keine Veränderung.

Wie schon gesagt, ich habe die Sache eh aufgegeben und fahre momentan mit einer anderen Lösung.
Eventuell bügelt AVM den FW-Bug ja im nächsten FW Update aus. :kafffee:

Die Hoffnung stirbt zuletzt.

Gruß Andreas

 

[johnripper]

Jo, also im Ergebnis das selbe wie hier: http://www.unitymediaforum.de/viewtopic.php?f=90&t=27239&start=40#p349642.

Da es exakt das gleiche Fehlerbild ist (DS-Lite Box meldet IKE-Error 0x2027, IPv4 Box meldet Ursache: 3 IKE Server) scheint die 6to4-Gateways von UM irgendwas (unerwartetes) zu machen. Sonderlich ist mE nur, dass die DS-Lite Box den Timeout (IKE-Error 0x2027) meldet, nicht andersrum :kratz:

 

[Andreas1969]

Jo, also im Ergebnis das selbe wie hier: http://www.unitymediaforum.de/viewtopic.php?f=90&t=27239&start=40#p349642.

Da es exakt das gleiche Fehlerbild ist (DS-Lite Box meldet IKE-Error 0x2027, IPv4 Box meldet Ursache: 3 IKE Server) scheint die 6to4-Gateways von UM irgendwas (unerwartetes) zu machen. Sonderlich ist mE nur, dass die DS-Lite Box den Timeout (IKE-Error 0x2027) meldet, nicht andersrum :kratz:

Ja, da schiebt Einer den schwarzen Peter auf den Anderen :wand:

AVM behauptet steif und fest, VPN zwischen DSLITE Box und IPV4 Box würde funktionieren, wenn´s
Probleme gibt. läge es an der komplexen Routing bei Unitymedia. :hirnbump:
Unitymedia behauptet, VPN zwischen DSLITEBOX und IPV4 Box würde nicht gehen, man bräuchte zwingend
einen Business-Anschluss. :wand:

Ich persönlich bin da aber ganz anderer Meinung. Es handelt sich um einen Bug in der FW der Boxen.
Und zwar interpretiert die Box die Tunnel MTU des 4 in 6 Tunnels falsch, bzw. ignoriert diese, sodass
der Datenstrom des VPN Tunnels fragmentiert wird und das AFTR da nicht ordentlich mitspielt.

Ich habe da mal die ganzen Fehlerprotokolle der Boxen auseinandergenommen und bin (für mich)
zu diesem Ergebnis gekommen.
Ich habe das auch der Entwicklung von AVM mitgeteilt, aber nie eine Antwort von denen bekommen. :zerstör:

Vieleicht haben die das ja mittlerweile schon behoben und in der FW 6.63 läuft das jetzt?

Wenn das eventuell mal jemand mit einer eigenen Box (FW 6.63) an einem DSLITE Anschluß testen könnte, eine Verbindung zu einer IPV4 Box aufzubauen. :super:

Eine andere Variante, das zu prüfen, wäre, wenn jemand noch eine IPV4 Box bei einem Provider am
Laufen hat, bei dem die MTU kleiner ist, als die Tunnel MTU des UM 4 in 6 Tunnels am DSLITE Anschluß.
Da müsste die VPN Verbindung meiner Meinung nach auch aufgebaut werden. :super:

Vielleicht hat ja jemand eine dieser beiden genannten Konstellationen und kann das mal
gegenchecken. :super:

Gruß Andreas

 

[omodebach]

Sehr bedauerlich. Meine Ausführungen bezogen sich ja ursprünglich auch nicht auf DS-Lite, ich hatte aber Hoffnung, dass das auch mit DS-Lite funktioniert. Bei M-Net geht's aber z.B. auch nicht, also ist dieses Thema wohl nicht UM-spezifisch. https://forum.m-net.de/viewtopic.php?f=20&t=9820&start=15&sid=b0b974e837091816605cc34708bac899

An die MTU-Theorie will ich nicht so recht glauben, mir sind bisher nie derartige Probleme begegnet. Aber ausgeschlossen ist natürlich nichts.

Ich spinne jetzt aber nochmal ein bisschen rum: Du bekommst jetzt unterschiedliche Fehler: "0x2027" auf DS-Lite Seite und "3 IKE Server" auf IPv4 Seite. 0x2027 ist ein klassischer Timeout, "3IKE Server" ist eine saubere Trennung der Verbindung. Das interpretiere ich jetzt mal so, dass beide Seiten versuchen, die Verbindung aufzubauen. Die IPv4 Seite bekommt natürlich keine Verbindung, gleichzeitig kommt aber eine gültige SA aus der anderen Richtung zu Stande. Die wird nun von der IPv4 Box verworfen, weil sie ihr "nicht in den Kram passt". Das ist der "3 IKE Server". Da die einkommende SA auf der IPv4 Box verworfen und nicht quittiert wird, läuft die DS-Lite Seite in den Timeout, daher dort der 0x2027.

Jetzt müsste man versuchen, die IPv4 Seite zum Responder only zu machen. Wie genau man das in den Config-Dateien macht, ist mir nicht klar. Ich würde mal versuchen, in der Datei, die für die Box mit IPv4 gedacht ist, den Eintrag remoteip = 0.0.0.0; zu setzen (ist er standardmäßig ohnehin) und auch remotehostname = ""; (hier also den Hostnamen rauslöschen). remoteid darf aber nicht angefasst werden, hier muss weiterhin der Hostname stehen. Damit weiß die Box nicht wohin und verhält sich ruhig, so meine Theorie.

Vielleicht klappt's ja. Ich kann das nicht testen, da ich kein DS-Lite irgendwo zur Verfügung habe.

Gruß,
Oliver

 

[johnripper]

Jetzt müsste man versuchen, die IPv4 Seite zum Responder only zu machen.

Wurde schon versucht.

Wie genau man das in den Config-Dateien macht, ist mir nicht klar.

Ich schon.

Ich würde mal versuchen, in der Datei, die für die Box mit IPv4 gedacht ist, den Eintrag remoteip = 0.0.0.0; zu setzen (ist er standardmäßig ohnehin) und auch remotehostname = ""; (hier also den Hostnamen rauslöschen). remoteid darf aber nicht angefasst werden, hier muss weiterhin der Hostname stehen. Damit weiß die Box nicht wohin und verhält sich ruhig, so meine Theorie.

Nein.

Siehe den von mir verlinkten Thread oben.

 

[Andreas1969]

Jetzt müsste man versuchen, die IPv4 Seite zum Responder only zu machen.

Das hatte ich damals als eine der ersten Aktionen schon versucht, bzw. in der Config angepasst.

Gruß Andreas

 

[Andreas1969]

Jetzt mal ein neuer Ansatz:

Das AFTR lässt anscheinend nur TCP Pakete mit einer max. MTU von 1420 unfragmetiert durch.
Das könnte auf einen Fehler in der Fritzbox hindeuten, wenn die VPN Verbindung mit einer MTU größer 1420 arbeitet.

Gruß Andreas

 

[Andreas1969]

Ich nehme dieses Thema nochmal auf.
Eventuell hat AVM den VPN Bug in den neueren FW Versionen behoben.
Ich hab jetzt mal ein Dreier Verbund eingerichtet:

Fritzbox 6360 FW 6.52 DSLITE
Fritzbox 6490 FW 6.50 IPV4
Fritzbox 7580 FW 6.88 IPV4

Der Tunnel zwischen 6490 und 7580 läuft stabil und fehlerfrei, war auch zu erwarten, da beide Boxen IPV4 haben.
Tunnel zwischen 6360 und 6490 baut überhaupt keine Verbindung auf (FW auf beiden Boxen veraltet)

Jetzt kommt das Interessante:
Tunnel zwischen 6360 und 7580 wird aufgebaut und auch als grün in der Fritzbox angezeigt.
Es fließt nur kein Traffic durch den Tunnel.
Vermutlich, weil eine Box noch die uralt FW drauf hat, aber zumindest wird der Tunnel schon mal aufgebaut, da eine Seite eine aktuelle FW drauf hat.

 

[Andreas1969]

Jetzt kommt das Interessante:
Tunnel zwischen 6360 und 7580 wird aufgebaut und auch als grün in der Fritzbox angezeigt.
Es fließt nur kein Traffic durch den Tunnel.
Vermutlich, weil eine Box noch die uralt FW drauf hat, aber zumindest wird der Tunnel schon mal aufgebaut, da eine Seite eine aktuelle FW drauf hat.

Kann das eventuell mal ein User hier mit einer 6590 am DSLITE Anschluss und aktuellem OS 6.8x testen?
Sprich VPN Verbindung zwischen 6590 DSLITE (OS 6.8x) und einer IPV4 Box (auch mit aktuellem OS 6.8x).

Wenn das jetzt funktioniert, würde ich nämlich die 6360 am DSLITE Anschluss gegen eine eigene 6590 ersetzen wollen. Ich scheue momentan noch die hohe Ausgabe für eine 6590, da mir das Risiko, dass es doch nicht funktioniert, einfach zu hoch ist.

AVM behauptet nämlich immer noch steif und fest, dass es ohne Probleme funktionieren würde.

 

[Andreas1969]

Der VPN Bug wurde seitens AVM im Fritz!OS 7.10 behoben. :super: