VPN Verbindung nach FRITZ!Box 6490 Cable baut sich nicht ab

[yauser23]

Hallo,

hoffe es past in dieses Forum:

Habe auf einem Linux Mint Cinnamon System mit dem Networkmanager eine VPN-Verbindung zur 6490 Cable (FW: 6.87 ; Vodafone Mietbox) nach der AVM Anleitung mit dem Cisco-kompatiblen-VPN-Client (vpnc) aufgebaut.
Auf und Abbau klappt auch scheinbar wunderbar. Ich kann auf die Geräte wie lokal drauf zugreifen und nach trennen der Verbindung nicht mehr.
Durch Zufall ist mir aufgefallen, daß die VPN-Verbindung dauerhaft aktiv (grün) im Webinterface der Fritzbox angezeigt wird, obwohl laut Networkmanager die Verbindung abgebaut ist und ich auch keine Erreichbarkeit vom Client ins VPN habe.
Anscheinend baut der Client die Verbindung nicht ordnungsgemäß ab.
Ich muss die Verbindung im Webinterface manuell trennen (deaktivieren/aktivieren), damit sie nicht mehr aktiv im Webinterface angezeigt wird.

Bei einem VPN-Aufbau unter Windows mit Shrewsoft wird die Verbindung auf und abgebaut, so wie es sein soll. Bei dem Linux Client nicht!?

Woran könnte dies liegen, bzw. wie kann ich den Fehler eingrenzen/suchen?
Hat das am Ende etwas mit der Vodafone Firmware zu tun?

 

[PeterPawn]

Normalerweise gibt es bei IKEv1 für den "Client" gar keine Möglichkeit, die SAs auf der Gegenseite abzuräumen (jedenfalls soweit ich weiß, ich nehme Quellenangaben für gegenteilige Aussagen gerne entgegen).

Jede Seite ist selbst dafür verantwortlich, die SAs für eine "Verbindung" abzuräumen und das kann aus drei Gründen erfolgen:

• die "lifetime" der SA ist überschritten, das kann auf Basis einer Zeit oder einer mit der SA übertragenen Datenmenge erfolgen ("lifetime" ist also nicht zwingend zeitabhängig)
• die Gegenseite reagiert auf R_U_THERE-Messages (im Rahmen der "dead peer detection" - DPD) nicht mehr
• die Gegenseite startet einen neuen Verbindungsversuch mit einer INITIAL-CONTACT-Message (RFC 2407)

Erst bei IKEv2 gibt es dann mit der DELETE-Message (RFC 4306) auch die Möglichkeit, eine SPI gezielt zu löschen.

Die "Ungewißheit" fängt also schon da an, wo man nicht genau weiß, wie die Verbindung hier konfiguriert ist bzw. was "zur Laufzeit" zwischen den Peers ausgehandelt wurde (DPD oder nicht, Werte für "lifetime", usw.).

Ich weiß nicht, über welche "Kunstkniffe" der ShrewSoft-Client die Verbindung auf der FRITZ!Box-Seite aktiv als "down" markieren könnte ... aber das kann man ja - anhand eines Protokolls - herausbekommen.

Denkbar wäre z.B., daß noch eine INITIAL-CONTACT-Message gesendet wird (ungeachtet des tatsächlichen ISAKMP-Status) - aber das ist auch eher Spekulation und ich würde die Beobachtung, daß die Verbindung bei der Benutzung des ShrewSoft-VPN-Client tatsächlich direkt beim Beenden auf der PC-Seite auch in der Box als "nicht aufgebaut" angesehen wird, erst noch einmal überprüfen - bei der Gelegenheit kann man dann ja auch gleich auf der ShrewSoft-Seite den Debug-Modus aktivieren und sich die übertragenen Pakete ansehen.

