[Frage] VPN mit Fritz!Fernzugang einrichten

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
300
Punkte für Reaktionen
4
Punkte
18
Hallo liebes Forum,

ich wollte fragen, ob es irgendwo eine Dokumentation zu den VPN.CFGs gibt, welche Parameter ich setzen kann, welches Format sie haben müssen, was es für Optionen gibt?

Und ich wollte noch wissen, wenn ich eine komplette vpn.cfg in die Fritzbox importieren möchte, um z.B. bestehende Verbindungen zu ändern (zB. Name, Accesslist) ... muss ich dann immer erst manuell die Verbindungen entfernen und dann die komplette VPN.cfg neu importieren, oder werden die Einstellungen beim Import überschrieben?f

Oder gibt es eine einfachere "Ersetzen-Methode"??

LG
Wile C
 

Micha0815

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
3,891
Punkte für Reaktionen
213
Punkte
63
ich wollte fragen, ob es irgendwo eine Dokumentation zu den VPN.CFGs gibt, welche Parameter ich setzen kann, welches Format sie haben müssen, was es für Optionen gibt?
Eine vollumfängliche Dokumentation im Detail seitens AVM ist mir nicht bekannt, sofern Du auf den "Inhalt" einer VPN.cfg abzielst bzgl. Selbserstellung/Handshape. AVM beschränkt sich auf die Handhabung des eigenen VPN-Konfigurator-Programms und ein paar Standard-Fälle via GUI (sofern die FW/Modell es zulässt) ohne auf das Ergebnis (unter der Haube) nähers einzugehen, womit die meisten Enduser wohl zum Ziel kommen.
Und ich wollte noch wissen, wenn ich eine komplette vpn.cfg in die Fritzbox importieren möchte, um z.B. bestehende Verbindungen zu ändern (zB. Name, Accesslist) ... muss ich dann immer erst manuell die Verbindungen entfernen und dann die komplette VPN.cfg neu importieren, oder werden die Einstellungen beim Import überschrieben?
Falls die Verbindung denselben Namen trägt, wird die alte imho überschrieben/ersetzt, falls man die VPN.cfg als gültige Textdatei (Mit Linux-kompatiblen Editor erstellt) importiert.
Wenn Verbindungen ständig aufgebaut/gehalten werden sollen, sollte man Vorsicht walten lassen, wenn es sich um ein und dieselbe Gegenstelle handelt und man nur den Verbindungsnamen ändert. Z.T. -iirc- werden grottenfalsche *.cfg zwecks Import verweigert. Als Bsp. mochte -meiner Erinnerung nach- eine 7390 die Optionszeile editable=yes so garnicht importieren, auchwenn der Rest korrekt war.
Wenn es sich lediglich um ein paar wenige Änderungen in der accesslist und/oder permit/deny-Anweisungen handelt, kann der FB-Editor gute Dienste leisten. (Mit der aktuellen 7.19er-Laborreihe kommt er -noch?- nicht zurecht).
Sofern der Fernzugriff via öffentlicher IPv4 möglich ist, kann man etwas mutiger agieren, alswenn die Gegenstelle ohne pysischen Zugriff als Initiator in der Ferne an einem Mobilfunk- oder DS-Lite-Anschluss wergelt. Durch Fehler in der Syntax und/oder insbesonders rund um die accesslist kann man sich dabei schnell "aussperren", was u.a. viel Aufwand/Bittere Tränen bedeuten kann. Bevor man Änderungen vornimmt, sollte man sich stets eine funktionierende *.export erstellen, um ggfs. den korrekten VPN.cfg-Abschnitt parat zu haben.
LG and my2cent
P.S.: Da AVM z.Zt. in der 7.19er Laborreihe u.a. auch am VPN "schraubt", sollte man bzgl. älterer Quellen/Beispiel-Configs beim "Abkupfern" Vorsicht walten lassen und sich hier im Forum -oder vergleichbaren aktuellen Quellen- informieren.
 

Peter_Lehmann

Neuer User
Mitglied seit
13 Mrz 2007
Beiträge
151
Punkte für Reaktionen
22
Punkte
18
Falls die Verbindung denselben Namen trägt, wird die alte imho überschrieben/ersetzt, falls man die VPN.cfg als gültige Textdatei (Mit Linux-kompatiblen Editor erstellt) importiert.
Kleine Ergänzung von mir:
Ich habe gefühlte 10 Jahre auf bis zu 10 fremden F!B diverse VPN für Wartungszwecke, Datenaustausch usw. eingerichtet. Und ich habe dazu immer "händisch" eine Konfigurationsdatei erstellt und ganz normal auf die F!B hochgeladen. Und da ich immer noch gewisse Regeln meiner ehemaligen beruflichen Tätigkeit anwende, ist ein regelmäßiger Schlüsselwechsel für mich eine Selbstverständlichkeit.
Ich habe also immer wieder die identische config mit immer neuen Schlüsseln über die bisherige config "drübergebügelt". Nicht ein einziges mal führte das zu Problemen. Also, per VPN eingeloggt, config hochgeladen, die beiden neuen Schlüssel auf dem Rechner in den Networkmanager eingetragen, neu verbunden und fertig!

Jetzt das ABER:
Seit ich die erste BETA der 7.19er-Laborreihe nutze, bekomme ich das VPN (auf diese Art) nicht mehr zum Laufen. Es sieht so aus, als ob es nur noch funktioniert, wenn ich das VPN auf die von AVM gewollte Art, also Nutzer für VPN berechtigen usw. einrichte. Da ich jetzt konsequent auf Wireguard setze, will ich mich erst wieder mit dem "AVM-VPN" befassen, wenn die offizielle Version der Fw draußen ist.

Ich würde mich aber sehr freuen, wenn mir ein Nutzer der 7.19er-Laborreihe dieses Problem bestätigen oder ausschließen könnte.


MfG Peter
 

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
300
Punkte für Reaktionen
4
Punkte
18
Vielen Dank für Eure Antworten.

Mir ging es eigentlich mehr darum, zusätzliche Konfiguratioszeilen wie "keepalive_ip = 1.1.1.1" oder ähnliches in eine vpn.cfg aus dem Programm "Fritz!Fernzugang einrichten" einzufügen und was diese dann bewirken. Dachte, da gäbe es schon ein kleines "Kompendium" ;)
 

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
300
Punkte für Reaktionen
4
Punkte
18
Wie oft wird denn ein "Ping" oder dieses "keepalive_ip" von der Fritzbox angestoßen? Weiß das zufällig jemand?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,038
Punkte für Reaktionen
987
Punkte
113
Hast Du denn mal gesucht?

Wie wäre es mit dieser Fundstelle?


Ob die Zahlen noch stimmen (erst recht dann ab 07.20), mußt Du halt selbst mal überprüfen.
 

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
300
Punkte für Reaktionen
4
Punkte
18
Ich habe mal einen Mitschnitt gemacht. Wenn ich das richtig sehe, wird von der Box im ca. 20 Sekunden Takt der NAT-Keepalive gesendet, oder?

Und die Pakete sind nicht wirklich groß ...
 

Anhänge

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,038
Punkte für Reaktionen
987
Punkte
113
Wo siehst Du da die ICMP-Pakete aus dem Keepalive?

Mein Tipp, wenn Du das Mitschneiden möchtest (so habe ich es damals jedenfalls gemacht): Einfach eine IP im LAN (beim Peer) bei "keepalive_ip" angeben, dann kann man die Pakete wunderbar am "dev lan" (EDIT: natürlich dann auch am Peer) abgreifen. Was an den jeweiligen Interfaces des "kdsld" vorbeikommt und mitgeschnitten wird, ist teilweise auch Glückssache - aber beim Keepalive an eine LAN-Adresse MÜSSEN die Pakete den richtigen Weg nehmen (vom WAN-Interface zur CPU (zum IPSec-Decryptor, solange das nicht mit Hardware-Unterstützung läuft) und von da nach dem Entschlüsseln an die LAN-Bridge).
 

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
300
Punkte für Reaktionen
4
Punkte
18
Ist ja eine wireshark Datei. Da kommt im 20 Sekunden Takt ein NAT-Keepalive.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,038
Punkte für Reaktionen
987
Punkte
113
Ist eine pcap-Datei ... und Wireshark kann die dann lesen (neben vielen anderen Programmen).

Aber diese Pakete haben (afaik) nichts mit "keepalive_ip" zu tun ... oder siehst Du da irgendeine der Adressen, die bei Dir als "keepalive_ip" eingetragen sind, irgendwo im Paket oder besser im Header?

Im Payload dieser Pakete (1 Byte, ggf. "padded") ist nicht mal genug Platz für die IP-Adresse, an die ein ICMP-Paket gesendet werden soll, geschweige denn für den (verschlüsselten) Payload einer IPSec-Verbindung ... der schon in der Theorie ja aus mind. einem kompletten verschlüsselten Block bestehen müßte, dessen Länge zwar vom verwendeten Algorithmus abhängt, aber kleiner als 16 Byte (aka 128 Bit) heute bei keinem aktuellen Algorithmus mehr zu finden wäre.

Das, was Du da siehst, sind die "keepalive packets" für eine NAT-T-Verbindung beim IPSec (NAT Traversal) ... die sorgen (alleine schon mit ihren IP-Headern, deshalb haben die auch keinen Payload) dafür, daß irgendwelche Connection-Trackings in den NAT-Routern auf dem Weg am Leben bleiben.

Die ICMP-Pakete, die aus der Angabe einer "keepalive_ip" resultieren, sind "normaler Payload" für die IPSec-Verbindung - da kommen dann entweder ESP-Pakete (bei "direkter Sicht", also ohne NAT-T) oder UDP-Pakete auf Port 4500 ... aber dann auch mit entsprechende Länge, weil sie das ICMP-Paket in verschlüsselter Form transportieren müssen.

Das, was da in Deinem Paketmitschnitt zu sehen ist, ist jedenfalls kein ICMP-Keepalive, wie das bisher (vor 07.19/07.20) von AVM genutzt wurde. Ob/wie sich das bei der 07.20 geändert hat, muß ich erst noch ermitteln - es gibt derzeit aber deutlich Wichtigeres.
 

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
300
Punkte für Reaktionen
4
Punkte
18
Also hier ist mal ein Mitschnitt des LAN von einer FritzBox, welche den keepalive_ip auf eine entfernte Fritzbox hat... Entweder ist da nix drin, oder ich sehe es nicht...
 

Anhänge

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,038
Punkte für Reaktionen
987
Punkte
113
Mein Vorschlag lautete ja auch genau anders herum - Du solltest nicht an der Quelle, sondern am Ziel den Mitschnitt machen. Die Quelle ist die FRITZ!Box selbst, wieso sollte da ein Paket für das entfernte LAN (also beim Peer) auf dem eigenen LAN-Interface auftauchen?
 

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
300
Punkte für Reaktionen
4
Punkte
18
Achso, ich dachte, weil ja die "eigene" FritzBox ja den keepalive_ip sendet. Ich dachte, der taucht dann da auch auf?! Dann probiere ich das Ganze nochmal am LAN-Interface der "empfangenden" Box.
 

Zurzeit aktive Besucher

3CX

Statistik des Forums

Themen
235,317
Beiträge
2,059,182
Mitglieder
355,920
Neuestes Mitglied
flowstream