[Frage] VPN mit Fritz!Fernzugang einrichten

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
395
Punkte für Reaktionen
13
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
 
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.
 
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
 
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" ;)
 
Wie oft wird denn ein "Ping" oder dieses "keepalive_ip" von der Fritzbox angestoßen? Weiß das zufällig jemand?
 
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.
 
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

  • fritzbox-vcc0_08.07.20_1859.eth.txt
    572.9 KB · Aufrufe: 8
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).
 
Ist ja eine wireshark Datei. Da kommt im 20 Sekunden Takt ein NAT-Keepalive.
 
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.
 
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

  • iad-if-lan_09.07.20_0946.eth.txt
    163 KB · Aufrufe: 3
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?
 
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.
 
  • Like
Reaktionen: Micha0815
Also an der Ziel-Box finde ich nix von den "entfernten Boxen" mit den IPs 192.168.15.1 oder 192.168.20.1 ... weder auf dem LAN-Interface, noch auf dem Internet-Interface...

Der Paketmitschnitt dauerte jeweils 5 Minuten...
 
Nochmal drei Mitschnitte der Iinterfaces "internet", "routing" und "lan".

an keinem Interface finde ich was vom keepalive_ip der Sourcen intern 192.168.15.1 und 192.168.20.1 ... lediglich alle 20 Sekunden einen NAT-Keepalive der jeweiligen externen Sourcen 185.*.*.*.

Einmal ist ein Ping (ICMPv4) um 10:20 zu sehen, der tatsächlich von der Box 192.168.20.1 aufschlägt. Dies ist ein Ping, welcher von der entfernten Box per Cron alle 5 Minuten auf die hiesige Box mit 192.168.1.1 ausgeführt wird. Das ist mir das einzige, was angezeigt wird.

Wird das evtl nirgends protokolliert?
 

Anhänge

  • fritzbox-vcc0_17.07.20_1019.eth.txt
    114 KB · Aufrufe: 0
  • fritzbox-ip_17.07.20_1019.eth.txt
    88.2 KB · Aufrufe: 1
  • iad-if-lan_17.07.20_1019.eth.txt
    600.9 KB · Aufrufe: 0
Ich bin gerade mit etwas komplett anderem beschäftigt.