Man muß sich ja im IPSec-Kontext auch etwas von dem Begriff "Verbindung" verabschieden ... eine aktive Verbindung ist nichts anderes als die Annahme auf einer "Seite", daß man für den verschlüsselten Datenaustausch das notwendige Schlüsselmaterial hätte, um ausgehenden Verkehr selbst ver- und eingehenden Verkehr entschlüsseln zu können - ob das tatsächlich funktioniert, kann man erst durch aktive Übertragungen und deren Ergebnis herausfinden (DPD ist am Ende auch nichts anderes als eine regelmäßige Kontrolle durch so eine Übertragung). Etwas anderes gibt es da eigenlich nicht - anders als z.B. bei OpenVPN o.ä.

EDIT: Korrektur ... ich habe gerade gesehen, daß es bei IKEv1 doch schon die Definition einer DELETE-Message gibt - ist mir bisher halt nicht untergekommen: https://tools.ietf.org/html/rfc2408#section-3.15 - ändert aber an der Empfehlung, wo man nachsehen und ggf. debuggen sollte, nichts.

 

[yauser23]

Daß die VPNVerbindung "dauerhaft" aktiv angezeigt wird ist so nicht richtig.
Ich habe die Ereignisse der FB jetzt mal etwas genauer (und länger) beobachtet und bei 4 Versuchen festgestellt, daß:
- der Shrewsoft Client die Verbindung ziemlich unmittelbar beendet (VPN-Verbindung zu vpnuser wurde getrennt. Ursache: 3 IKE server)
- die VPN-Verbindung einmal nach ca. 8min nach Trennung vom Linux-Client beendet wird (VPN-Verbindung zu vpnuser wurde getrennt. Ursache: 12 SA loss)
- die VPN-Verbindung einmal nach ca. 16min nach Trennung vom Linux-Client beendet wird (VPN-Verbindung zu vpnuser wurde getrennt. Ursache: 9 Dead Peer Detection)
- die VPN-Verbindung einmal nach ca. 21min nach Trennung vom Linux-Client beendet wird (VPN-Verbindung zu vpnuser wurde getrennt. Ursache: 9 Dead Peer Detection)

Warum die Zeitdifferenz der Dead Peer Detection so weit auseinander? Keine Ahnung.

Die Erklärung der Verbindungstrennung in den Fritzbox Ereignissen ist hier erklärt:
https://avm.de/service/fritzbox/fri...-Box-meldet-VPN-Verbindung-zu-wurde-getrennt/

Ich verstehe trotzdem nicht, warum die Verbindung so lange "aktiv" bleibt, bevor die Trennung seitens der Fritzbox erfolgt.

 

[PeterPawn]

Weil es bei dieser Art der Verbindung seitens der FRITZ!Box nichts regelmäßig zu übertragen gibt und sie damit auch nicht feststellt, daß diese Übertragung nicht länger funktioniert ... wenn Du von einem Gerät an der FRITZ!Box nach dem Trennen im Linux ein "ping" o.ä. auf die Adresse des Clients versuchst (ich gehe mal davon aus, daß hier eine Verbindung mit "conntype_user" benutzt wird und da hat der Peer ja eine eigene Adresse), sollte die Verbindung auch entsprechend schneller als "tot" erkannt werden.

 

[yauser23]

Ja, ist so wie Du geschrieben hast.
Hatte nochmal eine Verbindung vom Linux-Client auf,-und abgebaut und dann über 30min gewartet und nichts gemacht. Die Verbindung war noch immer in der Fritzbox als aktiv angegeben. Erst als ich einen Ping auf die Peer-Adresse im lokalen Netz der Cable-Box abgesendet habe, trat kurz danach das Ereignis "...Ursache 9: Dead Peer Connection" auf. Den Ping hatte ich auch schon in den vorherigen Versuchen gemacht, und dadurch unbewusst das "Dead Peer Connection"-Ereignis ausgelöst.

Der Shrewsoft-Client ist ja dann wohl in der Lage die Verbindung ordnungsgemäß zu beenden (Ereignis: VPN-Verbindung zu vpnuser wurde getrennt. Ursache: 3 IKE server).
AVM sagt zu diesem Ereignis: "Ursache 3: Die Gegenstelle (z.B. FRITZ!Fernzugang) hat die VPN-Verbindung getrennt." (siehe Link Post #3).

Kann das eine Sicherheitslücke sein, wenn die Verbindung vom Linux-Client nicht auf diese Weise beendet wird?
Und gibt es eine Möglichkeit die Verbindung vom Linux-Client genauso zu beenden wie vom Shrewsoft-Client?

 

[Shirocco88]

Bei einem VPN-Aufbau unter Windows mit Shrewsoft wird die Verbindung auf und abgebaut, so wie es sein soll. Bei dem Linux Client nicht!?

üblicherweise gibt es den Shrewsoft Client auch für LINUX;
wie sieht es da mit "Linux Mint Cinnamon" aus, ist Shrewsoft da auch verfügbar ?

 

[yauser23]

üblicherweise gibt es den Shrewsoft Client auch für LINUX;
wie sieht es da mit "Linux Mint Cinnamon" aus, ist Shrewsoft da auch verfügbar ?

ja, den Client gibt es von der Herstellerseite zum Download (Release ist von Juni 2013). Möchte den aber auch gar nicht gerne installieren, da Closed Source und alt. Es ist auch viel bequemer den Networkmanager zu benutzen.
Wäre schöner, wenn man dem Netzwerkmanager bzw. dem vpnc Plugin beibringen könnte, die Verbindung ordentlich zu beenden.

ii  network-manager-vpnc                                        1.2.4-6ubuntu0.1                             amd64        network management framework (VPNC plugin core)
ii  network-manager-vpnc-gnome                                  1.2.4-6ubuntu0.1                             amd64        network management framework (VPNC plugin GNOME GUI)
ii  vpnc                                                        0.5.3r550-3                                  amd64        Cisco-compatible VPN client

 

[PeterPawn]

Das ist auch keine Sicherheitslücke, solange der "Client" die SPIs nicht irgendwoanders in der Gegend herumposaunt, nur weil er selbst sie nicht mehr nutzen will und als "kann weg" ansieht. Da die SAs auch immer "am Peer hängen" und mit der IP-Adresse des Gegenübers verknüpft sind, kann die auch ein anderer nicht so ohne weiteres benutzen, selbst wenn er sie kennt.

Da müßte - solange er nicht einfach "eavesdropping" betreiben will, aber da ist ja gar kein Traffic mehr, den er belauschen könnte - noch soo viel anderes zusammenpassen, damit sich jemand mit den falschen SPIs für einen anderen ausgeben kann, daß es vermutlich einfacher ist, das Kennwort für die Verbindung zu knacken (was hoffentlich nicht weniger als 32 Zeichen (echter) Zufall hat).

EDIT: Wer unbedingt die Verbindung sofort invalidieren will, kann ja mal mit der "keepalive_ip" versuchen, ob der AVM-Daemon auch für "conntype_user"-Verbindungen das ICMP-Paket (als Ergebnis einer gesetzten "keepalive_ip") absetzt. Wenn das so ist, geht die Verbindung auch entsprechend schnell wieder "down", wenn die Gegenstelle nicht mehr erreichbar ist.

 

[yauser23]

Wer unbedingt die Verbindung sofort invalidieren will, kann ja mal mit der "keepalive_ip" versuchen, ob der AVM-Daemon auch für "conntype_user"-Verbindungen das ICMP-Paket (als Ergebnis einer gesetzten "keepalive_ip") absetzt. Wenn das so ist, geht die Verbindung auch entsprechend schnell wieder "down", wenn die Gegenstelle nicht mehr erreichbar ist.

Wie genau mache ich das?

 

[PeterPawn]

Es gibt viele Wege ... wenn Du auf einem davon (die findet man z.B. mit einer Suche) nicht weiterkommst (und der nichtsdestotrotz einer der richtigen wäre), kriegst Du hier garantiert auch Hilfe.

Es wäre einfach unfair, hier den einen hervorzuheben, ohne die anderen ebenfalls zu erwähnen ... daher mache ich so etwas grundsätzlich nicht (oder zumindest sehr ungerne und das selbst dann, wenn es sich bei den dabei zu verwendenden Tools um meine eigenen "Schöpfungen" handelt).

Aber ich gehe jede Wette ein, daß schon der Nächste in den Startlöchern wartet, der Dir diese Mühen abnehmen wird ... insofern verlierst Du durch meine "Weigerung" nicht wirklich etwas (und ich gewinne trotzdem ... sei's auch nur das "gute Gewissen", niemanden "vorgezogen" zu haben - im doppelten Sinne).

 

[Shirocco88]

Wie genau mache ich das?

eine Änderung der Datei /var/flash/vpn.cfg kann über mehrere Wege erfolgen;

• wenn man direkten Shellzugang zur Box hat (z.B. via SIAB, telnetd, busybox-ssh, ...) dann kann man diese Config-Datei z.B. per "nvi /var/flash/vpn.cfg" ändern, dann die Fritzbox dazu bringen, dass die neue Config-Datei neu eingelesen (z.B. reboot, ...).
  
• eine weitere Möglichkeit ist Exportieren der VPN-Config http://fritz.box/?lp=mSave oder http://fritz.box/?lp=support, Extrahieren der vpn.cfg bzw. des gewünschten VPN-Profiles, die gewünschten Parameter anpassen, ggf. Konvertieren der verschluesselten Werte in Klartext-Äquivalente und dann das VPN-Profile importieren, ggf. noch vorher das vorhandene VPN-Profile löschen.

hierzu gibt es aber sicher noch Threads in diesem Forum, die den Ablauf im Detail beschreiben; einfach SuFu nutzen.

 

[yauser23]

wenn man direkten Shellzugang zur Box hat (z.B. via SIAB, telnetd, busybox-ssh, ...) dann kann man diese Config-Datei z.B. per "nvi /var/flash/vpn.cfg" ändern, dann die Fritzbox dazu bringen, dass die neue Config-Datei neu eingelesen (z.B. reboot, ...).

Da ich mich nur selten lokal bei der Box befinde, scheidet diese Möglichkeit aus.

eine weitere Möglichkeit ist Exportieren der VPN-Config http://fritz.box/?lp=mSave oder http://fritz.box/?lp=support, Extrahieren der vpn.cfg bzw. des gewünschten VPN-Profiles, die gewünschten Parameter anpassen, ggf. Konvertieren der verschluesselten Werte in Klartext-Äquivalente und dann das VPN-Profile importieren, ggf. noch vorher das vorhandene VPN-Profile löschen.

Danke, so ähnlich hatte ich es gedacht. Config exportieren, bearbeiten und zurück importieren.
Kann ich nicht einfach den entsprechenden Wert (hier keepalive_ip) in der heruntergeladenen config mit einen Texteditor ändern, abspeichern und nur den VPN-Teil zurückimportieren (Auswahl Fritzbox beim importieren)?
Na ja, werde das mal demnächst versuchen, dann sehe ich es.

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "vpnuser";
                boxuser_id = 12;
                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.x.x;
                keepalive_ip = 0.0.0.0;

Sonst werde ich versuchen mit dem Fritz Fernzugang eine Config zu generieren und den Wert zu ändern.

@PeterPawn
ich hatte das auch etwas unglücklich fomuliert mit "wie genau mache ich das?" Das "genau" hätte ich auch weglassen können. Es geht mir hier nur um einen groben funktionierenden Weg, da ich nicht viel "herumspielen" möchte an der Box, weil ich nicht immer vor Ort bin. Danke für den Hinweis auf "keepalive_ip".

 

[PeterPawn]

Kann ich nicht einfach den entsprechenden Wert (hier keepalive_ip) in der heruntergeladenen config mit einen Texteditor ändern, abspeichern und nur den VPN-Teil zurückimportieren (Auswahl Fritzbox beim importieren)?

Nein, das geht gerade nicht, wenn man nicht den wichtigen "Zwischenschritt" des Dekodierens der verschlüsselten Werte ausführt, den @Shirocco88 aber erwähnt hat. Denn dann importiert die Box die Daten genau so, wie sie in der Datei stehen.

Oder wenn damit dann doch nicht der VPN-Import gemeint sein sollte ... nach einer Änderung in einer Export-Datei muß man erst noch deren Prüfsumme (CRC32 am Ende) korrigieren, bevor die Box sie überhaupt als gültige Sicherungsdatei akzeptiert.

Danke für den Hinweis auf "keepalive_ip".

Es ist nur eine Möglichkeit, weil ich - steht oben - nicht weiß, ob die Option bei "conntype_user" überhaupt ausgewertet wird.

 

[Shirocco88]

Sonst werde ich versuchen mit dem Fritz Fernzugang eine Config zu generieren und den Wert zu ändern.

ich sehe noch keine "Notwendigkeit" das Programm Fritz!Fernzugang zu nutzen, das geht doch mit Export, Decoder, Parameter anpassen, Import, ...

das Programm Fritz!Fernzugang ist IMHO nicht mehr "taufrisch" und stammt noch aus Zeiten von Fritz!OS 5.x, wo es noch keine Möglichkeit gab, die VPN-Configuration im Web-Interface der Fritzbox zu bewerkstelligen; somit werden nicht die aktuellen bzw. zum aktuellen Fritz!OS Default-Encryption-Schemata ("phase1ss", "phase2ss") gesetzt.

 

[yauser23]

Oder wenn damit dann doch nicht der VPN-Import gemeint sein sollte ... nach einer Änderung in einer Export-Datei muß man erst noch deren Prüfsumme (CRC32 am Ende) korrigieren, bevor die Box sie überhaupt als gültige Sicherungsdatei akzeptiert.

Ja, so dachte ich das, aber wusste nichts von der CRC32 am Ende.

ich sehe noch keine "Notwendigkeit" das Programm Fritz!Fernzugang zu nutzen, das geht doch mit Export, Decoder, Parameter anpassen, Import, ..

Der Decoder-Link hat mir die Augen geöffnet (herzlichen Dank dafür, auch an den Author ).

Habe die exportierte Config decodiert,gesplittet und die vpn.cfg angepasst (keepalive_ip = IP wie remote_virtualip) . Dann die vpn.cfg in die FB importiert.
Leider scheint "keepalive_ip" doch nicht bei "conntype_user"-Verbindungen ausgewertet zu werden.
Ein Versuch war es aber trotzdem wert, schon wegen des Lerneffektes.

Wenn das wie @PeterPawn schreibt, auch keine Sicherheitslücke ist, so ist es doch blöde, weil im Ereignis-Log der Box die Trennungen der VPN-Verbindungen nicht exakt nachvollziehbar sind.
Mal schauen, ob ich dafür eine Lösung finde, oder mich einfach damit abfinde.

 

[Shirocco88]

@yauser23 feut mich, dass die vpn.cfg Änderung per Decoder-Binaries funktioniert hat ;-)

Habe die exportierte Config decodiert, gesplittet und die vpn.cfg angepasst

für etwaige nachfolgende Leser, hier die relevanten Programme:

decode_export: decrypt export file
split_export:  split an export file into the contained settings files
checksum:      compute CRC-32 value for input file

die Binaries sind für armv7, mips32r2, x86, x86_64 verfügbar,
die x86_64 Binaries sollten auch in Windows 10 BASH (Windows 10 Subsystem for Linux (WSL) Ubuntu) laufen.

 

[yauser23]

für etwaige nachfolgende Leser, hier die relevanten Programme:

Habe es wie in der Readme empfohlen mit den C-Programmen gemacht.

$ ./decoder.x86_64 decode_export -c  coded_config.export > decoded_config.export
$ mkdir split
$ ./decoder.x86_64 split_export -o split < decoded_config.export
$ nano split/vpn.cfg

### Zusammenführung Doppelpost by stoney ###

Mal schauen, ob ich dafür eine Lösung finde, oder mich einfach damit abfinde.

Habe es nun so versucht und die VPN-Verbindung wird sofort inaktiv in der Fritzbox, nach dem Beenden.

$ sudo nano /etc/vpnc/fb.conf

# Inhalt von /etc/vpnc/fb.conf
IPSec gateway xxxxxxxxx.myfritz.net
IPSec ID vpnuser
IPSec secret <SHARED SECRET>
IKE Authmode psk
Xauth username vpnuser
Xauth password <PASSWORD of vpnuser>
local port 0
DPD idle timeout (our side) 0

$ sudo vpnc fb.conf
$ sudo vpnc-disconnect

Vielleicht hat ja einer ne Ahnung, wieso das beim Networkmanager (siehe #1) anders ist.

 

[Shirocco88]

wieso das beim Networkmanager (siehe #1) anders ist.

Gibt es beim Networkmanager auch ein Config-File ?

Am Besten mal Einrichtung "screenshoten", d.h. die Bilder sowie "ip a" Befehlsoutput bei deaktivem VPN-Tunnel und aktivem VPN-Tunnel hier posten,
dann kann man dazu mehr sagen.

 

[yauser23]

Am Besten mal Einrichtung "screenshoten", d.h. die Bilder sowie "ip a" Befehlsoutput bei deaktivem VPN-Tunnel und aktivem VPN-Tunnel hier posten,
dann kann man dazu mehr sagen.

Ich kann jetzt auch gut mit der Lösung aus #17 ($ sudo vpnc fb.conf ; $ sudo vpnc-disconnect ) leben.
Aber da möchte ich nicht den ganzen Traffic über das VPN leiten, sondern nur den Netzwerkverkehr ins verbundene Subnet. Internet (Webseitenaufruf etc.) soll über den lokalen Router geleitet werden.
Habe nur noch nicht herausgefunden, wie ich die in #17 gezeigte fb.conf geändert werden muss um das zu erreichen.

 

[yauser23]

Habe die manpage von vpnc gelesen und dort steht:

--script <command>
              command is executed using system() to configure  the  interface,
              routing  and so on. Device name, IP, etc. are passed using envi‐
              ronment variables, see README. This  script  is  executed  right
              after  ISAKMP  is  done,  but before tunneling is enabled. It is
              called when vpnc terminates, too
              Default: /etc/vpnc/vpnc-script
       conf-variable: Script <command>

Heißt für mich also, man muss vpnc mit --script aufrufen mit Verweis auf ein externes Script

Der Inhalt von /etc/vpnc/vpnc-script (Standard-Script laut manpage) ist : https://pastebin.com/WNTM93fB

Stehe aber auf dem Schlauch, wo und was ich dort ändern muss (nachdem ich eine Kopie erstellt habe) um den "normalen" Internetverkehr (siehe letzter Beitrag) über den lokalen Router zu schicken.
Ich bin mir ziemlich sicher, dies haben schon etliche Leute gemacht und vielleicht ist es sogar in diesem Forum hier, aber ich bin zu blöd das zu finden.

Edit:

Route VPN aktiv
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         0.0.0.0         0.0.0.0         U     0      0        0 tun0
default         _gateway        0.0.0.0         UG    600    0        0 wlp3s0
ip1f12f352.dyna _gateway        255.255.255.255 UGH   0      0        0 wlp3s0
192.168.2.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0

Route VPN nicht aktiv
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    0      0        0 wlp3s0
default         _gateway        0.0.0.0         UG    600    0        0 wlp3s0
192.168.2.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0