FRITZ!Fernzugang einrichten: VPN-Konfiguration, wenn eine Gegenstelle DS-Lite hat

[LarsIP]

Hallo,

ich bin mit den VPN-Konfigurationsmöglichkeiten von AVM soweit ganz gut vertraut und habe auch schon einige Kniffe realisiert, z.B. geänderte Accesslists. Ich hatte bislang allerdings ausschließlich mit IPv4-Internetzugängen zu tun und habe nun eine Frage zu diesem Supportdokument von AVM:
Sind VPN-Verbindungen zu einer FRITZ!Box am DS-Lite-Internetzugang möglich?

Soweit ja verstanden... Mein Plan ist jetzt: Eine Gegenstelle mit FB 7490 nutzt DS-Lite (gezwungenermaßen), die andere ganz normal IPv4. Was ich nun nicht ganz verstanden habe:

1. Ist es überhaupt a) möglich, b) notwendig und c) sinnvoll, dass sich die Fritzbox mit DS-Lite beim MyFritz-Dienst anmeldet/einloggt? Oder fehlt in der Box gar der MyFritz-Menupunkt, wenn sie weiß, dass sie nur DS-Lite hat? Sie hat ja selbst gar keine IPv4-Adresse, die sie an den MyFritz-Dienst weitermelden könnte...

2. Falls das MyFritz-Konto bei der DS-Lite-Box entfallen kann oder soll, welchen Domainnamen trägt man dann ganz grundsätzlich in die VPN-Konfiguration (in "FRITZ!Fernzugang einrichten") für die DS-Lite Box ein, irgendeinen Dummynamen?

Mir ist schon klar, dass der Tunnel nur von der DS-Lite-Box zur anderen aufgebaut werden kann und nicht in der Gegenrichtung. Sobald der Tunnel steht, kann natürlich in beide Richtungen kommuniziert werden.

 

[PeterPawn]

Die IDs in P1 sind Schall und Rauch und sollten nur vom Aufbau her einem FQDN entsprechen (es gab mal Fälle, wo es mit der Domain ".local" nicht funktioniert haben soll) und natürlich "über Kreuz" aufs I-Tüpfelchen übereinstimmen.

Entscheidend für das Auffinden des Peers ist die Angabe bei "remotehostname" oder "remoteip".

Der GUI-Editor kann die ID und "remotehostname" nicht voneinander trennen, wie weit das Windows-Tool das kann, weiß ich nicht. Aber ein Texteditor kann das garantiert.

Ein MyFRITZ!-Konto kann auch IPv6-Adressen verwalten (bei DS-Lite hätte der Host zumindest eine solche) und daher ist der Punkt auch bei DS-Lite vorhanden.

Benötigt wird er aber nicht, denn auf 1. muß man antworten:

a) ja
b) nein, nicht für ausgehende VPN-Verbindungen
c) kommt ganz drauf an, für ausgehende VPN-Verbindung aber: nein

 

[LarsIP]

Danke Dir schon mal für die tolle ausführliche Erklärung!

Die IDs in P1 sind Schall und Rauch und sollten nur vom Aufbau her einem FQDN entsprechen

Okay, dann muss eben bei remoteid und localid über Kreuz ein sinnvoller FQDN drinstehen. Zur Sicherheit sollten vermutlich, wenn mehrere unterschiedliche Verbindungen konfiguriert sind, auch nicht mehrere unterschiedliche Remote-Peers den exakt gleichen FQDN verwenden, trotz Schall und Rauch in Phase 1.

Entscheidend für das Auffinden des Peers ist die Angabe bei "remotehostname" oder "remoteip".

Üblicherweise hat man remoteip = 0.0.0.0; - zumindest setzt das Windows-Tool das so. Den remotehostname setzt es identisch zur remoteid. Interessant fände ich zu wissen, ob man zusätzlich zu remoteip = 0.0.0.0; auch gleichzeitig noch remotehostname = ""; setzen kann, weil es halt keinen gültigen gibt. Aber dadurch wäre die ganze Konfig vielleicht ungültig und die Box weigert sich sie zu importieren oder sie fliegt einem um die Ohren, hängt in einer Schleife fest, wenn sie nicht weiß wie sie die (DS-Lite-)Gegenstelle versuchen kann zu erreichen oder so.

Ein MyFRITZ!-Konto kann auch IPv6-Adressen verwalten (bei DS-Lite hätte der Host zumindest eine solche) und daher ist der Punkt auch bei DS-Lite vorhanden.

Mir geht es um Unitymedia - aus irgendwelchen Gründen dachte ich bislang, die IPv6-Adressen der DS-Lite-Kunden wären nur dazu da, um IPv4-Pakete in IPv6-Pakete kapseln zu können, und ansonsten gar nicht von anderswo aus dem Internet (z.B. von Telekom Dual Stack-DSL-Anschlüssen) aus erreichbar. Das aber nur als Notiz am Rande.

 

