[Problem] 6820 LTE - Zugriff via MyFritz oder DynDns-Anbieter nicht möglich

Shirocco88 · 6 Jan 2016

Hallo PeterPawn sowie alle VPN-Nutzer,
zuerst die gute Nachricht, die LAN-LAN-VPN-Verbindung konnte auch zwischen FB7490 FW 06.50 und FB6340 FB06.04 erfolgreich eingerichtet werden;

die Tests ergaben, dass sich FW-06.50 anders verhält als frühere FW-Versionen (z.B. DynDNS-Abhängigkeit oder P1-localid);
daher habe ich die Tests/Diagnosemethoden hier dokumentiert, so dass dies für Leser nachvollzogen werden kann.

Ausgangskonfiguration:

FB6340, FW 06.04, Public-IPv4, kein CGN/DS-Lite
==> LAN-IP: 192.168.0.1, Netzwerk: 192.168.0.0, Netzmask: 255.255.255.0
==> keine MyFritz-Registrierung
==> DynDNS Registrierung "xxxxx.ddns.net"

FB7490, FB 06.50, Internet-Zugang mit USB-Tethering Mobilfunk-Stick, NAT44-Config (Vodafone-SIM, UDP-Port 500 und UDP-Port 4500 sind jeweils ausgehend freigeschalten)
==> USB-Tethering, kein Portforwarding bei vorgeschaltenem NAT-Router aktiv
==> LAN-IP: 192.168.0.1, Netzwerk: 192.168.0.0, Netzmask: 255.255.255.0
==> WAN-IP: 192.168.8.100
==> keine MyFritz-Registrierung
==> keine DynDNS Registrierung
==> Fritzbox wurde vor Beginn der Tests auf Werkseinstellungen zurückgesetzt, FW tweaked with PeterPawn's modfs

Problem 1: IKE-Error 0x2027 "timeout"
bei "disable/enable" der VPN-Configuration bei GUI erhalte ich folgendes Fehlerbild:

Code:

FB7490_06.50# /sbin/eventsdump -d
TELNET,NOT_SIGNED,DEBUGCFG
05.01.16 22:22:07 VPN-Fehler: CT_LAN_to_fb6340, IKE-Error 0x2027 [10 Meldungen seit 05.01.16 22:16:52]
05.01.16 22:16:21 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 192.168.8.100, DNS-Server: 192.168.8.1 und 192.168.8.1, Gateway: 192.168.8.1
05.01.16 22:16:10 Internetverbindung wurde getrennt.
05.01.16 22:15:21 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 192.168.8.100, DNS-Server: 192.168.8.1 und 192.168.8.1, Gateway: 192.168.8.1
05.01.16 22:15:11 Internetverbindung wurde getrennt.

Code:

FB7490_06.50# Console.log:
Jan  5 22:15:25 ddnsd[5133]: startup ($Revision: 1.31 $$CompileDate: Dec  4 2015 14:47:44 $)
Jan  5 22:15:25 ddnsd[5133]: starting ...
Jan  5 22:15:25 ddnsd[5135]: DDNS: no valid accounts
Jan  5 22:15:25 ddnsd[5135]: [5135] Start failed

Code:

FB7490_06.50# cat /var/tmp/ike.log
2016-01-05 22:16:05 avmike:< add(appl=dsld,cname=CT_LAN_to_fb6340,localip=192.168.8.100, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-

all/pfs p1mode=4 keepalive_ip=192.168.0.1 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2016-01-05 22:16:05 avmike:new neighbour CT_LAN_to_fb6340:  nat_t
2016-01-05 22:16:05 avmike:CT_LAN_to_fb6340 start_vpn_keepalive 192.168.0.1
2016-01-05 22:16:21 avmike:< add(appl=dsld,cname=CT_LAN_to_fb6340,localip=192.168.8.100, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-

all/pfs p1mode=4 keepalive_ip=192.168.0.1 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2016-01-05 22:16:21 avmike:new neighbour CT_LAN_to_fb6340:  nat_t
2016-01-05 22:16:21 avmike:CT_LAN_to_fb6340 start_vpn_keepalive 192.168.0.1
2016-01-05 22:16:51 avmike:CT_LAN_to_fb6340: Phase 1 failed (initiator): timeout, checking ip address
2016-01-05 22:16:51 avmike:< cb_sa_create_failed(name=CT_LAN_to_fb6340,reason=IKE-Error 0x2027)
2016-01-05 22:17:26 avmike:CT_LAN_to_fb6340: Phase 1 failed (initiator): timeout, checking ip address
2016-01-05 22:17:26 avmike:< cb_sa_create_failed(name=CT_LAN_to_fb6340,reason=IKE-Error 0x2027)
FB7490_06.50#

Code:

# VPN assocs
# ----------
FB7490_06.50# cat /proc/kdsld/dsliface/internet/ipsec/assocs:
CT_LAN_to_fb6340: 192.168.8.100:0.0.0.0 255.255.255.255:0.0.0.0 0 SAs  valid enabled dynlocalip
    permit ip any 192.168.0.0 255.255.255.0
    Forbidden Clients: 192.168.179.0/24

Code:

# VPN connections
# ----------
FB7490_06.50# cat /proc/kdsld/dsliface/internet/ipsec/connections:
CT_LAN_to_fb6340: pmtu 0 mtu 1500 dont_filter_netbios

Code:

FB7490_06.50# /sbin/showdsldstat
time: 2016-01-05 22:19:40
0: sync_usb: ATA (showtime) 
 manual              0          0       0bit/s       0bit/s
 maxspeed            0          0       0bit/s       0bit/s
 actual              0          0       0bit/s       0bit/s
                                            0%           0%
running (voip=0,tr069=0,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled
VPN: CT_LAN_to_fb6340 connecting ... 
     error 8231 IKE-Error 0x2027 (2016-01-05 22:16:23)

0: name internet
0: sync_group: sync_usb
0: iface usb0 RBE/14/dsl c8:0e:14:aa:bb:cc stay online 1 (prop: default internet)
0: IPv6: off
0: IPv4: native
0: IPv4: connected since 2016-01-05 22:16:23 (setup time 0 secs) (connect cnt 3)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 192.168.8.100 mask 255.255.255.0 gw 192.168.8.1 dhcp mtu 1500
0: IPv4: masqaddr 192.168.8.100
0: IPv4: dns 192.168.8.1
0: route 192.168.8.0/24 protocol iface
0: route 192.168.8.1/32 via 192.168.8.1 protocol dns
0: mc to wan 224.0.255.135 (unknown), Received: Tue Jan  5 22:17:05 2016
0: RX bytes:71356 pkt error:0 discard:0 filtered:0 dropped:66
0: RX pkts:238 unicast:172 multicast:66 broadcast:0
0: TX bytes:46924 pkt error:0 discard:0 filtered:0 dropped:35
0: TX pkts:221 unicast:216 multicast:2 broadcast:3

Code:

FB7490_06.50# /bin/showshringbuf dnsd
2016-01-05 22:15:09.075 - 0/0 entries/bytes left
2016-01-05 22:15:09.075 - shutdown
2016-01-05 22:15:13.941 - startup
2016-01-05 22:15:22.609 - add A your-dns-needs-immediate-attention.mylan.local ttl=1056, flags=0x0000
2016-01-05 22:15:24.850 - add A 0.europe.pool.ntp.org ttl=137, flags=0x0000
2016-01-05 22:16:08.004 - del A your-dns-needs-immediate-attention.mylan.local (flags=0x0000)
2016-01-05 22:16:08.004 - del A 0.europe.pool.ntp.org (flags=0x0000)
2016-01-05 22:16:08.005 - 0/0 entries/bytes left
2016-01-05 22:16:08.005 - shutdown
2016-01-05 22:16:13.658 - startup
2016-01-05 22:16:21.570 - add A your-dns-needs-immediate-attention.mylan.local ttl=1056, flags=0x0000
2016-01-05 22:16:25.531 - add A 0.europe.pool.ntp.org ttl=137, flags=0x0000
FB7490_06.50#

Erkenntnis:
AVM-Knowledgebase liefert zu "IKE-Error 0x2027" nur einen nichtssagenden Hinweis "timeout",
siehe http://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/015/hilfe_syslog_122
VPN-Verbindung wird nicht aufgebaut (siehe ike.log, showdslstat, ...),
eine DNS-Anfrage nach xxxxx.ddns.net wird nicht durchgeführt
==> es wird so wie es aussieht auf DynDNS-Dienst gewartet
Unklar, ob diese Dienste-Abhängigkeit schon in früheren Firmware-Versionen bestand, z.B. FB6340/FB7270 mit FW 05.87

Durchgeführte Änderungen: MyFRITZ-Account @FB7490 und in vpn.cfg eingerichtet.

Problem 2: IKE-Error 0x202E "dns: unspecified error"
bei "disable/enable" der VPN-Configuration bei GUI erhalte ich folgendes Fehlerbild:

Code:

FB7490_06.50# cat /var/tmp/ike.log
2016-01-05 23:09:12 avmike:< add(appl=dsld,cname=  CT_LAN_to_fb6340,localip=192.168.8.100, remoteip=255.255.255.255,  p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-

all/pfs p1mode=4 keepalive_ip=192.168.0.1 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2016-01-05 23:09:12 avmike:new neighbour  CT_LAN_to_fb6340:  nat_t
2016-01-05 23:09:12 avmike:CT_LAN_to_fb6340 start_vpn_keepalive 192.168.0.1
2016-01-05 23:09:16 avmike: CT_LAN_to_fb6340: Phase 1 failed (initiator): IKE-Error 0x202e
2016-01-05 23:09:16 avmike:< cb_sa_create_failed(name= CT_LAN_to_fb6340,reason=IKE-Error 0x202e)

Code:

FB6340_06.04# /var/tmp/ike.log
-rw-r--r--    1 root     root         13265 Jan  6 00:17 /var/tmp/ike.log
-rw-r--r--    1 root     root         20580 Jan  5 23:05 /var/tmp/ike.old
2016-01-05 23:08:32 avmike:unknown remote peer supported XAUTH
2016-01-05 23:08:32 avmike:unknown remote peer supported DPD
2016-01-05 23:08:32 avmike:unknown remote peer supported NAT-T RFC 3947
2016-01-05 23:20:52 avmike:unknown remote peer supported XAUTH
2016-01-05 23:20:52 avmike:unknown remote peer supported DPD
2016-01-05 23:20:52 avmike:unknown remote peer supported NAT-T RFC 3947
2016-01-05 23:21:26 avmike:unknown remote peer supported XAUTH
2016-01-05 23:21:26 avmike:unknown remote peer supported DPD
2016-01-05 23:21:26 avmike:unknown remote peer supported NAT-T RFC 3947
2016-01-05 23:21:58 avmike:unknown remote peer supported XAUTH
2016-01-05 23:21:58 avmike:unknown remote peer supported DPD
2016-01-05 23:21:58 avmike:unknown remote peer supported NAT-T RFC 3947
SNIP

Erkenntnis:
AVM-Knowledgebase liefert zu IKE-Error 0x202E "dns: unspecified error",
siehe http://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/015/hilfe_syslog_122
die remoteid-fqdn/localid-fqdn passen nicht der beiden Boxen zueinander, evtl. Zusammenhang mit Non-Public-DNS-Suffixes "*.vpn.local" gegeben

anschließend Änderung FB6340-IPv4.cfg von

Code:

localid {
   fqdn = "fb6340.vpn.local";
}
remoteid {
   fqdn = "";
}

nach

Code:

remoteid {
   fqdn = "xxxxx.myfritz.net";
}

Änderung FB7490-umts.cfg von

Code:

remoteid {
   fqdn = "fb6340.vpn.local";
}

nach

Code:

remoteid {
   fqdn = "xxxxx.ddns.net";
}

nach Import und Aktivieren der Config hat die VPN-Verbindung funktioniert.

Hinweis: die vpn.cfg hat sich bei FB7490-06.50 nach Reboot automatisch geändert:

Code:

localid {
   fqdn = "SECRET";
}
remoteid {
   fqdn = "xxxxx.ddns.net";
}

Hab noch folgende Fragen:
Welche Bedeutung hat "localvirtualip 0.0.0.0 dns1 0.0.0.0 dns2 0.0.0.0" bei "showdsldstat" ?

Code:

FB7490_06.50# /sbin/showdsldstat
time: 2016-01-06 11:03:24
0: sync_usb: ATA (showtime) 
 manual              0          0       0bit/s       0bit/s
 maxspeed            0          0       0bit/s       0bit/s
 actual          21312        216  21.31Kbit/s     216bit/s
                                            0%           0%
running (voip=0,tr069=0,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled
VPN: CT_LAN_to_fb6340 connected since 2016-01-06 10:53:45 (setup time 1 secs)
[COLOR=#0000ff]     localvirtualip 0.0.0.0 dns1 0.0.0.0 dns2 0.0.0.0[/COLOR]

Wie sollte "always_renew" eingestellt werden ? Steht dies nicht in Konflikt mit keepalive_ip ?
evtl. kann hierzu mir jemand antworten geben.

ich mache gerade noch Langzeit- und Streßtest (FTP-Übertragung) via VPN-Tunnel.

Gruß Shirocco88

EDIT:
Fehlerbild "unknown remote peer" in /var/tmp/ike.log:

Code:

FB6340:/var/tmp/ike.log
2016-01-04 07:11:03 avmike:[COLOR=#ff0000]unknown remote peer[/COLOR] supported XAUTH
2016-01-04 07:11:03 avmike:[COLOR=#ff0000]unknown remote peer[/COLOR] supported DPD
2016-01-04 07:11:03 avmike:[COLOR=#ff0000]unknown remote peer[/COLOR] supported NAT-T RFC 3947
2016-01-04 07:11:39 avmike:[COLOR=#ff0000]unknown remote peer[/COLOR] supported XAUTH
2016-01-04 07:11:39 avmike:[COLOR=#ff0000]unknown remote peer[/COLOR] supported DPD
2016-01-04 07:11:39 avmike:[COLOR=#ff0000]unknown remote peer[/COLOR] supported NAT-T RFC 3947

Ursache:
P1-Identifikation-Missmatch (remoteid vs. localid Missmatch)
Details:
FB6340_ipv4:vpn.cfg

Code:

remoteid {
     ip = 0.0.0.0;
     }

FB7490_NAT44:vpn.cfg

Code:

localid {
     fqdn = "CT_LAN_to_fb6340.<dyndns.org>";
}

Lösung:
sicherstellen, dass die P1-Identifikationen der beiden vpn.cfg wechselseitig (remoteid <==> localid) übereinstimmen;
ggf. mit "allcfgconv_06.03 -C vpn -c -o -" mit telnet prüfen, siehe #25

PeterPawn · 6 Jan 2016

Die Änderung der im Klartext importierten Werte in die verschlüsselte Form ist vollkommen normal. Warum AVM das auch für die IDs in Phase1 gewählt hat, weiß ich auch nicht ... es macht die Kontrolle, was da am Ende steht, für den Benutzer eben nicht gerade leichter (MyFRITZ!- vs. DynDNS-Account als Problem ist ja bekannt). Was ich gar nicht begreife, ist die Anzeige der "remoteid" nach dem Neustart in der vpn.cfg im Klartext ... jedenfalls dann nicht, wenn der Import über die regulären Schnittstellen erfolgte und damit das Serialisieren aus dem OS heraus erfolgte.

"always_renew" dürfte (sind halt alles nur empirisch gewonnene Erkenntnisse) bei gleichzeitig aktivem "keepalive_ip"-Eintrag tatsächlich keine Rolle spielen ... meine Interpretation an dieser Stelle ist: "Immer eine neue SA beim Ablauf einer alten etablieren, auch wenn aktuell gerade kein Traffic durch den Tunnel muß/will." - das wäre bei aktivem (ICMP-)Keepalive ja nie wirklich der Fall. Einen Konflikt sehe ich da allerdings nicht, weil auch "always_renew=no" dann eben nicht heißt, daß da gar keine SA mehr installiert werden soll - eben nur, daß das nur bei tatsächlichem Bedarf erfolgen soll.

So ganz habe ich den Verlauf aber auch nicht verstanden ... wenn ich das zusammenfassen müßte, wäre das nach meinem Verständnis:

1. Mind. ein DNS-Account muß konfiguriert sein (das heißt sicherlich nicht auch aktiviert), ansonsten hat das FRITZ!OS Probleme mit der "localid" auch in importierten Konfigurationsdateien für das VPN.

2. Eventuell hat die Box tatsächlich ein Problem mit bestimmten Domains, wobei ich nicht erkennen kann, ob nicht 1. das Problem ebenfalls schon gelöst hätte/hat.

3. Die Speicherung einer "remoteid" in einer vpn.cfg in unverschlüsselter Form in der Box (beim Einspielen über "normale Mechanismen") ist sehr befremdlich.

Die Angaben bei der VPN-Verbindung haben m.W. nur dann eine (sinnvolle) Bedeutung, wenn die Box ihrerseits als "Client" in einer Host2LAN-Verbindung aktiv ist und geben dann die eigene IP-Adresse der Box im VPN und zusätzliche DNS-Server im entfernten Netz an.

Shirocco88 · 6 Jan 2016

Hallo PeterPawn,

Mind. ein DNS-Account muß konfiguriert sein (das heißt sicherlich nicht auch aktiviert), ansonsten hat das FRITZ!OS Probleme mit der "localid" auch in importierten Konfigurationsdateien für das VPN.

==> bei mir ist auf FB6340 kein DynDNS konfiguriert; die DynDNS-Registrierung für die WAN-IP der FB6340 macht bei mir ein Raspberry-PI, Hintergrund: ich wollte vermeiden, dass die DynDNS-Credentials durch KNB z.B. per TR069 abgegriffen werden können.
==> bei FB7490 wird MyFRITZ-Service als DynDNS verwendet.

Wenn man den avmike-Prozess betrachtet, so liegt nach meinen Tests eine Abhängigkeit bzgl. DDNS-Dienst und FW-Version vor:
==> FW 06.04: hier konnte VPN-Connection ohne DDNS-Service auf FB6340 gestartet werden.
==> FW 06.50: hier konnte VPN-Netzverbindungsufbau nur mit funktionierden DynDNS/MyFritz-Dienst auf der FB7490 durchgeführt werden.

Hinweis: bei mir ist bei FB6340 keine localid konfiguriert, ~~dies macht das Einrichten von VPN-Mesh-Netzwerken einfacher.~~

Eventuell hat die Box tatsächlich ein Problem mit bestimmten Domains

für mich sieht es nach den Tests so aus, dass bei FW 06.50 die "gefakten" DNS-Namen "*.vpn.local" - wie in Thread http://www.ip-phone-forum.de/showthread.php?t=282261&p=2127273&viewfull=1#post2127273 beschrieben - nicht mehr funktionieren, ich denke da erfolgt neuerdings eine Plausibilitätsprüfung.

Die Speicherung einer "remoteid" in einer vpn.cfg in unverschlüsselter Form in der Box (beim Einspielen über "normale Mechanismen") ist sehr befremdlich.

Bei mir hat die FB7490 mit 06.50 eine per nvi im Klartext gesetzte "remoteid" nach reboot automatisch in verschlüsselte Form konvertiert;

Alles wie gesagt meine Erfahrungen;
konstruktives Feedback gerne ;-)

Gruß Shirocco88

EDIT: Configuration bzgl. DynDNS bzgl. FB6340/FB7490 angepasst/eingepflegt.
EDIT2: Bemerkung bzgl. "Missing localid" und Mesh-Netzwerken gemäß Hinweis von PeterPawn #28 gestrichen

PeterPawn · 6 Jan 2016

Das war mir selbst gar nicht mehr bewußt, daß ich selbst mal "*.vpn.local" als Test vorgeschlagen hatte ... da füge ich gleich noch einen Kommentar hinzu, daß man besser eine andere Domain ab 06.50 nimmt. Damals ging es mir auch nur darum, da einen klaren Unterschied zwischen einem leeren FQDN bei "localid" (wie in der davor gezeigten Konfiguration) und irgendeinem anderen Wert zu erhalten, der eben nichts mit einem DynDNS-Namen zu tun haben sollte. Für mich ist die Angabe einer lokalen ID für P1 mit einem leeren FQDN etwas vollkommen anderes als das komplette Fehlen einer "localid".

Wobei ich tatsächlich erstaunt bin, daß das AVM-VPN auch ohne lokale ID für P1 (in einer conntype_lan-Verbindung) funktioniert ... ich blicke aber auch nach #21 jetzt gar nicht mehr durch, was da in welcher Box am Ende bei den IDs für Phase1 übrig geblieben ist.

Was ich mir nicht erklären könnte, wäre der Umstand, daß eine VPN-Verbindung mit PSK auch dann funktioniert, wenn in jeder der beiden beteiligten Boxen nur eine "remoteid" für die andere Seite konfiguriert ist.

Nach meinem Verständnis dürfte dann die Responder-Box gar nicht in der Lage sein, den richtigen PSK zu lokalisieren, weil sie vom Peer ja nur ihre eigene "localid" übermittelt bekommt und mit der kann sie die Verbindung spätestens dann nicht mehr finden, wenn da zwei verschiedene VPN-Verbindungen konfiguriert sind.

Solange der Initiator nicht wenigstens seine eigene lokale ID übermittelt, mit der der Responder dann nach dem PSK suchen kann, verstehe ich einfach nicht, wie der Responder zwei unterschiedliche VPN-Clients auseinanderhalten sollte (die IP kann es ja nicht sein, wenn die dynamisch ist) und da wird ja hoffentlich nicht mit allen PSKs solange probiert, bis endlich einer paßt.

Nach meinem Weltbild besteht so eine PSK-"Datenbank" aus Datensätzen mit drei verschiedenen "Werten", der lokalen und der entfernten ID für P1 und dem PSK. Solange nicht wenigstens eine der beiden IDs auf den Datensatz paßt, sollte auch dieser PSK nicht ausgewählt werden für das Verschlüsseln einer Antwort auf einen einkommenden Verbindungswunsch. Die Identität des Responders hängt am Ende an diesem PSK und an nichts anderem ... wenn der auf der Basis der Angaben des Initiators im ersten Paket (beim "aggressive mode") nicht identifiziert werden kann, kann da ja nicht einfach der Reihe nach irgendetwas probiert werden.

Also muß wenigstens eine "remoteid" (auf der anderen Seite ist das logischerweise die "localid") sowohl angegeben sein als auch zur VPN-Verbindung passen ... wenn das auch ohne so ein "match" gehen sollte, wäre das in meinen Augen tatsächlich ein Fehler. Ich weiß zwar momentan auch nicht, was der Standard dazu sagt, aber wenn die Box tatsächlich nach dem Motto "Ich habe nur einen Key, also muß es der sein." auf beliebige eingehende (erste) IKE-Pakete mit ein und demselben Key reagieren sollte, ist das in meinen Augen ein Sicherheitsrisiko.

Es wäre also schön, wenn Du noch einmal die endgültige Konstellation bei den IDs für P1 in einem Stück zusammenfassen könntest ... wenn Du sie selbst nicht mehr lesen kannst, nachdem die FRITZ!Box sie verschlüsselt gespeichert hat, hilft entweder "allcfgconv" in der richtigen Version oder "decode_passwords" (bzw. das in Freetz importierte Pendant fritzos_cfg_decrypt (o.s.ä.)).

Shirocco88 · 6 Jan 2016

PeterPawn schrieb:
Es wäre also schön, wenn Du noch einmal die endgültige Konstellation bei den IDs für P1 in einem Stück zusammenfassen könntest ... wenn Du sie selbst nicht mehr lesen kannst, nachdem die FRITZ!Box sie verschlüsselt gespeichert hat, hilft entweder "allcfgconv" in der richtigen Version oder "decode_passwords" (bzw. das in Freetz importierte Pendant fritzos_cfg_decrypt (o.s.ä.)).

EDIT: das allcfgconv-Binary aus FW 06.03 funktioniert bei FB7490-06.50 ohne Probleme, Anleitung pp aus Posting 2147714, Variante C:

Code:

FB7490_0650# mkdir /var/firmware_06.03
FB7490_0650# mount /var/media/ftp/firmware_06.03/rootfs.squashfs /var/firmware_06.03
FB7490_0650# ls -la /var/firmware_06.03/bin/allcfgconv_06_03 /bin/allcfgconv
-rwxrwxrwx    1 root     root          9336 Dec  8 13:50 /bin/allcfgconv
-rwxrwxrwx    1 root     root          9380 Feb  7  2014 /var/firmware_06.03/bin/allcfgconv
FB7490_0650# mount --bind /var/firmware_06.03/bin/allcfgconv /bin/allcfgconv
FB7490_0650# /bin/allcfgconv -C vpn -c -o -
vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "CT_LAN_to_fb6340";
                boxuser_id = 0;
                [COLOR=#0000FF]always_renew = yes;[/COLOR]
                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 = "xxxxx.ddns.net";
                keepalive_ip = 192.168.0.1;
                localid {
                        fqdn = "xxxxx.myfritz.net";
                }
                remoteid {
                        fqdn = "xxxxx.ddns.net";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "SECRET";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.0.0 255.255.255.0",
                             "permit ip any 192.168.1.0 255.255.255.0";
                app_id = 0;
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


// EOF
#

Hier habe ich noch das Perimeter-LAN 192.168.1.0/24 in accesslist aufgenommen, so dass ich auch von diesem LAN den Tunnel nutzen kann.

wie kann ich dies bei FB6340 durchführen ?
hier habe ich kein Telnet; mir liegt nur ein Export-File vor.

Code:

/*
 * /var/flash/vpn.cfg
 * Wed Jan  6 00:49:07 2016
 */

meta { encoding = "utf-8"; }

vpncfg {
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "CT_LAN_to_FB7490";
                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;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        fqdn = "[COLOR=#FFA500]SECRET[/COLOR]";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "SECRET";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.178.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


// EOF

Gruß Shirocco88

EDIT:
Nutzung von allcfgconv gemäß "Posting 2147714, Variante C" eingepflegt.

PeterPawn · 6 Jan 2016

Shirocco88 schrieb:
irgendwie funktioniert das genannte Programm bei FB7490-06.50 nicht:

Ja, steht in dem Thread auch in #1 so drin ... muß man eben einen anderen Weg suchen (und finden) - aber wenn Du das nicht ohnehin brauchst, vergiß es einfach.

wie kann ich dies bei FB6340 durchführen ?
hier habe ich kein Telnet; mir liegt nur ein Export-File vor.

Ja, die habe ich tatsächlich nie gehabt ... auch hier wieder: vergiß es. Solltest Du generell Interesse an Telnet auch auf der 6340 haben, sollte eigentlich die Lösung für die 6360 genauso funktionieren, wenn man die Skripte etwas anpaßt (bei der HWRevision und den 6490-Teil dann gleich entsorgt).

Zumindest für die 7490 (die ist ja offenbar der Initiator), sieht das aber dann doch wieder so aus, daß da eine "localid" konfiguriert ist. Nur wenn die jetzt nicht mit der "remoteid" in der 6340 übereinstimmt und das trotzdem funktioniert, ist ja die Theorie aus dem Beitrag zuvor überhaupt relevant. Wenn die Werte übereinstimmen (also die entschlüsselten), ist zumindest wieder erklärbar, wie der avmike den richtigen Eintrag findet (auf der 6340).

Shirocco88 · 6 Jan 2016

Hallo PeterPawn und andere VPN-User,
nun habe ich doch noch ein Problem mit VPN-Verbindung, nach ca. 1h funktioniert der Ping nicht mehr,
die VPN-Verbindung wird jedoch auf beiden Boxen "grün" angezeigt (Internet >> Freigabe >> VPN).

Code:

FB7490_0650# cat /var/tmp/ike.log
1970-01-01 01:01:08 avmike:< add(appl=dsld,cname=CT_LAN_to_fb6340,localip=192.168.8.100, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=192.168.0.1 flags=0x48001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
1970-01-01 01:01:08 avmike:new neighbour CT_LAN_to_fb6340:  nat_t
1970-01-01 01:01:08 avmike:CT_LAN_to_fb6340 start_vpn_keepalive 192.168.0.1
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: Warning: source changed from 0.0.0.0:500 to 37.209.39.122:500
2016-01-06 19:07:15 avmike:mainmode CT_LAN_to_fb6340: selected lifetime: 3600 sec(no notify)
2016-01-06 19:07:15 avmike:mainmode CT_LAN_to_fb6340: add SA 1
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340 remote peer supported XAUTH
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340 remote peer supported DPD
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340 remote peer supported NAT-T RFC 3947
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: sending embedded inital contact message (0,37.209.39.122,0.0.0.0)
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: switching to NAT-T (Initiator)
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: Phase 1 ready
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: current=0.0.0.0 new=37.209.39.122:4500
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340 start_vpn_keepalive already running
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: no valid sa, reseting initialcontactdone flag
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: local is behind a nat
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: sending initial contact message
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: start waiting connections
2016-01-06 19:07:15 avmike:CT_LAN_to_fb6340: Phase 2 starting (start waiting)
2016-01-06 19:07:16 avmike:CT_LAN_to_fb6340: Phase 2 ready
2016-01-06 19:07:16 avmike:< cb_sa_created(name=CT_LAN_to_fb6340,id=1,...,flags=0x00012101)
2016-01-06 19:07:16 avmike:CT_LAN_to_fb6340 stop_vpn_keepalive to 192.168.0.1
2016-01-06 19:07:16 avmike:CT_LAN_to_fb6340 start_keepalive_timer 3540 sec
2016-01-06 19:07:16 avmike:CT_LAN_to_fb6340: start waiting connections
2016-01-06 19:07:16 avmike:CT_LAN_to_fb6340: NO waiting connections
2016-01-06 19:07:26 avmike:>>>4500 nat-t-keepalive[37.209.39.122:4500]
2016-01-06 20:01:15 avmike:wolke_neighbour_renew_sa 1 SAs
2016-01-06 20:01:15 avmike:wolke_neighbour_renew_sa 1 SAs RENEW
2016-01-06 20:01:15 avmike:CT_LAN_to_fb6340: Phase 1 starting (renew)
2016-01-06 20:01:17 avmike:mainmode CT_LAN_to_fb6340: selected lifetime: 3600 sec(no notify)
2016-01-06 20:01:17 avmike:mainmode CT_LAN_to_fb6340: add SA 2
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340 remote peer supported XAUTH
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340 remote peer supported DPD
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340 remote peer supported NAT-T RFC 3947
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340: Phase 1 ready
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340: current=37.209.39.122:4500 new=37.209.39.122:4500
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340: local is behind a nat
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340: remote is behind a nat
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340: start waiting connections
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340: Phase 2 starting (start waiting)
2016-01-06 20:01:17 avmike:CT_LAN_to_fb6340: Phase 2 ready
2016-01-06 20:01:17 avmike:< cb_sa_created(name=CT_LAN_to_fb6340,id=2,...,flags=0x00032101)
2016-01-06 20:01:18 avmike:CT_LAN_to_fb6340 stop_vpn_keepalive to 192.168.0.1
2016-01-06 20:01:18 avmike:CT_LAN_to_fb6340 restart keepalive_timer timer_id 2001891392
2016-01-06 20:01:18 avmike:CT_LAN_to_fb6340: start waiting connections
2016-01-06 20:01:18 avmike:CT_LAN_to_fb6340: NO waiting connections
2016-01-06 20:01:20 avmike:CT_LAN_to_fb6340: Phase 1 failed (initiator): IKE-Error 0x202e
2016-01-06 20:01:28 avmike:>>>4500 nat-t-keepalive[37.209.39.122:4500]
2016-01-06 20:07:15 avmike:mainmode CT_LAN_to_fb6340: del SA 1
2016-01-06 20:07:16 avmike:FreeIPsecSA: spi=881ef0e             protocol=3 iotype=1
2016-01-06 20:07:16 avmike:FreeIPsecSA: spi=77bb                protocol=4 iotype=1
2016-01-06 20:07:16 avmike:FreeIPsecSA: spi=1efe8339            protocol=3 iotype=2
2016-01-06 20:07:16 avmike:FreeIPsecSA: spi=2fa4                protocol=4 iotype=2
FB7490_0650#

Code:

VPN assocs
----------
FB7490_0650# cat /proc/kdsld/dsliface/internet/ipsec/assocs
CT_LAN_to_fb6340: 192.168.8.100:0.0.0.0 109.xxx.yyy.zzz:0.0.0.0 1 SAs  valid enabled dynlocalip
    permit ip any 192.168.0.0 255.255.255.0
    permit ip any 192.168.1.0 255.255.255.0
    Forbidden Clients: 192.168.179.0/24
FB7490_0650#

Code:

VPN connections
---------------
FB7490_0650# cat /proc/kdsld/dsliface/internet/ipsec/connections
CT_LAN_to_fb6340: pmtu 0 mtu 1500 dpd_supported dont_filter_netbios local_nat remote_nat
FB7490_0650#

Code:

FB7490_0650#  /sbin/showdsldstat
time: 2016-01-06 20:42:25
0: sync_usb: ATA (showtime)
 manual              0          0       0bit/s       0bit/s
 maxspeed            0          0       0bit/s       0bit/s
 actual              0       4424       0bit/s   4.42Kbit/s
                                            0%           0%
running (voip=0,tr069=0,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled
VPN: CT_LAN_to_fb6340 connected since 2016-01-06 20:01:20 (setup time 2 secs)
     localvirtualip 0.0.0.0 dns1 0.0.0.0 dns2 0.0.0.0

0: name internet
0: sync_group: sync_usb
0: iface usb0 RBE/14/dsl c8:0e:14:aa:bb:cc stay online 1 (prop: default internet)
0: IPv6: off
0: IPv4: native
0: IPv4: connected since 2016-01-06 19:07:16 (setup time 1 secs) (connect cnt 1)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 192.168.8.100 mask 255.255.255.0 gw 192.168.8.1 dhcp mtu 1500
0: IPv4: masqaddr 192.168.8.100
0: IPv4: dns 192.168.8.1
0: route 192.168.8.0/24 protocol iface
0: route 192.168.8.1/32 via 192.168.8.1 protocol dns
0: mc to wan 224.0.255.135 (unknown), Received: Wed Jan  6 20:41:39 2016
0: RX bytes:3305904 pkt error:0 discard:0 filtered:0 dropped:2090
0: RX pkts:7199 unicast:5108 multicast:2090 broadcast:1
0: TX bytes:946634 pkt error:0 discard:0 filtered:0 dropped:10
0: TX pkts:4061 unicast:4038 multicast:6 broadcast:17
FB7490_0650#

Code:

FB7490_0650# /sbin/eventsdump -d
TELNET,NOT_SIGNED,DEBUGCFG
06.01.16 19:07:16 VPN-Verbindung zu CT_LAN_to_fb6340 wurde erfolgreich hergestellt.
06.01.16 19:07:14 Die Systemzeit wurde erfolgreich aktualisiert von Zeitserver 46.18.10.10.
06.01.16 19:07:13 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 192.168.8.100, DNS-Server: 192.168.8.1 und 192.168.8.1, Gateway: 192.168.8.1
FB7490_0650#

Code:

FB7490_0650# ping www.google.de
PING www.google.de (216.58.209.131): 56 data bytes
64 bytes from 216.58.209.131: seq=0 ttl=49 time=128.613 ms
64 bytes from 216.58.209.131: seq=1 ttl=49 time=128.030 ms
64 bytes from 216.58.209.131: seq=2 ttl=49 time=147.613 ms
--- www.google.de ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 128.030/134.752/147.613 ms
FB7490_0650#

Test des VPN-Tunnels

Code:

FB7490_0650# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
^C
--- 192.168.0.1 ping statistics ---
[COLOR="#FF0000"]6 packets transmitted, 0 packets received, 100% packet loss
[/COLOR]FB7490_0650#

FB6340-06.04:/var/tmp/ike.log

Code:

VPN avmike
-------
-rw-r--r--    1 root     root          8856 Jan  6 20:44 /var/tmp/ike.log
-rw-r--r--    1 root     root         20566 Jan  6 18:57 /var/tmp/ike.old
2016-01-06 11:13:27 avmike:< add(appl=dsld,cname=CT_LAN_to_FB7490,localip=109.xxx.yyy.zzz, remoteip=0.0.0.0, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2016-01-06 11:13:27 avmike:new neighbour CT_LAN_to_FB7490:  dynamic  nat_t
2016-01-06 11:24:48 avmike:mainmode CT_LAN_to_FB7490: selected lifetime: 3600 sec(no notify)
2016-01-06 11:24:48 avmike:CT_LAN_to_FB7490 remote peer supported XAUTH
2016-01-06 11:24:48 avmike:CT_LAN_to_FB7490 remote peer supported DPD
2016-01-06 11:24:48 avmike:CT_LAN_to_FB7490 remote peer supported NAT-T RFC 3947
2016-01-06 11:24:49 avmike:mainmode CT_LAN_to_FB7490: add SA 1
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: Warning: source changed from 0.0.0.0:500 to 109.43.2.36:33608
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: switching to NAT-T (Responder)
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: embedded inital contact message received
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: Phase 1 ready
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: current=0.0.0.0 new=109.43.2.36:33608
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: no valid sa, reseting initialcontactdone flag
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: remote is behind a nat
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: start waiting connections
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: NO waiting connections
2016-01-06 11:24:49 avmike:CT_LAN_to_FB7490: inital contact message received
2016-01-06 11:24:50 avmike:CT_LAN_to_FB7490: Phase 2 ready
2016-01-06 11:24:50 avmike:< cb_sa_created(name=CT_LAN_to_FB7490,id=1,...,flags=0x00022003)
2016-01-06 11:24:50 avmike:CT_LAN_to_FB7490: start waiting connections
2016-01-06 11:24:50 avmike:CT_LAN_to_FB7490: NO waiting connections
2016-01-06 11:30:26 avmike:mainmode CT_LAN_to_FB7490: selected lifetime: 3600 sec(no notify)
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490 remote peer supported XAUTH
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490 remote peer supported DPD
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490 remote peer supported NAT-T RFC 3947
2016-01-06 11:30:26 avmike:mainmode CT_LAN_to_FB7490: add SA 2
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: Warning: source changed from 109.43.2.36:33608 to 109.43.1.144:36085
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: switching to NAT-T (Responder)
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: embedded inital contact message received
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: inital contact message with address change
2016-01-06 11:30:26 avmike:mainmode CT_LAN_to_FB7490: del SA 1
2016-01-06 11:30:26 avmike:< cb_sa_deleted(name=CT_LAN_to_FB7490,id=1,what=3)
2016-01-06 11:30:26 avmike:FreeIPsecSA: spi=52ca5c6d		protocol=3 iotype=1
2016-01-06 11:30:26 avmike:FreeIPsecSA: spi=28d6		protocol=4 iotype=1
2016-01-06 11:30:26 avmike:FreeIPsecSA: spi=4d6976ac		protocol=3 iotype=2
2016-01-06 11:30:26 avmike:FreeIPsecSA: spi=9794		protocol=4 iotype=2
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: Phase 1 ready
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: current=109.43.2.36:33608 new=109.43.1.144:36085
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: no valid sa, reseting initialcontactdone flag
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: remote is behind a nat
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: start waiting connections
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: NO waiting connections
2016-01-06 11:30:26 avmike:CT_LAN_to_FB7490: inital contact message received
2016-01-06 11:30:27 avmike:CT_LAN_to_FB7490: Phase 2 ready
2016-01-06 11:30:27 avmike:< cb_sa_created(name=CT_LAN_to_FB7490,id=2,...,flags=0x00022003)
2016-01-06 11:30:27 avmike:CT_LAN_to_FB7490: start waiting connections
2016-01-06 11:30:27 avmike:CT_LAN_to_FB7490: NO waiting connections
#
2016-01-06 20:01:16 avmike:mainmode CT_LAN_to_FB7490: selected lifetime: 3600 sec(no notify)
2016-01-06 20:01:16 avmike:CT_LAN_to_FB7490 remote peer supported XAUTH
2016-01-06 20:01:16 avmike:CT_LAN_to_FB7490 remote peer supported DPD
2016-01-06 20:01:16 avmike:CT_LAN_to_FB7490 remote peer supported NAT-T RFC 3947
2016-01-06 20:01:17 avmike:mainmode CT_LAN_to_FB7490: add SA 18
2016-01-06 20:01:17 avmike:CT_LAN_to_FB7490: Phase 1 ready
2016-01-06 20:01:17 avmike:CT_LAN_to_FB7490: current=109.43.0.234:34202 new=109.43.0.234:34202
2016-01-06 20:01:17 avmike:CT_LAN_to_FB7490: local is behind a nat
2016-01-06 20:01:17 avmike:CT_LAN_to_FB7490: remote is behind a nat
2016-01-06 20:01:17 avmike:CT_LAN_to_FB7490: start waiting connections
2016-01-06 20:01:17 avmike:CT_LAN_to_FB7490: NO waiting connections
2016-01-06 20:01:18 avmike:CT_LAN_to_FB7490: Phase 2 ready
2016-01-06 20:01:18 avmike:< cb_sa_created(name=CT_LAN_to_FB7490,id=13,...,flags=0x00032003)
2016-01-06 20:01:18 avmike:CT_LAN_to_FB7490: start waiting connections
2016-01-06 20:01:18 avmike:CT_LAN_to_FB7490: NO waiting connections
2016-01-06 20:01:28 avmike:>>>4500 nat-t-keepalive[109.43.0.234:34202]
2016-01-06 20:06:49 avmike:FreeIPsecSA: spi=1efe8339		protocol=3 iotype=1
2016-01-06 20:06:49 avmike:FreeIPsecSA: spi=2fa4		protocol=4 iotype=1
2016-01-06 20:06:49 avmike:FreeIPsecSA: spi=881ef0e		protocol=3 iotype=2
2016-01-06 20:06:49 avmike:FreeIPsecSA: spi=77bb		protocol=4 iotype=2
2016-01-06 20:06:49 avmike:FreeIPsecSA: spi=eaa5b035		protocol=3 iotype=1
2016-01-06 20:06:49 avmike:FreeIPsecSA: spi=3b6b		protocol=4 iotype=1
2016-01-06 20:06:49 avmike:FreeIPsecSA: spi=90c7fae5		protocol=3 iotype=2
2016-01-06 20:06:49 avmike:FreeIPsecSA: spi=7827		protocol=4 iotype=2
2016-01-06 20:06:49 avmike:mainmode CT_LAN_to_FB7490: del SA 18
2016-01-06 20:06:49 avmike:mainmode CT_LAN_to_FB7490: del SA 17
2016-01-06 20:07:20 avmike:CT_LAN_to_FB7490: Phase 1 failed (initiator): IKE-Error 0x2027
2016-01-06 20:07:20 avmike:< cb_sa_create_failed(name=CT_LAN_to_FB7490,reason=IKE-Error 0x2027)
2016-01-06 20:07:50 avmike:CT_LAN_to_FB7490: Phase 1 failed (initiator): IKE-Error 0x2027
2016-01-06 20:07:50 avmike:< cb_sa_create_failed(name=CT_LAN_to_FB7490,reason=IKE-Error 0x2027)
2016-01-06 20:40:10 avmike:CT_LAN_to_FB7490: Phase 1 failed (initiator): IKE-Error 0x2027
2016-01-06 20:40:10 avmike:< cb_sa_create_failed(name=CT_LAN_to_FB7490,reason=IKE-Error 0x2027)
2016-01-06 20:41:14 avmike:CT_LAN_to_FB7490: Phase 1 failed (initiator): IKE-Error 0x2027
2016-01-06 20:41:14 avmike:< cb_sa_create_failed(name=CT_LAN_to_FB7490,reason=IKE-Error 0x2027)
2016-01-06 20:44:27 avmike:mainmode CT_LAN_to_FB7490: selected lifetime: 3600 sec(no notify)
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490 remote peer supported XAUTH
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490 remote peer supported DPD
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490 remote peer supported NAT-T RFC 3947
2016-01-06 20:44:27 avmike:mainmode CT_LAN_to_FB7490: add SA 19
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490: Warning: source changed from 109.43.0.234:500 to 109.43.0.234:34344
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490: switching to NAT-T (Responder)
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490: embedded inital contact message received
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490: Phase 1 ready
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490: current=109.43.0.234 new=109.43.0.234:34344
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490: remote is behind a nat
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490: start waiting connections
2016-01-06 20:44:27 avmike:CT_LAN_to_FB7490: NO waiting connections
2016-01-06 20:44:28 avmike:CT_LAN_to_FB7490: Phase 2 ready
2016-01-06 20:44:28 avmike:< cb_sa_created(name=CT_LAN_to_FB7490,id=14,...,flags=0x00022003)
2016-01-06 20:44:28 avmike:CT_LAN_to_FB7490: start waiting connections
2016-01-06 20:44:28 avmike:CT_LAN_to_FB7490: NO waiting connections

u.U. liegt hier SA Rekeying Problem vor ?

Was ist hier zu tun ?
wie kann das Problem gelöst werden ?

Gruß Shirocco88

PS: Hinweis: die IP-Adressen "109.43.2.36, 109.43.1.144, 109.43.0.234" gehören zum Mobilfunk-Device@FB7490.

PeterPawn · 6 Jan 2016

Hier beißen sich m.E. die unterschiedlichen Zeitpunkte der Erneuerung einer SA (54 Minuten bei der 7490, 60 Minuten bei der 6340 mit der älteren Firmware).

Vielleicht bringt in der 6340 ja "always_renew" andere Ergebnisse als die von mir beschriebenen und ich verstehe auch nicht so richtig, warum Du die auf beiden Seiten unterschiedlich einstellst.

Jedenfalls verstehen sich wohl beide Boxen auch nach dem Versuch der 7490, nach 54 Minuten eine neue SA auszuhandeln (20:01:17 ist das abgeschlossen, 20:01:20 funktioniert dann angeblich irgendein P1-Kontakt mit der 7490 als Initiator nicht) erst einmal noch so lange, bis die frühere SA um 20:07:16 in der 7490 dann abgeräumt wird, nachdem sie ihre "lifetime" von 3600 Sekunden (seit 19:07:16) erreicht hat. Also hat wohl das Einrichten der zweiten parallelen SA auf mindestens einer der Boxen gar nicht richtig funktioniert oder sie wurde wegen einer Fehlerbedingung (s. 20:01:20) gleich wieder mit abgeräumt.

Jedenfalls wirft dann auch die 6340 um 20:06:49 beide bei ihr eingerichteten SAs weg (neben der älteren SA 17 auch die SA 18, die sie erst um 20:01:17 eingerichtet hatte) und versucht dann irgendwie ihrerseits als Initiator (20:07:20) eine Verbindung aufzubauen. Ich weiß zwar nicht, wie das überhaupt funktionieren soll ohne IP-Adresse des Peers, aber vermutlich nimmt der (alte) avmike da einfach die letzte IP-Adresse des Peers. Es kommt ja auch erwartungsgemäß ein Timeout, weil die Pakete der 6340 ziemlich sicher am CGN beim Provider versanden. Die eingehende Verbindung kommt ja für die 6340 auch nicht von Port 4500, sondern von irgendwas über 34000 (der Teil fehlt ja im Protokoll der 7490, aber frühere Ports sind ja noch zu sehen davor) und der wird früher oder später vom CGN auch abgeräumt, wenn die 7490 dort keinen weiteren Traffic sendet, denn aus ihrer Sicht dürfte die neue Verbindung (die vom Port 34202 kommt) aktiv sein. Wohin die 6340 jetzt ihrerseits gesendet hat, was dann um 20:07:20 zur "Phase 1 failed"-Nachricht führt, kann man leider nicht sehen, aber es würde mich schon arg wundern, wenn das tatsächlich der Port 34202 wäre und nur der ist "durchgestellt" zum Port 4500 der 7490 am CGN des Providers.

Das ist aber auch nichts anderes als eine Beschreibung dessen, was man m.E. aus dem Protokoll ersehen kann ... für eine mögliche Behebung würde ich erst mal das "always_renew" in der 7490 auch noch abschalten (das sollte vom Keepalive mit erledigt werden, wenn es keine gültige SA gibt) und dann zumindest für einen Versuch einfach mal wieder auf die "normale Konfiguration" mit einer "localid" und einer "remoteid" auf beiden Seiten gehen.

Da offenbar die 7490 da trotz erfolgreichem Abschluß der Phase2 mit dem Aufruf der (anzunehmenden) Callback-Funktion "cb_sa_created" im Anschluß Probleme damit hat, die P1 als abgeschlossen anzusehen, würde ich das mit "ohne localid" in der 6340 noch nicht als "geht" abhaken.

Beim "aggressive mode" wird ja die Identität beider Seiten nur über die IDs "abgesichert" (das ist eigentlich ein Euphemismus, weil eben die Identität im "aggressive mode" gar nicht wirklich sichergestellt ist, da verläßt man sich auf die Sicherheit des gemeinsamen Geheimnisses "PSK") und ich würde es nicht für ausgeschlossen halten, daß die 7490 - bei praktisch zwei gleichzeitig existierenden Verbindungen zur 6340 in der Phase der Etablierung der zweiten SA - einfach eine Antwort der 6340 nicht richtig zuordnen kann, weil deren "localid" (quasi der Absender) nicht mit den Erwartungen der 7490 übereinstimmt.

Beim Aufbau der ersten SA könnte das keine wirkliche Rolle spielen, weil die 7490 nur eine einzige Verbindung unterhält und damit vielleicht gar nicht nach der richtigen sucht (ähnlich wie ich das bei der Suche nach dem PSK vermutete, als Du noch etwas von "keine localid" geschrieben hattest). Irgendwelche vorherigen Abfragen eines Counters, ob da mehr als ein Objekt existiert oder nicht, sind ja nicht so selten, wenn man etwas sparen will/muß.

Muß auch nicht stimmen, aber meiner Verwunderung über Deine Konstruktion habe ich schon oben Ausdruck verliehen ... das Argument "einfacher bei einem Mesh-Netzwerk" habe ich ohnehin nicht verstanden, aber ich wollte nicht OT um des Kaisers Bart streiten.

Shirocco88 · 6 Jan 2016

@PeterPawn:
Vielen Dank für die Analyse und Feedback,
werde morgen Abend bzw. am WE die angesprochene "Konsolidierung" der Umgebung durchführen;
"always_renew" und wenn möglich auch "localid" @FB6340, sowie Tests zum Thema SA-Rekeying durchführen;

melde mich sobald ich diskussionsfähige Ergebnisse habe.

Gruß Shirocco88

Shirocco88 · 24 Jan 2016

Hallo PeterPawn und alle VPN-Interessierte,
anbei Recherergebnisse zu Problembild: "nach ca. 1h funktioniert VPN-Verbindung nicht mehr", siehe #27

ich habe die Konsolidierungen/Problembehebungen der VPN-Konfiguration - wie PeterPawn vorgeschlagen hat - durchgeführt:
1.) Problembehebung allcfgconf #25 durchgeführt
allxxxx_06.03 @FB7490 installiert und Ergebnisse in #25 aktualisiert
2.) Dokumentation zu Fehlerbild "unknown remote peer" in /var/tmp/ike.log in #21 eingepflegt
3.) Konfiguation @FB7490 angepasst
Konsolidierung: vpn.cfg von always_renew=yes auf always_renew=no zurückgestellt

"always_renew" würde ich erst einmal auslassen ... AVM bastelt da m.E. immer noch am 54-Minuten-Problem herum und ich würde eher darauf tippen (aber immer noch ohne Kenntnis der

Quellen), daß ohne "always_renew" die alte Verbindung abgebaut wird und dann mit dem nächsten Keepalive-Paket eine neue aufgebaut werden kann. Wenn das "always_renew" zu unterschiedlichen

SAs auf beiden Seiten führt, "hängt" die Verbindung ... die dann ausbleibende Keepalive-Antwort führt ja eben nicht (bisher jedenfalls) zu einem neuen Anlauf.

somit ergibt sich folgende Ausgangskonfiguration:
FB6340, FW 06.04, Public-IPv4, kein CGN/DS-Lite
==> LAN-IP: 192.168.0.1, Netzwerk: 192.168.0.0, Netzmask: 255.255.255.0
==> DynDNS-Registrierung "xxxxx.ddns.net" für Public-IP der FB6340 wird von Raspberry-PI im LAN der FB6340 durchgeführt
==> keine MyFritz-Registrierung

FB7490, FB 06.50, Internet-Zugang mit USB-Tethering Mobilfunk-Stick, NAT44-Config (Vodafone-SIM, UDP-Port 500 und UDP-Port 4500 sind jeweils ausgehend freigeschalten)
==> USB-Tethering, kein Portforwarding bei vorgeschaltenem NAT-Router aktiv
==> LAN-IP: 192.168.0.1, Netzwerk: 192.168.0.0, Netzmask: 255.255.255.0
==> WAN-IP: 192.168.8.100, DHCP-Client
==> MyFritz-Registrierung "xxxxx.myfritz.net"
==> keine DynDNS Registrierung
==> Fritzbox wurde vor Beginn der Tests auf Werkseinstellungen zurückgesetzt, FW tweaked with PeterPawn's modfs

Mobilfunk-Router (Huawei-LTE-Stick, USB-Tethering)
Router wurde vor Beginn der Tests auf Werkseinstellungen zurückgesetzt
==> DynDNS-Config: keine
==> Port-Forwarding: keine
==> Exposed-Host nicht eingerichtet
==> WAN-IP 109.xxx.yyy.zzz Vodafone
==> NAT-Settings Cone=on, Symmetric=off
==> Firewall-Settings
The IP address filter and WAN port ping functions are only available when the firewall is enabled.
X Enable firewall
X Disable WAN port ping

FB6340-ipv4.cfg:

Code:

vpncfg {
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "xxxxx.myfritz.net";
                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 = "xxxxx.myfritz.net";
                keepalive_ip = 0.0.0.0;
                remoteid {
                        fqdn = "xxxxx.myfritz.net";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "SECRET";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.178.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}

// EOF

Hinweis: Konfig wurde per Web-IF erstellt, da es war nicht möglich eine funktionierende VPN-Verbindung per VPN-Importer ("firmwarecfg") zu erstellen.

FB7490-NAT44.cfg:

Code:

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "CT_LAN_to_fb6340";
                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 = "xxxxx.ddns.net";
                keepalive_ip = 192.168.0.1;
                localid {
                        fqdn = "xxxxx.myfritz.net";
                }
                remoteid {
                        fqdn = "xxxxx.ddns.net";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "SECRET";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.0.0 255.255.255.0",
                             "permit ip any 192.168.1.0 255.255.255.0";
                app_id = 0;
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}

// EOF

Problemanalyse ergab:

Fehlerbild 1:
Raspberry-PI kann den DynDNS-Namen nicht auflösen

Code:

root@raspberry-pi2:/# nslookup xxxx.myfritz.net
Server:    192.168.0.1
Address 1: 192.168.0.1 fritz.box
nslookup: can't resolve 'xxxx.myfritz.net'
root@raspberry-pi2:/#

Ursache:
der vorgeschaltete NAT4-Configuration (Mobilfunk-Router, Huawei-USB-Stick) stellt der FB7490 nur eine WAN-IP 192.168.8.100 aus RFC1918 Adressbereich bereit.
Diese IP-Adresse kann ohne Probleme bei MyFRITZ-DDNS Service registriert werden. Leider ist dies "sinnfrei", da diese IP-Adresse von FB6340 nicht ins Internet geroutet werden kann;
ferner funktioniert die Namensauflösung aus FB6340-LAN nicht, da hier der DNS-Rebind-Schutz aktiv ist http://avm.de/service/fritzbox/fritzbox-6340-

cable/wissensdatenbank/publication/show/663_DNS-Aufloesung-privater-IP-Adressen-nicht-moeglich/.
Glücklicherweise startet die FB6340 von sich aus (wg. keepalive_ip = 0.0.0.0

keinen VPN-Verbindungsaufbau.

Durchgeführte Maßnahme: Umstellung von MyFRITZ-DDNS auf DynDNS-Service @FB7490.

Fehlerbild 2:
"nach ca. 1h funktioniert VPN-Verbindung nicht mehr"

Code:

FB7490_NAT44_06.50: Eventlog:
10.01.16     12:23:36    VPN-Verbindung zu CT_LAN_to_fb6340 wurde erfolgreich hergestellt.
10.01.16     12:23:29    VPN-Fehler: CT_LAN_to_fb6340, IKE-Error 0x203d
10.01.16     12:23:29    VPN-Verbindung zu CT_LAN_to_fb6340 wurde getrennt. Ursache: 9 Dead Peer Detection

Code:

FB6340_ipv4_06.04: Eventlog:
10.01.16        16:06:14        Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.0.99.
10.01.16        16:00:10        VPN-Verbindung zu CT-LAN-to-FB7490.ddns.net wurde erfolgreich hergestellt.
10.01.16        15:58:24        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:56:08        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:53:53        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:51:38        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:49:23        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:47:08        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:44:53        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:42:38        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:40:23        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:38:08        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:35:52        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:33:37        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:31:13        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:30:30        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:29:59        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:29:07        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:26:52        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:24:36        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:22:21        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:20:06        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:19:22        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:18:51        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:17:54        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:17:23        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:16:52        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:15:35        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:13:30        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        15:12:55        VPN-Verbindung zu CT-LAN-to-FB7490.ddns.net wurde getrennt. Ursache: 9 Dead Peer Detection
#
VPN-Verbindung funktioniert 1h lang problemlos;
#
10.01.16        14:12:02        VPN-Verbindung zu CT-LAN-to-FB7490.ddns.net wurde erfolgreich hergestellt.
10.01.16        14:10:15        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        14:08:11        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        14:07:21        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        14:06:50        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        14:05:14        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        14:03:04        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        14:00:54        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:58:43        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:56:33        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:54:23        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:52:13        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:50:03        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:47:53        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:45:43        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:43:33        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:41:23        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:39:13        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:37:03        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:34:53        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:32:43        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:30:33        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:28:23        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:26:13        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:24:03        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:22:58        VPN-Fehler: CT-LAN-to-FB7490.ddns.net, IKE-Error 0x2027
10.01.16        13:22:10        VPN-Verbindung zu CT-LAN-to-FB7490.ddns.net wurde getrennt. Ursache: 9 Dead Peer Detection
10.01.16        12:23:35        VPN-Verbindung zu CT-LAN-to-FB7490.ddns.net wurde erfolgreich hergestellt.

Ursache: so wie es aussieht möchte die SAs nach ca. 1h neu aufbauen, hier gibt es Probleme,
ich denke es hängt mit fehlendem localid zusammen

Lösung:
Cronjob @FB7490 zur Registrierung der Public-IPv4 eingerichtet

Code:

SNIP
# WAN-IP des Mobilfunk-Routers ermitteln
/usr/bin/wget -O /var/media/ftp/tmp/dnsomatic.newip [URL]http://myip.dnsomatic.com/[/URL]
OLDIP=`cat /var/media/ftp/tmp/dnsomatic.myip`
NEWIP=`cat /var/media/ftp/tmp/dnsomatic.newip`
SNIP
# Bei IP-Änderung den DynDNS-Record aktualisieren
if [ "$NEWIP" = "$OLDIP" ]
then
     echo "$WJ_DATUM: IP $NEWIP is still the same, not updating"
else
     /usr/bin/wget -q -O /var/media/ftp/tmp/dyndns.no-ip.out https://user:[email protected]/nic/update?hostname=CT-LAN-to-FB7490.ddns.net&myip=$NEWIP
fi

Anschließend hat nach Deaktivieren/Aktivieren der beiden FB7490-VPN-Verbindung funktioniert.
Inzwischen läuft die VPN-Verbindung seit 16.01. ohne Probleme

konstruktives Feedback/Verbesserungsvorschläge sind willkommen.

Gruß Shirocco88

Languages

Suche

Languages

Suche

[Problem] 6820 LTE - Zugriff via MyFritz oder DynDns-Anbieter nicht möglich

Shirocco88

Aktives Mitglied

PeterPawn

IPPF-Urgestein

Shirocco88

Aktives Mitglied

PeterPawn

IPPF-Urgestein

Shirocco88

Aktives Mitglied

PeterPawn

IPPF-Urgestein

Shirocco88

Aktives Mitglied

PeterPawn

IPPF-Urgestein

Shirocco88

Aktives Mitglied

Shirocco88

Aktives Mitglied

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums