[Problem] FRITZ!OS6: VPN manuell per cfg einrichten

Sebastian-46

Neuer User
Mitglied seit
24 Sep 2010
Beiträge
73
Punkte für Reaktionen
0
Punkte
6
Hallo,
ist es unter FRITZ!OS 6 noch möglich die VPN Verbindung manuell über die cfg zu konfigurieren? Wollte gerade ein wenig rum testen, allerdings fürchte ich, dass zu Konflikten in die GUI implementierte VPN Konfiguration über den VPN Haken bei den Fritzbox Usern gibt.

Der neue User sieht in der cfg (zunächst mit dem Fritz!Box Fernzugang einrichten Tool erstellt) zunächst so aus:
Code:
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "sebastian";
                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 = 192.168.177.201;
                remoteid {
                        key_id = "sebastian";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "asdf";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "sebastian";
                        passwd = "sebastian";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.177.201;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip 192.168.177.0 255.255.255.0 192.168.177.201 255.255.255.255", 
                             "permit ip any 192.168.177.201 255.255.255.255";
        }
(Es ist bereits eine Verbindung zu einer anderen Fritzbox konfiguriert (funktioniert weiterhin), daher nur der Ausschnitt der den User betrifft. Auch wird natürlich ein sichereres Passwort und PSK eingesetzt.)

Wenn ich versuche wie gewohnt bspw. mit dem iPhone eine Verbindung über den Mobilfunk versuche aufzubauen, kommt nach längerer Wartezeit "Authentifizierung fehlgeschlagen". Löschen des Fritzbox Users "sebastian" nützt nichts. Oder muss die Fritzbox neugestartet werden nach dem löschen von Usern oder importieren von VPN cfgs?

Edit: Neustart hat geholfen. Trotzdem wäre es Interessant zu wissen ob sich die GUI Konfiguration mit eigenen cfgs beißt bzw. diese sich gegenseitig überschreiben können oder es anders zu Konflikten kommen kann. Vielleicht hat das schon jemand hinreichend intensiv getestet um da eine Aussage treffen zu können.
Wenn ich es richtig sehe, muss man, bevor man einen User manuell per das hochladen einer neuen cfg Datei ändert, ihn aus der VPN Verbindungsliste unter Internet->Freigaben->VPN im GUI löschen und danach erst die geänderte cfg hochladen.

Edit2: Habe den PSK nun etwas länger gestaltet. Dazu den betreffenden User aus der VPN-Verbindungsliste gelöscht, die cfg mit dem geänderten PSK importiert und den neuen PSK am iPhone eingetragen. Nun erhalte ich die Meldung "Der VPN-Schlüssel (Shared-Secret) ist nicht korrekt.". Auch ein Neustart der Fritzbox bringt nichts. Ist die Länge des PSK limitiert? 22 Zeichen (Buchstaben und Zahlen) funktionierten. 27 Zeichen nichtmehr.

Edit3: PSK darf nicht länger als 23 Zeichen sein, kann das sein? Darüber antwortet der VPN-Server entweder nicht oder meldet falschen PSK. Im übrigen habe ich den Fritzbox User "sebastian" gelöscht gelassen und ich kann trotzdem per VPN mit diesem User verbinden zusammen mit der obigen cfg.
 
Zuletzt bearbeitet:
Die VPN-Verbindungen werden anhand von "name=" identifiziert. Verwendet man denselben Namen, können sich auch Client2LAN- und LAN2LAN-Verbindungen gegenseitig überschreiben bzw. genauer gesagt "mischen", was zu sehr interessanten Effekten führt, wenn die Box selbst eine Verbindung für einen Benutzer konfiguriert hat (conntype_user) und man anschließend per Datei eine "conntype_lan"-Verbindung unter diesem Namen importiert - dabei bleiben dann z.B. die ursprünglichen xauth-Einstellungen erhalten - es ist also kein reines Ersetzen der einen durch die andere. Das wird vermutlich nicht "als Text" realisiert, sondern anhand eines passenden Objektes, das nach und nach die Eigenschaften zugewiesen bekommt und am Ende wieder "serialisiert" wird - schließlich wird ja auch die gesamte VPN-Datei mit allen Verbindungen neu geschrieben, da ereilt dieses Schicksal der "Serialisierung" sicherlich jede einzelne Verbindung bei jeder Konfigurationsänderung aufs Neue.

Das macht es auch für mich etwas unverständlich (also die Annahme, daß bei solchen Änderungen immer ein Abbild der gesamten Konfiguration in der Box existieren sollte, an dem die Änderungen dann vollzogen werden), daß dort so wenige zusätzliche Prüfungen (die nicht immer zur "Verweigerung" führen sollten/müssen, aber wenigstens zu passenden Warnungen) stattfinden, um "Interferenzen" zwischen solchen Verbindungen auszuschließen. Ich bin im Moment nicht einmal sicher, ob die Box nicht auch die Aktivierung zweier VPN-Verbindungen zu unterschiedlichen Gegenstellen mit identischen LAN-Segmenten ermöglichen würde, zumindest dann, wenn die Box selbst nur als Responder arbeitet (sonst würde die Verbindung zum zweiten Peer naturgemäß kaum aufgebaut). Die Konflikte treten dann ja erst auf, wenn P2 schon fast beendet ist, da die Box selbst keine Änderung ihrer IP-Konfiguration vornimmt, egal welche (conntype_lan-)Verbindung aktiv ist. Die bloße Existenz zweier solcher Verbindungen stört die Box jedenfalls schon mal definitiv nicht, ob bei der Aktivierung einer SA dann schon ein Problem auftritt, würde ich auch bezweifeln, denn m.W. können auch zwei SAs für dieselbe Verbindung parallel bestehen und da unterscheiden sich dann SAs für zwei verschiedene Verbindungen nur bei der (öffentlichen) Adresse des Peers (und natürlich beim aktiven SPI).

Die "Verwaltung" der zugeordneten IP-Adressen zu Host2LAN-Verbindungen (das sind ja Client2LAN-Verbindungen im Endeffekt) würde ich auch eher so machen, daß nach der IP-Range des DHCP-Servers (da fängt FRITZ!OS mit der Vergabe dieser Adressen an) noch genug Platz freigelassen wird, damit es dort keine Konflikte zwischen selbst verwalteten Adressen und den vom FRITZ!OS verwalteten IP-Adressen für diese Verbindungen gibt.

Insgesamt sollte man die Möglichkeiten und die Fähigkeiten des eingebauten Editors nicht überschätzen, das geht bei der Erkennung von doppelten Belegungen bei entfernten Netzsegmenten los und endet bei der Konfiguration eines "passiven Responders" (der also seinerseits nicht aktiv eine Verbindung aufbaut, weil sich die Gegenstelle z.B. hinter einem CGN befindet) noch lange nicht.

Was dieser Editor den meisten abnehmen kann, ist die parallele Konfiguration der Einstellungen in der ar7.cfg für "ipsecbrX"-Interfaces, also die Reservierung einzelner Ports für bestimmte VPN-Verbindungen. Da dieses parallel zu Änderungen an der VPN-Konfiguration (was mit Import einzelner Verbindungen ja noch ganz gut klappt - früher ging das ja auch nur "en bloc" und selbst die spätere "Notwendigkeit", die Box neu zu starten oder zumindest den dsld neu zu starten und damit die Internet-Verbindung der Box zumindest kurzzeitig zu unterbrechen (mit allen Konsequenzen wie z.B. neuer dynamischer Adresse, die dann erst wieder ein DynDNS-Update braucht, usw.), sind ja inzwischen glücklicherweise Geschichte, insofern hat AVM sich da durchaus Mühe gegeben) auch noch Änderungen an der ar7.cfg verlangt, für die es gar keine "offizielle" Möglichkeit gibt, schlägt er in diesem Punkt sogar die Konfiguration von Hand (wenn auch die meisten die Einschränkung, daß die ar7.cfg-Änderungen erst nach einem Neustart wirksam werden, offenbar nicht einmal lesen, geschweige denn verstehen, können).

Ob inzwischen auch andere potentielle Schwachstellen überwunden sind (z.B. die Anpassung von VPN-Verbindungen (conntype_user) mit ihren "remote_virtualip"-Werten, wenn sich die LAN-Konfiguration der Box ändert), müßte man glatt mal wieder testen, nachdem nun die 06.50 als Release-Version erschienen ist. Auch die Frage, ob sich das xauth-Kennwort automatisch ändert, wenn man das Benutzerkennwort für das FRITZ!Box-Login erneuert, ist ja nicht ganz uninteressant. Diese beiden (ursprünglich identischen) Kennwörter werden ja tatsächlich an zwei verschiedenen Stellen in der FRITZ!Box-Konfiguration abgelegt und wer seinerseits z.B. VPN-Einstellungen aus einer älteren Konfiguration selektiv wiederherstellen läßt (cfgtakeover), während der Benutzer in der Box vielleicht noch denselben Namen, aber ein neues Kennwort hat, der "importiert" sich in diesem Falle schnell mal ein Problem, was ohne Kenntnis der Zusammenhänge schwer zu finden ist. Schon die Frage, ob eine Änderung des Benutzerkennworts auch eine Änderung des VPN-Kennworts für xauth nach sich zieht, ist nicht unspannend.

Allerdings geht sicherlich die Frage, wie weit so ein "GUI-Editor" an dieser Stelle "Eigeninitiative" entwickeln sollte, schon wieder ans Eingemachte ... der eine verläßt sich auf automatische Anpassungen, der andere verflucht solche "Automatismen", weil sie ihm die mühsam von Hand zusammengestellte Konfiguration durcheinander bringen.

Unter diesem Aspekt kannst Du auch problemlos Deine Frage zum PSK abhaken ... eine Beschränkung (zumindest bei LAN2LAN) wäre mir nicht geläufig (da nehme ich problemlos mind. 32 Zeichen "random", am Ende wird ohnehin ein Hash über den Wert gebildet). Allerdings kann das ja auch durchaus eine Einschränkung des Clients sein ... die FRITZ!Box hat (meine Erfahrung, aber auch nicht mit conntype_user-Verbindungen) solch ein Limit wohl eher nicht. Denkbar wäre zwar auch, daß ein Fehler sich bei einer Verbindung zwischen zwei FRITZ!Boxen "wegkürzt" (indem eben beide nur die ersten 22 Zeichen hashen), aber dann würde eine Verbindung von der FRITZ!Box zu einem Linux-Server auch eher nicht funktionieren (außer racoon als IKE-Daemon auf dem Linux-Server hätte dasselbe Problem), wenn da längere PSK verwendet werden. Ich habe gerade mal nachgezählt (eigentlich zählen lassen mit "wc -c") ... meine PSKs auf dem Linux-Server haben 64 Zeichen (65 inkl. LF beim "Zählen") für jede FRITZ!Box.

Beim Import von VPN-Verbindungen wird der avmike (das ist der Daemon für's "key exchange", der die SAs für die Verbindungen verwaltet) beendet und neu gestartet, deshalb unterbricht die Änderung der Konfiguration einer Verbindung (auch das Löschen einer solchen) auch immer andere aktive Verbindungen. Das reine (De-)Aktivieren über die Checkbox (oder über entsprechende ctlmgr-"Befehle") macht das seit einiger Zeit dankenswerterweise auch nicht mehr. Ab wann jetzt ein Neustart des ctlmgr und/oder des dsld und/oder der gesamten Box notwendig wird, hängt u.a. von den ausgeführten Änderungen ab. Ich bin mir nicht einmal 100% sicher (bei der neuen Version), ob das Löschen des Benutzers auch tatsächlich eine für diesen Benutzer eingerichtete VPN-Verbindung entfernen würde - bei früheren Verbindungen blieb die bestehen. Heute könnte sie tatsächlich mit gelöscht werden, wenn dabei die Einstellung "vpn_access=yes" beim Benutzer nicht nur dazu verwendet werden sollte, im Benutzer-Manager des GUI die Checkbox bei "VPN" zu steuern. Da parallel zum "name"-Wert der VPN-Verbindung auch noch eine Eigenschaft "boxuser_id" gesetzt wird in der vpn.cfg, könnte man das wohl auch tatsächlich sauber auseinanderhalten, welche Konfiguration von der Box für einen Benutzer eingerichtet wurde und welche nachträglich editiert wurde. Aber das oben erwähnte "Mischen" beim Import einer gleichnamigen Verbindung läßt mich da eher zweifeln ... auch wird natürlich das "boxuser_id" beim Import wieder überschrieben. Ob tatsächlich bei einer "conntype_lan"-Verbindung schon aus Prinzip mit "0" oder nur deshalb, weil es in meinem Versuch mit "0" angegeben war, weiß ich nicht einmal ... spielt aber auch nicht wirklich eine Rolle - genauso wenig wie die Frage, ob denn die Box beim (teilweisen) Import einer VPN-Verbindung für einen gar nicht in der Box existierenden Benutzer - oder auch für einen Benutzer mit identischem Namen aber abweichender Benutzer-ID - die korrekten Anpassungen vornimmt (vermutlich differieren schon die Ansichten, was da "korrekte Anpassungen" wären).

Mein persönliches Fazit zum GUI-Editor in der Box selbst: Nette Spielerei, die beim "normalen Benutzer" sicherlich die meisten Aspekte der VPN-Konfiguration abdecken kann. Sowie es etwas komplizierter wird (und VPN-Konfigurationen können beliebig kompliziert sein, je nach Anwendungsfall), greift man lieber zur Konfiguration "von Hand" und hofft inständig, daß der GUI-Editor beim "Import" einer bestehenden Verbindung nicht in die Versuchung gerät, zuviel "Eigenintelligenz" zu entwickeln ... sonst landet man wieder beim direkten Austausch der kompletten ar7.cfg (für Benutzer und ipsecbr-Interfaces) und der vpn.cfg auf der Box, damit der einem nicht "dazwischenfummelt". Daß allerdings nicht einmal die Konfiguration einer VPN-Verbindung zwischen einer Box mit öffentlicher IP und einer Box ohne eine solche (wir reden hier ohnehin nur über IPv4, IPv6 als Transportverbindung beherrscht die FRITZ!Box m.W. ohnehin nicht) damit machbar ist (weil es eine 1:1-Beziehung zwischen "remotehostname" und der ID für P1 gibt) und auch bei einem (parallel) aktivierten MyFRITZ!-Account mit einem zusätzlichen DynDNS-Account bei einem anderen Provider die Konfiguration bei den meisten Benutzern scheitern wird (wieder wegen der erwähnten 1:1-Umsetzung), ist schon ein Schwachpunkt in diesem Editor, den AVM m.E. auch noch ausmerzen sollte, damit verringert sich die Zahl der Kunden, die "von Hand" konfigurieren müssen, noch einmal.
 
Danke schonmal für den Beitrag. Ich glaube den muss ich noch ein paar Mal durchlesen um ihn tatsächlich auch zu verinnerlichen. :D
Zum Thema Länge des PSK habe ich mit dem iPhone experimentell die Grenze von 23 Zeichen ermittelt. Bei mehr Zeichen wird ein falscher PSK moniert. Mir scheint als werden die Konfigurationen für jene VPN Accounts überschrieben für die es in einer importierten cfg andere/neue Informationen gibt. Accounts die in der importierten cfg nicht behandelt werden, bleiben offensichtlich bestehen. Hab ich aber nicht hinreichend getestet. Zur Sicherheit hab ich die betreffenden Accounts vor dem Import manuell gelöscht im GUI.

Kann jemand kurz erklären ob und wie man es anstellen kann, dass man für Clients den Zugriff auf ausgewählte einzelne IPs beschränkt? Bin da bisher auf einige Threads gestoßen wo das im Endeffekt im Sand verlaufen ist. Habe heute vielfach mit verschiedenen accesslist Variationen rum probiert aber am Ende war entweder nichts oder weiterhin alles erreichbar.
 
Der Import von VPN-Verbindungen ist schon länger für jede Verbindung einzeln möglich ... solltest Du also noch eine Variante des Programms "FRITZ!Fernzugang konfigurieren" verwenden, was immer eine große einzelne Datei mit allen dort verwalteten Verbindungen erzeugt, ist das unnötiger Aufwand (keine Ahnung, ob es ein "FRITZ!Fernzugang konfigurieren" für einzelne Verbindungen überhaupt gibt bzw. ob das Programm die Verbindungen für die Box auch einzeln ausspucken kann.

Insofern stimmt es ausdrücklich, daß Verbindungen, die in einer Import-Datei nicht enthalten sind, auch nicht geändert werden ... wie auch. Die Zeiten der "monolithischen vpn.cfg-Datei" sind lange vorbei - m.E. schon seitdem der GUI-Editor überhaupt existiert. Ob es seitdem ein neues Konfigurationsprogramm von AVM gab, würde ich zumindest bezweifeln ... das soll nicht den Eindruck erwecken, ich wüßte es.

Ansonsten ist das Anliegen beim Beschränken des Zugriffs eines Clients (was für eines) auf ausgewählte einzelne IP-Adressen (ein- oder ausschließen, interne oder externe Adressen) viel zu unbestimmt, als daß es eine konkrete Antwort geben könnte.

Die "accesslist" in einer VPN-Konfiguration selektiert nur den Verkehr, der auf der FRITZ!Box in den VPN-Tunnel zur Gegenstelle "umgeleitet" wird, das ist keine Firewall und damit wird kein Verkehr aus dem Tunnel zur FRITZ!Box und darüber hinaus reguliert.

Wenn Du also an die Stelle des "trial & error" einen Plan (auf der Basis systematischer Überlegungen) setzt, was da von der Box an den Client gesendet werden soll, klappt das auch mit der "accesslist" ... das Senden von beliebigen Paketen vom Client an Adressen im LAN oder sogar im WAN wirst Du auf diesem Weg ohnehin nicht verhindern - nur die Antworten auf solche Pakete kannst Du beeinflussen.

Gibt es im LAN z.B. einen Host, der für einen "ping of death" anfällig ist, kannst Du einem VPN-Client bei der FRITZ!Box das Senden eines solchen Paketes nicht verbieten (jedenfalls nicht auf einem dokumentierten Weg und wie weit die "dpconfig"-Einstellungen auf Pakete auf "dev dsl" vor dem Punkt wirken, an dem IPSec "ausgeleitet" wird, müßte man auch erst erneut versuchen).

Reagiert ein LAN-Teilnehmer auf WoL-Pakete in "IP-Form" (also jenseits von Ethernet-Frames und kriegt die Box dann auch noch die Adressierung eines solchen IP-Paketes an die richtige MAC-Adresse hin, weil das betreffende Gerät einen ARP-Eintrag bei ihr hat), kann so ein VPN-Client auch jederzeit den betroffenen LAN-Client "wecken" ... eben weil auch da wieder keine "Zwei-Wege-Verbindung" erforderlich ist.

EDIT: Das Thema PSK-Länge müßte man halt für valide Ergebnisse noch mit einem anderen Client untersuchen, solange nicht klar ist, ob die Beschränkung auf der FRITZ!Box (dann aber auf conntype_user beschränkt, denn conntype_lan verkraftet eben definitiv längere PSKs) oder auf dem iPhone auftritt.
 
Zuletzt bearbeitet:
Hallo,
also kann man mit der Fritzbox alleine nicht wirklich effektiv den Zugriff eines VPN Clients auf nur eine oder ausgewählte IPs begrenzen?
 
Hallo PeterPawn und ander VPN-Interessierte,
da im Web-IF nur das Ändern von ausgewählten vpn.cfg Parametern möglich ist, nicht jedoch Spezialsettings, die für Betrieb von L2L-VPN via UMTS erforderlich sind; deshalb habe ich mich gefragt, ob es neben der "Import vpn.cfg" Methode auch andere Möglichkeiten der VPN-Anpassung gibt, vorzugsweise würde ich gerne LUA CLI-Befehle in Verbindung mit modfs oder modfs-SIAB einsetzen.

Beispiel: Anzeigen aller VPN-Configs
Code:
# echo -e "VPN=vpn:settings/connection/list(activated,name,deletable,editable,state,remote_ip,src,dst,connected_since,settings)"  | ./queries.lua
VPN_1_index="connection0"
VPN_1_activated="1"
VPN_1_name="myfqdn.dyndns.org"
VPN_1_deletable="1"
VPN_1_editable="1"
VPN_1_state="in progress"
VPN_1_remote_ip="255.255.255.255"
VPN_1_src=""
VPN_1_dst=""
VPN_1_connected_since="0"
VPN_1_settings=""
VPN_count=1
#


Setzen eines VPN-Config-Parameters
Code:
# echo -e "vpn:settings/connection0/name=myfqdn_2.dyndns.org"  | ./set.lua
OK
#

Wie kann ich so eine Config-Änderung aktivieren (vpn-reload, vpn-restart) ?

Wie kann ich weitere VPN-Einstellungen wie keepalive_ip, ... auslesen ?

Ziel: alle VPN-Parameter analog zu vpn.cfg per LUA auslesen, sowie ggf. auch anpassen.

LG Riverhopper

EDIT: Text im erstem Abschnitt angepasst.
 
Zuletzt bearbeitet:
Hallo Sebastian-46!

Zum Thema Länge des PSK habe ich mit dem iPhone experimentell die Grenze von 23 Zeichen ermittelt. Bei mehr Zeichen wird ein falscher PSK moniert.
Ich habe herausgefunden, daß das Paßwort für VPNs aus Sicht der Fritz!Box aus maximal 63 Zeichen bestehen kann und zwar aus den Zeichen: A ... Z und a ... z, sowie den Ziffern: 0 ... 9 und letztlich Sonderzeichen, außer dem Anführungszeichen: ". AVM hat mir das an der Telefonhotline bestätigt und will diese Info in ihr Online-Hilfen einbauen.

Ich will aber nicht ausschließen, daß das Paßwort bedingt durch das Smartphone kleiner sein muß.

Glück auf!

Rorohiko
 
Ich habe herausgefunden, daß das Paßwort für VPNs aus Sicht der Fritz!Box aus maximal 63 Zeichen bestehen kann und zwar aus den Zeichen: A ... Z und a ... z, sowie den Ziffern: 0 ... 9 und letztlich Sonderzeichen, außer dem Anführungszeichen: ". AVM hat mir das an der Telefonhotline bestätigt und will diese Info in ihr Online-Hilfen einbauen.
Für den in der vpn.cfg gespeicherten PSK ist das definitiv falsch, egal was die AVM-Hotline dazu sagt.

Es mag sein, daß es tatsächlich im GUI irgendwo eine Limitierung auf diese 63 Zeichen gibt - wenn das nicht nur von der AVM-Hotline falsch verstanden wurde, weil man da beim WLAN-PSK nachgesehen hat und da sieht der Standard dieses Limit tatsächlich vor.

Hier geht es aber offensichtlich um die direkte Eingabe des PSK in der vpn.cfg, denn auf einem anderen Weg kann Sebastian-46 die PSK-Länge für einen Benutzer ja nicht ändern. Dabei ist es vom Prinzip egal, ob diese Änderung extern erfolgt und dann importiert wird oder ob direkt in der Datei geändert wird.

Ich habe jedenfalls (ohne die AVM-Hotline dazu zu befragen) einfach mal den bisher schon verwendeten 64 Zeichen langen PSK (wie ich schon weiter oben geschrieben habe) einer FRITZ!Box auf 72 Zeichen erweitert (natürlich auf beiden Seiten) und die Verbindung aufbauen lassen. Die Gegenseite war dabei ein Linux-Server mit racoon, es kann also auch nicht sein, daß irgendwelche Zeichen am Ende bei der FRITZ!Box einfach ignoriert werden, denn sowie ich das letzte Zeichen dieses PSK ändere, kommt keine Verbindung mehr zustande. Nun ist so eine nicht zustandekommende Verbindung ja nicht immer ein sicheres Zeichen (das könnte ja auch andere Ursachen haben), aber sowie ich diese Änderung auf Seiten der FRITZ!Box ebenfalls noch vornehme, klappt auch die Verbindung wieder.

Fazit: Für den PSK-Eintrag in der vpn.cfg gilt dieses 63 Zeichen-Limit definitiv nicht (die Testumgebung war dieselbe wie häufig, 113.06.50) - wollen wir mal hoffen, daß AVM etwas anderes meinte oder zumindest vor dem Ändern irgendwelcher Beschreibungen noch mal jemand konsultiert wird, der sich damit dann tatsächlich auskennt. Wer es immer noch nicht glauben will, sollte es mit den vorstehenden Informationen (auch eine passende racoon-Konfiguration hatte ich letztens irgendjemandem zusammenkorrigiert) problemlos selbst testen können. Auch dem Mitarbeiter an der AVM-Hotline müßte man diesen Test dann wohl nahelegen.

Und nur nebenbei ... bei direkter Eingabe in der vpn.cfg stimmt nicht einmal die Feststellung mit der Ausnahme bei der "quotation mark" (0x22, HTML ") - gibt man die mit der korrekten Schreibweise mit vorangestelltem Escape-Zeichen (ein "backslash") in dem Wert an (damit das nicht mit dem Ende verwechselt werden kann), funktioniert sogar das einwandfrei (wieder gegen racoon getestet). Nur beim Import bringt das FRITZ!OS die Sonderzeichen in einer extern editierten VPN-Konfiguration ohnehin gerne mal durcheinander, daher sollte man solche Experimente dann immer direkt mit dem Editor an der vpn.cfg-Datei durchführen.

PS: Damit da kein Mißverständnis aufkommt, der tatsächlich verwendete Schlüssel wird ohnehin per Hash-Funktion unter Einbeziehung der angegebenen Zeichenkette gebildet (RFC 2409, Punkt 5.4). Auch ein 20 Zeichen langer PSK führt also zu einem Hash-Wert der entsprechenden Länge - viel hilft hier also nur insofern viel, als daß in der Theorie keine zweite Zeichenkette existieren sollte, die denselben Hashwert liefert (das leidige Problem der Hash-Kollisionen) und je länger so ein Key ist, um so schwerer ist er durch "brute force attacks" (man kann das auch "systematisches Probieren" nennen) zu ermitteln.

EDIT: Ne, also nicht einmal im GUI-Editor existiert bei der 113.06.50 irgendeine Beschränkung auf diese 63 Zeichen ... wenn ich da 72 Zeichen eingebe (Ziffern 0-9, Buchstaben A-Z, a-z und nochmal alle Ziffern von 0-9), landen die auch 1:1 so in der vpn.cfg - da wüßte ich schon gerne, wo diese Beschränkung beim VPN zu finden sein soll. Eventuell hat das ja auch jemand mit dem Kennwort für XAUTH verwechselt (das ist normalerweise dasselbe, wie das für den Benutzeraccount in der Box) ... das teste ich jetzt nicht mehr, das verwende ich bei der FRITZ!Box nicht selbst.
 
Zuletzt bearbeitet:
Ziel: alle VPN-Parameter analog zu vpn.cfg per LUA auslesen, sowie ggf. auch anpassen.
Nicht auf diesem Weg ... die werden auch von AVM nicht "einzeln" konfiguriert, da sitzt irgendein Adapter zwischen dem ctlmgr und dem Schreiben in die vpn.cfg - die Abhängigkeiten (z.B. remotehostname und remoteid für P1) sind wohl "hard-wired" ... sonst hätte ich da längst einen Patch für das GUI gebastelt. Aber nicht einmal die Einstellung, welche P1-ID das lokale System nehmen soll, wenn es mehrere gibt (MyFRITZ! + DynDNS), ist da zu finden und von außen irgendwie zu steuern.

Das AVM-GUI verwendet auch bloß folgende Eigenschaften einer VPN-Verbindung, die Du genauso wie die anderen abfragen kannst:
Code:
access_net
access_mask
access_hostname
access_username
access_psk
access_type
dns_domains
xauth_username
xauth_password
keepalive (auch nur 0 oder 1, keine Adresse, wohin das gehen soll)
ipsecbr_enabled
ipsecbr_interfaces
ipsecbr_prefix
ipsecbr_netmask
ipsecbr_first_dns
ipsecbr_second_dns
Bleibt also nur das (entschlüsselte) Auslesen aus der vpn.cfg, Editieren (notfalls kann man sich ja einen Parser dafür basteln) und anschließend das Zurückschreiben über eine definierte Schnittstelle, damit der ctlmgr das auch mitkriegt.

Dafür kommt am ehesten der auf CGI getrimmte Aufruf von firmwarecfg infrage ... andererseits kann man auch die vpn.cfg neu schreiben und mit "msgsend ctlmgr vpncfg_changed" wohl tatsächlich eine Art "reload" ausführen. Das eigentliche "reload" (msgsend dsld vpnreload) wird dabei vom ctlmgr gleich mitgemacht ... auf diesem Weg kann man auch VPN komplett totlegen (msgsend dsld vpndisable) oder wieder starten (vpnenable).
 
@PeterPawn:
Vielen Dank für die Inputs zu LUA und CLI-Befehle zur Administration von vpn.cfg und VPN-Sessions;
ich werde dies am WE austesten

LG Riverhopper
 
Hallo,
FRITZ!Box 7490 FRITZ!OS 7.01.

Ich verwende bisher den ShrewSoft VPN Client oder Android und gebe dort die unter System > FRITZ!Box Benutzer > Bearbeiten > VPN-Einstellungen anzeigen angezeigten Daten ein.

Nun wollte ich zusätzlich FRITZ!Fernzugang verwenden weil es mittlerweile auch für Windows 10 64-Bit verwendbar ist.

Leider bietet AVM nicht an dass man die Daten von Hand eingibt.

Daher frage ich mich ob man das Shared Secret (IPSec Xauth PSK) in eine wie in #1 genannten Konfiguration verwenden kann.
Eventuell muss es zunächst (in Hash, MD5, SHA1, SHA256, Base64 o.ä.) umgewandelt werden?

Dazu habe ich folgende Seite gefunden: https://www.computersalat.de/linux/vpn/ipsec-vpn-zwischen-fritzbox-und-linux/

...
Parameter für phase1ss
def/3des/sha Zugriff auf WatchGuard Firebox
alt/aes/sha Zugriff auf AVM Access Server
def/all/all alle Algorithmen, DH-Gruppe default
alt/all/all alle Algorithmen, DH-Gruppe alternativ
def/all-no-aes/all alle Algorithmen ohne AES, DH-Gruppe default
alt/all-no-aes/all alle Algorithmen ohne AES, DH-Gruppe alternativ
alt/aes-3des/sha AES 256 Bit oder 3DES, DH-Gruppe alternativ
all/all/all alle Algorithmen, DH-Gruppe alternativ
...

Danke
 
Zuletzt bearbeitet:
Eventuell muss es zunächst (in Hash, MD5, SHA1, SHA256, Base64 o.ä.) umgewandelt werden?
Das Programm -zumindest die ältere Version- erstellt die jeweilige *.cfg mit Klartext-Inhalten. Beim Import werden die Credentials verschlüsselt. Möchte man diese aus einer *.export oder Support-Datei wieder sichtbar/lesbar machen, empfiehlt sich ein Blick auf "PeterPawns Decode-Tools" und/oder "M.Engelke-Fritz!Box-Tools", wo die Algorithmen genauer erläutert werden.
LG
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
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.