[PeterPawn]

Danke Dir schon mal für die tolle ausführliche Erklärung!

Da das eher Telegramm-Stil war (für meine Verhältnisse), bin ich mir etwas unsicher, wie das zu verstehen ist ... ich nehme es mal wörtlich.

Zur Sicherheit sollten vermutlich, wenn mehrere unterschiedliche Verbindungen konfiguriert sind, auch nicht mehrere unterschiedliche Remote-Peers den exakt gleichen FQDN verwenden, trotz Schall und Rauch in Phase 1.

Natürlich sollten die unterschiedlich sein ... es sind eben "Identifikationen" (einmal die eigene und einmal der "Anfragende") für den "responder" und der muß mit diesen Angaben in erster Linie einen Eintrag finden, bei dem "remoteid" dem eingehenden Paket entspricht - das dürfte bei mehreren Einträgen zumindest dann schwer werden, wenn man den zweiten mit identischen IDs verwenden (und erreichen) will.

Dann wird bei AVM (vermutlich) noch getestet, ob auch die angegebene lokale ID (also die eigene, wobei es auch da um die Angabe im VPN-Eintrag geht und nicht um irgendetwas anderes auf der Box) auch noch zu diesem VPN-Eintrag paßt. Erst dann wird der dort enthaltene PSK herangezogen.

Es gibt außer diesen beiden IDs keine Identifikation für P1 und die Authentifizierung wird ausschließlich daraus abgeleitet, daß der PSK auf beiden Seiten derselbe ist. Deshalb ist es auch so wichtig, daß beim "aggressive mode" ein vernünftiges Kennwort verwendet wird ... das ist die einzige Sicherung in der Phase des Verbindungsaufbaus.

Die Box hängt mit einer ungültigen VPN-Konfiguration (solange es nicht um die "accesslist" geht) auch nicht irgendwo, dann geht halt der betreffende Tunnel nicht. Meine Interpretation von "remoteip" und "remotehostname" ist die, daß bei Vorhandensein einer gültigen "remoteip" (Templates gibt es in anderen Threads auch zur Genüge) die Box diese direkt benutzt. Ansonsten wird "remotehostname" verwendet und die aus dessen Auflösung resultierende IP-Adresse. Diese Auflösung findet - nebenbei bemerkt - auch in regelmäßigen Abständen erneut statt und wenn sich die zurückgelieferte IP-Adresse ändert (was z.B. bei einem VPN-Service der Fall sein kann, der seine Einwahlknoten über DNS-Round-Robin rotiert), dann wird die Verbindung neu aufgebaut zu dieser Adresse.

Für nicht in der Konfiguration enthaltene Angaben gibt es bei einigen Werten ohnehin Standards, welche die Box beim Import automatisch setzt - m.W. gehört da sowohl ein leerer "remotehostname" als auch eine "remoteip" von "0.0.0.0" dazu. Aber das kriegst Du ganz leicht selbst heraus, indem Du einfach nach dem Import einer VPN-Konfiguration in der resultierenden Sicherungsdatei nachsiehst. Zwar werden drei Einträge verschlüsselt (localid, remoteid, key - bei conntype_user vier andere), aber der Rest ist nach wie vor Klartext und kann in der vpn.cfg nachgelesen werden.

Die IPv6-Adressen der DS-Lite-Anschlüsse sind (m.W.) ganz normale "öffentliche Adressen" und können von jedem anderen IPv6-fähigen Anschluß aus erreicht werden. Allerdings transportiert das AVM-VPN nicht selbst über IPv6, daher keine eingehenden VPN-Verbindungen am DS-Lite-Anschluß (zumindest nicht ohne PCP und welcher Provider in D unterstützt das bisher?) - hier wäre vermutlich ohnehin L2TP/IPSec bei IPv6 die sinnvollere Lösung ... ist m.W. alles Zukunftsmusik (wie vieles beim VPN, u.a. auch die Möglichkeit, solche "asymmetrischen Konfigurationen" mit dem GUI einzurichten).

 

[LarsIP]

Da das eher Telegramm-Stil war (für meine Verhältnisse), bin ich mir etwas unsicher, wie das zu verstehen ist ...

Insofern ausführlich, dass Du direkt auf die unterschiedlichen wichtigen Punkte in der Textdatei eingegangen bist ohne drum herum zu reden

Die Box hängt mit einer ungültigen VPN-Konfiguration (solange es nicht um die "accesslist" geht) auch nicht irgendwo, dann geht halt der betreffende Tunnel nicht. Meine Interpretation von "remoteip" und "remotehostname" ist die, daß bei Vorhandensein einer gültigen "remoteip" (Templates gibt es in anderen Threads auch zur Genüge) die Box diese direkt benutzt. Ansonsten wird "remotehostname" verwendet und die aus dessen Auflösung resultierende IP-Adresse.

Ich konnte bislang noch keine "asymmetrische Konfiguration" richtig testen, bin deshalb nach wie vor etwas ratlos, ob man denn nun besser dran ist, wenn man einen leeren "remotehostname" verwendet statt einer unerreichbaren Dummy-Domain hinsichtlich Stabilität des Tunnels und Menge und Aussagekraft von Fehlermeldungen im Fritz-Protokoll. Ich kann erst in ein paar Wochen meine Erfahrungen dazu hier posten.

Diese Auflösung findet - nebenbei bemerkt - auch in regelmäßigen Abständen erneut statt und wenn sich die zurückgelieferte IP-Adresse ändert (was z.B. bei einem VPN-Service der Fall sein kann, der seine Einwahlknoten über DNS-Round-Robin rotiert), dann wird die Verbindung neu aufgebaut zu dieser Adresse.

Von beiden Seiten (Peers) - egal wer von beiden den Tunnel ursprünglich aufgebaut hat, richtig? Da hat man ja Glück, wenn/dass der Tunnel nicht zusammenkracht, weil die Auflösung dann etwa die Antwort liefert: dummydomain.example.com wurde von google-public-dns-a.google.com nicht gefunden: Non-existent domain.

kann in der vpn.cfg nachgelesen werden

Hierfür reicht ja dann das Abspeichern der Fritzbox-Konfiguration über das Webinterface und öffnen der Datei z.B. mit Notepad++ aus (man braucht keinen Telnetzugang, ar7.cfg oder ähnliches).

EDIT: Typos beseitigt.

 

[PeterPawn]

Ich verstehe überhaupt nicht, wie Du auf die Idee mit irgendeiner "Dummy-Domain" für "remotehostname" bei der Box mit der öffentlichen IPv4-Adresse kommst ... der bleibt einfach leer und das ist dann auch das einzige, was diese Box davon abhält, ihrerseits den Aufbau eines Tunnels zu versuchen (was ja scheitern muß). So ein Verbindungsversuch macht eben keinen Sinn (er kommt ja ohnehin nicht an) und beim dann fälligen Fehler wird auch eine von der anderen Seite bereits aufgebaute Verbindung wieder abgebaut ... zumindest war es bisher immer so.

Warum also so "geheimnisvoll" und vor allem kompliziert gedacht? Wenn Du es im Moment gar nicht testen kannst, macht es doch auch keinen Sinn, immer neue "wenn ... dann"-Szenarien durchzukauen. Wenn Du Dich schlau machen willst, dann lies einfach die anderen Threads zu diesem Thema, die es hier bereits gibt ... dort sollten dann auch (fast) alle Deine Fragen schon beantwortet sein.

 

[LarsIP]

Ich verstehe überhaupt nicht, wie Du auf die Idee mit irgendeiner "Dummy-Domain" für "remotehostname" bei der Box mit der öffentlichen IPv4-Adresse kommst ... der bleibt einfach leer (...)

Ich erstelle VPN-Konfigurationsdateien bislang mit dem Windows-Tool (wie vermutlich die meisten User). Das Tool trägt unter "remotehostname" immer den FQDN der Gegenstelle ein und ich habe diesen Eintrag unter "remotehostname" bei der Box mit der öffentlichen IPv4-Adresse als (unerreichbare) "Dummy-Domain" bezeichnet. Ich hab nur damit gehadert, ob ich die Datei anpassen oder es so lassen soll wie es das Tool ausspuckt. Danke für die klare Anweisung ihn rauszuschmeißen mit remotehostname = ""; Schade, dass AVM diesen Tipp nicht auf den Hilfeseiten einbaut, wenn schon das Tool diesen asymmetrischen Fall nicht abbilden kann.

 

[Micha0815]

Ich erstelle VPN-Konfigurationsdateien bislang mit dem Windows-Tool (wie vermutlich die meisten User).

Hatte ich als Anfänger auch zuerst genutzt, neben der neuerdings auch in der GUI implementierten Funktion.

Das Tool trägt unter "remotehostname" immer den FQDN der Gegenstelle ein und ich habe diesen Eintrag unter "remotehostname" bei der Box mit der öffentlichen IPv4-Adresse als (unerreichbare) "Dummy-Domain" bezeichnet.