Diesen Thread habe ich mir auf "Erinnerung" gelegt - so ca. in ein bis zwei Wochen schaue ich mir das mal an, da bin ich dann sicherlich auch so weit, das VPN mit der 07.19/07.20 richtig zu testen und zu erkunden, was sich durch die neue Implementierung geändert hat und was nicht. Dabei muß ich ohnehin hier zwei FRITZ!Boxen passend einrichten, dann prüfe ich das mit dem ICMP-Paket noch einmal. Aber das mit den 100 Byte durch 25x "PING" im Payload (so steht's iirc in dem anderen Thread) hatte ich mir ja nicht ausgedacht - das habe ich also irgendwann mal protokolliert. Wann das war, kann man anhand des Threads in etwa einordnen - auch wenn ich nicht wirklich glauben will, daß sich da Entscheidendes geändert hat; jedenfalls nicht bis zur neuen Implementierung durch AVM.
 
Also bei mir laufen drei 3490 mit FOS7.12 und freetz, und eine 6890 mit FOS 7.13 ohne freetz ...
 
Ich verstehe/sehe zwar gerade den Zusammenhang nicht, aber wenn ich für die Tests mit den neuen FRITZ!OS-Versionen dann die Boxen schon passend konfiguriert und verkabelt habe, ist ein (zusätzlicher) Test mit älteren Versionen auch kein Problem mehr und irgendwie ja sogar "Pflicht", wenn man Unterschiede zwischen 07.1x und 07.2x auch "sicher" erkennen/nachweisen/protokollieren will. Bei der Gelegenheit schaue ich dann auch noch mal nach den ICMP-Pakete, die sich aus der "keepalive_ip" ableiten sollten - warum die bei Dir nicht ankommen sollten, kann ich gerade nicht nachvollziehen und da kann man einfach noch zu viel falsch konfigurieren, als daß ich das jetzt "auf Verdacht hin" mit jemandem durchkauen wollte.

Wenn eine IP im LAN beim Peer dort angegeben ist, sollte der ICMP-Generator auch angeworfen werden ... und bisher war dieses Paket auch immer der Grund, warum überhaupt direkt eine VPN-Verbindung eingerichtet wurde (nicht mit "konfiguriert" oder "eingeschaltet/gestartet" zu verwechseln - das sind alles Zustände, bei denen die Verbindung noch nicht hergestellt wurde), da es als Traffic für das LAN beim Peer daherkam. Wenn die Verbindung auch ohne sonstigen Traffic aufgebaut wird (also nicht "on demand", wenn jemand anderes zugreifen will), dann muß es dafür ja irgendeine Ursache geben und wenn als IP-Adresse nicht die der Box selbst angegeben wurde, MUSS das Paket eigentlich ausgeliefert werden. Und das wäre auch der nächste Ansatzpunkt ... es mag noch viele Gründe geben, warum das ICMP-Paket nicht im FRITZ!Box-eigenen Mitschnitt auftaucht - u.a. wäre es denkbar, daß es nach dem Entschlüsseln an einer Stelle "eingespeist" wird, wo es nicht länger an der "Protokollierung" vorbeikommt. Aber spätestens auf dem adressierten Ziel im entfernten LAN sollte es sich dann in den Netzwerk-Paketen finden lassen ... es gibt also noch genug andere Möglichkeiten, das Problem zu untersuchen.

Nur habe ich echt keinen Bock, das im Moment ausführlich zu klären bzw. auch nur zu überlegen, woran es am Ende scheitern könnte - das oben sind nur "erste Ideen" und die haben mit einer systematischen Fehlersuche nichts zu tun.

Entweder Du entwickelst selbst die notwendige Phantasie, um das Problem weiter zu untersuchen - z.B. wäre es sogar noch einen Test wert, ob der "ICMP-Generator" tatsächlich nur Adressen aus dem entfernten LAN akzeptiert bzw. nur die Pakete generiert, wenn das Ziel auch dort liegt oder ob er sogar diese Pakete ins eigene LAN senden würde, wenn da als "keepalive_ip" eine Adresse aus seinem eigenen LAN angegeben ist. Klappt das, bräuchte man für die Klärung, wie häufig die gesendet werden und wie groß sie sind/welche Daten sie enthalten, nicht mal die aufgebaute VPN-Verbindung,.

Ohne die eigene Phantasie bzw. die daraus resultierenden Versuche mußt Du halt warten, bis ich wieder mal die Zeit dafür finde. Aber im Moment muß ich erst mal ein paar Sachen zum Ende bringen (jetzt kommen die 07.20-Versionen ja so langsam tatsächlich "in Sicht") und kann mich nicht (schon wieder) von anderen Dingen davon ablenken lassen, sonst wird das nie etwas, weil sich dann fast wieder das Warten auf das nächste Release von AVM und die dort enthaltenen Überraschungen lohnt.

Die Frage, was AVM am VPN gemacht hat und wie sich das (a) auf die Geschwindigkeit und (b) auf den generierten Traffic auswirkt, sind jedenfalls bei mir erst einmal Nebensache - höchstens die Frage, wie die Crypto-Hardware eingebunden wurde, ist noch interessant, wenn es um die Frage der "Nachnutzung" in anderen Programmen (vom SSH- über andere VPN- bis hin zum HTTPS-Server) geht. Aber das AVM-VPN ist da erst mal nur "Studienobjekt" und nicht das primäre Ziel meiner eigenen Neugierde.
 
Wie gesagt, ich finde lediglich UDPENCAP-Pakete auf den Interfaces ... mehr nicht.. keine Ahnung wohin die Pakete geschossen werden...
 
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.