Ich glaube da verwechselst Du die beiden cfg`s? Imho muss die FB -diejenige, die eine öffentliche IP hat und via DYNDNS oder Myfritz über dies erreichbar ist eben keinen Hostname haben.

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "beispiel";
                boxuser_id = 0;
                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 = "";
                keepalive_ip = 0.0.0.0;
                localid {
                        fqdn =

Sie ist nur Empfänger bzw. Responder

Während Du bei der FB ohne öffentliche IPv4 eben diesen remotehostname und keepalive_ip = -interne IP der FB mit öffentlicher IPv4- eintragen musst. Sie ist Initiator bzw. "Tunnelaufbauer"

Hier hat PeterPawn über die Schlüssellänge Überlegungen angestellt.
http://www.ip-phone-forum.de/showthread.php?t=282261&p=2129020&viewfull=1#post2129020
Das Tool nimmt wie berichtet nur kürzere keys an?
http://www.ip-phone-forum.de/showthread.php?t=282261&p=2129068&viewfull=1#post2129068

An anderer Stelle aufmerksam geworden, hatte ich heute mal das fbtools ... decrypted getestet und meine Schlüssel im Cleartext erkannt. (bei/aus einer älteren inaktiven LAN2LAN.cfg)

Da ich mit dem zufällig generieren etwas unbedarft, habe ich mir aus einer anderen export-datei einen schon sehr langen Teil in die configs kopiert, da sie bei import dann ja erneut verschlüsselt werden.

Good Luck und LG

- - - Aktualisiert - - -

Da das eher Telegramm-Stil war (für meine Verhältnisse), ...

OT und ein Novum für mich, dass das möglich? An anderer Stelle, holt man sich ne Watschen ab, falls man nach dem Motto "In der Kürze liegt die Würze" hinterfragt?

LG und ich bin eh stets, statt mit Axt, nur mit einem Spielzeug-Gummi-Tomahawk im Wald unterwegs mit geringer Verletzungsgefahr.

 

[LarsIP]

Ich glaube da verwechselst Du die beiden cfg`s?

Ich hab nur etwas knapp "bei der Box mit der öffentlichen IPv4-Adresse" geschrieben - gemeint ist natürlich die (vom Tool "FRITZ!Fernzugang einrichten" erstellte) Konfigdatei der Box, die Empfänger bzw. Responder ist. Bei dieser muss der remotehostname-Eintrag rausgelöscht werden mit remotehostname = "";

Während Du bei der FB ohne öffentliche IPv4 eben diesen remotehostname und keepalive_ip = -interne IP der FB mit öffentlicher IPv4- eintragen musst.

Musst? "remotehostname" kann ich stehenlassen, steht ja schon da :ziggi: Und die "keepalive_ip" ist, wenn ich Post #2 im von Dir verlinkten Thread richtig verstanden habe, nicht unbedingt notwendig, da keine Antwort auf das erste Paket benötigt wird. Die "keepalive_ip" steht ja ansonsten im Standardfall (beide Peers haben IPv4 bzw. einen Hostname, der erreichbar ist) auch nicht in der Konfig und warum soll ich mir jetzt speziell die Mühe machen die "keepalive_ip" bei den "asymmetrischen Verbindungen" einzutragen?

Das Tool nimmt wie berichtet nur kürzere keys an?

Das Tool "FRITZ!Fernzugang einrichten" erlaubt keine Eingabe von Schlüsseln, sondern generiert diese automatisch, wenn man die Verbindung erstellt. Ich habe mal verschiedene (ältere) VPN-Konfigs angeschaut - die Länge des Keys scheint zu variieren zwischen 30 und 37 Zeichen.

 

[PeterPawn]

@LarsIP:
Eine "keepalive_ip" mußt Du bei der Initiator-Box tatsächlich eintragen (das sollte eine Adresse sein, die über den Tunnel erreichbar ist im entfernten LAN, wobei der Host nicht zwangsweise existieren muß) ... wenn da ein solcher Eintrag fehlt, baut die DS-Lite-Box den Tunnel erst dann auf, wenn es ein Paket für das LAN am Ort der Box mit der öffentlichen IPv4-Adresse zu übertragen gilt. Da die andere Box gar keine Möglichkeit hat, von sich aus einen Verbindungswunsch zu signalisieren, wäre man dann vollkommen "in der Hand" der Gegenstelle - eher keine so richtig gute Entscheidung. Daher läßt man den Tunnel eben permanent aufbauen und genau dazu dient diese "keepalive_ip".

 

[LarsIP]

Oh ja, stimmt :gruebel: Als "keepalive_ip" würde sich ja die interne IP der Fritzbox auf der Gegenstelle anbieten. Andererseits, wenn man in Anbetracht der Knappheit der IPv4-Adressen dort womöglich eine größere Anzahl VPN-Verbindungen (=mehr als acht) konfiguriert hat, wäre vielleicht abzuwägen, ob man wirklich alle Tunnel permanent aufgebaut lassen will. Mit anderen Worten meine Frage: Was zählt denn überhaupt, die Anzahl konfigurierter Verbindungen oder die Anzahl parallel aufgebauter Verbindungen? Ressourcen sind ja nicht endlos