[Gelöst] VPN - Einstellungs Maske LAN<->LAN bei FB7490 u. UMTS-FB`s

Micha0815

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
5,344
Punkte für Reaktionen
467
Punkte
83
Da es dort störte, hierhinkopiert und angeraten
@Micha0815:
VPN-Problem gelöst oder aufgegeben oder habe ich bloß den gesonderten Thread überlesen?

Sorry ich hatte etwas Stress/ zu wenig Zeit.

Ich möchte eine LAN-LAN-Verbindung von einer UMTS-FB (Ich habe 2 Modelle zur Auswahl FB7240 FW:7240_7270_v3_05.53-freetz-devel-11807.en und eine FB7390 FW: 7390_LabBETA.AnnexB.84.06.36-31680 jeweils zu Testzwecken mit einem Huawei E3131-1&1SIM)

Die zu verbindende -wohin sich die UMTS-FBs verbinden sollen- ist eine 7490 FW: hier aus dem Thread 113.06.036.-31687 an VDSL50.

Diese FB7490 ist eine Produktiv-Box, an der kein modfs/Telnet installed ist. -Ich habe darauf nur WLAN-Zugriff und kann diese nicht allzuoft physisch bearbeiten (POR, Recovery, Telnet.tar etc.) und zudem hängen noch 2 Produktiv-FBs dahinter mit Tel. und DECT200 was im Verbund z.Zt. problemlos läuft.

Meine Frage. Die neueren Labors bieten ja ein Menue zum Erstellen einer LAN-LAN-Verbindung an.

Hier mal ein Bsp. aus der FB7490 mit IP 192.168.177.1
Anhang anzeigen 84347

Aus der Export-Datei erkenne ich folgende vpn.cfg
Code:
vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "Micha0815";
                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 = 192.168.177.201;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        user_fqdn = "$$$$...AAA";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "LT8h/all/all/all";
                keytype = connkeytype_pre_shared;
                key = "$$$$...LX";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.177.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.177.201;
                }
                phase2ss = "LT8h/esp-all-all/ah-none/comp-all/pfs";
                accesslist = 
                             "permit ip 192.168.177.0 255.255.255.0 192.168.177.201 255.255.255.255", 
                             "permit ip any 192.168.177.201 255.255.255.255";
                app_id = 0;
        } {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "https://100.66.102.188";
                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 = "https://100.66.102.188";
                keepalive_ip = 0.0.0.0;
                localid {
                        fqdn = "$$$$...5B";
                }
                remoteid {
                        fqdn = "$$$$...5B";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "$$$$.....AAA";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.177.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.183.2;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.183.2 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";
}

Der VPN-User Micha0815 kann sich von aussen verbinden.

Das Pendant der UMTS-FB7390 (ich hatte der Verbindung oben mal den Namen einer IP der UMTS-Verbindung gegeben) mit der IP 192.168.183.2

Code:
vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "https://xxxxxxxxx.spdns.de";
                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 = "https://xxxxxx.spdns.de";
                keepalive_ip = 192.168.177.2;
                remoteid {
                        fqdn = "$$$$...QA";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "$$$$...AA";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.183.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.177.1;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.177.1 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";
}

Mit den verschlüsselten Sequenzen fqdn und key weiss ich nicht umzugehen? Nach meiner Erinnerung kann man diese auch im Klartext in einer editierten vpn.cfg eingeben und über den Import werden diese dann über die jeweilige FB selbst wieder verschlüsselt? wobei mir zusätzlich unklar ist -eine *.export wird ja nochmals über ein Passwort verschlüsselt- was ggfs. 1:1 als verschlüsselte Sequenz kopierbar wäre?

Was mir auffällt, dass die vpn.cfg s eine "Boxuser_id = 0" innehaben, die ich in älteren cfgs so nicht erkenne.

Irgendwie mag die FB7490 keine VPN-Verbindung annehmen. Ich weiss, dass die UMTS-Box diese aufbauen muss und nicht umgekehrt.

Aus der 7490-support-datei lese ich, dass es kein ike.old gibt.

Da ich mir nicht sicher bin, ob es an meinem Unvermögen liegt, oder die aktuelle 7490Labor -auf die stock möchte ich aus eingangs genannten Gründen nicht zurück- dafür verantwortlich zeichnet, habe ich halt hier gefragt ;)

LG und ich hoffe, es ist nicht zuviel "prosa" (@PeterPawn)
 
Zuletzt bearbeitet:
VPN-Konfigurationen können inzwischen auch einzeln (nicht mehr nur eine vpn.cfg, die alle Verbindungen gleichzeitig enthält) importiert werden. Damit kann man aus einem Auszug der vpn.cfg in einem export-File seine eigene kleine Textdatei bauen, die man dann ändert und jedesmal erneut importiert. Solange der Eintrag unter "name" mit einer vorhandenen Verbindung übereinstimmt, wird diese Verbindung beim Import ersetzt.

Damit kann man dann problemlos anstelle der verschlüsselten Werte auch die Klartext-Daten in so einer zu importierenden Datei angeben - die Verschlüsselung übernimmt die Box selbst beim Import. Ich rede hier auch nur von einer VPN-Konfiguration, die über den Punkt beim VPN-Assistenten importiert wird und nicht unter "System ...".

Die Angabe von "boxuser_id" ist nur bei VPN-Verbindungen für Benutzer relevant, da wird die Verbindung zum Benutzerkonto in der FRITZ!Box hergestellt.

Eine endgültige VPN-Konfiguration der 7490 ist hier mit dem GUI-Assistenten nicht möglich (wenn AVM da nicht etwas geändert haben sollte, damit nicht mehr immer automatisch ein "remotehostname" erzeugt wird), denn die Box kann keine "passiven VPN-Verbindungen" konfigurieren. Versucht die 7490 aber ihrerseits den Aufbau einer Verbindung (weil sie "remotehostname" oder "remoteip" konfiguriert hat), funktioniert die VPN-Verbindung ebenfalls nicht (zumindest war es bisher so). Man kann aber den GUI-Assistenten benutzen, um sich ein Template für die Verbindung erstellen zu lassen und dann kopiert man sich diese Schablone aus einer export-Datei in den Editor und paßt sie dort an. Die wenigen verschlüsselten Angaben ersetzt man dann wieder mit den Klartext-Daten.

Bei "key" kommt eben ein ausreichend langer PSK als Zeichenkette hinein, der muß auf beiden Seiten identisch sein. Eine 32-Byte-Zeichenkette aus irgendeinem Generator ist dabei keine schlechte Wahl (solange der Generator taugt).

Bei "fqdn" steht ein "fully-qualified domain name", das ist - solange es unter "localid" oder "remoteid" steht - zunächst mal nur ein Name, der sollte zwar dem Aufbau nach einem Domain-Namen entsprechen, muß aber nicht erreichbar oder auch nur in irgendeinem DNS-Server definiert sein. An diesen beiden Stellen muß nur auf jeder Seite die Angabe für die eigene und die Gegenseite stimmen (über Kreuz), damit der richtige VPN-Eintrag gefunden werden kann.

Über "remoteip" oder "remotehostname" entscheidet der avmike (offensichtlich, ist natürlich alles nur aus dem Verhalten geschlossen, Quellen kenne ich auch nicht), ob er selbst aktiv eine Verbindung zur Gegenstelle aufbauen soll oder nicht ... der Zeitpunkt des Verbindungsaufbaus (ständig oder "on demand") wird damit noch nicht beeinflußt. Braucht man also einen "passiven Responder", läßt man einfach beide Angaben weg in der lokalen Konfiguration. Bei Dir darf also in der 7490 keiner der beiden Werte gesetzt werden, das unterstützt das AVM-GUI meines Wissens bisher nicht (letzte Labor nicht getestet, stand aber auch nichts in den Changelogs). Also braucht es auf dieser Seite eine Datei für den Import.

Die entscheidende Einstellung für "on demand" oder "ständig verbunden" ist dann "keepalive_ip". Der AVM-Assistent setzt dort (wenn die Checkbox angehakt ist) die erste Adresse aus dem entfernten Segment ein (also 192.168.177.2, wenn man beim Netz fälschlicherweise 192.168.177.1/24 konfiguriert). Ob diese Adresse auf der Gegenseite überhaupt existiert, interessiert auch nicht wirklich ... das Paket an diese Adresse führt zum Aufbau der VPN-Verbindung (wenn diese Adresse in die Range in der "accesslist" fällt), auch wenn es nie eine Antwort gibt.

Ansonsten hast Du bei der Konfiguration vermutlich anstelle der Netzwerk-Segmente (192.168.177.0 mit Maske 255.255.255.0 bei der 7490, 192.168.183.0/24 bei der UMTS-Box) irgendwelche Adressen aus diesen Segmenten angegeben, die Angaben zum jeweils entfernten Subnetz enden auf "0", dann stimmt das auch wieder.

Zusammengefaßt:

  1. beide Konfigurationen beim Netzwerk korrigieren (dann stimmt alles andere, wie z.B. die "accesslist", auch automatisch wieder)
  2. Einstellungen aus der 7490 exportieren
  3. dort aus der vpn.cfg den richtigen Abschnitt kopieren (bzw. die anderen einfach löschen)
  4. verschlüsselte Angaben durch Klartext ersetzen
  5. "remotehostname" und "keepalive_ip" (das zweite nur für "schöner wohnen") löschen und dann
  6. diese einzelne Verbindung importieren

Dann sollte das auch klappen.
 
Zuletzt bearbeitet:
VPN-Konfigurationen können inzwischen auch einzeln (nicht mehr nur eine vpn.cfg, die alle Verbindungen gleichzeitig enthält) importiert werden. Damit kann man aus einem Auszug der vpn.cfg in einem export-File seine eigene kleine Textdatei bauen, die man dann ändert und jedesmal erneut importiert. Solange der Eintrag unter "name" mit einer vorhandenen Verbindung übereinstimmt, wird diese Verbindung beim Import ersetzt.

Allerdings müssen die FBs neu gestartet werden, was ich bei einer Produktivbox / Gebinde tagsüber nicht allzuoft machen kann, da es sonst massiv Ärger gibt ;)


  1. beide Konfigurationen beim Netzwerk korrigieren (dann stimmt alles andere, wie z.B. die "accesslist", auch automatisch wieder)
  2. Einstellungen aus der 7490 exportieren
  3. dort aus der vpn.cfg den richtigen Abschnitt kopieren (bzw. die anderen einfach löschen)
  4. verschlüsselte Angaben durch Klartext ersetzen
  5. "remotehostname" und "keepalive_ip" (das zweite nur für "schöner wohnen") löschen und dann
  6. diese einzelne Verbindung importieren

Dann sollte das auch klappen.

Das habe ich sicherlich schon mit zig Varianten / cfgs probiert. Die FB7490 stellt sich stur?

Mit der UMTS-7390 habe ich eine funktionierende cfg zu meiner FB7240 (@Home1) importiert um auszuschliessen, dass die 1&1-SIM blockiert, was auf Anhieb klappt.

Als Vorlage aus meiner FB7240@Home1 die cfg angepasst (IP-Range) und in die 7490 importiert? NADA.

Zu später Stunde werde ich nochmals Testen. Die FB7490 und nachgelagerte 7490-WLAN-Repeater-Box brauchen ca. 7-10 Minuten, bis ich wieder Zugriff habe.

LG und Danke für die Geduld.
 
Allerdings müssen die FBs neu gestartet werden, was ich bei einer Produktivbox / Gebinde tagsüber nicht allzuoft machen kann, da es sonst massiv Ärger gibt
Das ist so nicht ganz korrekt - bei neuerer Firmware ... es werden allerdings andere bereits aufgebaute VPN-Verbindungen ebenfalls neu gestartet, wenn man eine Verbindung erfolgreich importiert.

Die einzige Stelle, wo ein Neustart der Box obligatorisch ist (und manuell ausgeführt werden muß), ist eine Änderung der "ipsecbridges" in der ar7.cfg - wenn man also per GUI dedizierte LAN-Ports für eine VPN-Verbindung zuweist oder diese Zuweisung ändert/aufhebt.

Das habe ich sicherlich schon mit zig Varianten / cfgs probiert. Die FB7490 stellt sich stur?
Mit den gezeigten Konfigurationen ist das aber logisch, wenn die 7490 nicht reagiert ... und an der Stelle gibt es tatsächlich nicht zig funktionierende Varianten, sondern höchstens eine Handvoll.

Die 7490 weiß schlicht nicht, was die UMTS-Box von ihr will, da die Identifikationen für P1 im "aggressive mode" schlicht nicht übereinstimmen.

M.W. protokolliert sie solche vergeblichen Versuche, wo noch nicht einmal die Gegenstelle identifiziert werden kann, auch nicht - das wäre ein wunderbarer "Angriff" auf das Eventlog von extern, wenn man da einfach Eintrag über Eintrag erzeugen kann und damit andere wichtige Nachrichten überschrieben werden im verwendeten "ring buffer".

EDIT: Man sollte allerdings tatsächlich nicht auf die Idee kommen, die VPN-Konfiguration einer FRITZ!Box (das meint die Gesamtheit aller dort vorhandenen Verbindungen) über eine VPN-Verbindung zu dieser Box mit dem GUI zu bearbeiten. Das führt ggf. schneller zum Verbindungsabbau, als man erwartet und die anschließende Prüfung, wie weit die Änderungen wirksam wurden, ist viel zu viel Aufwand. So etwas sollte man also über den HTTPS-Fernzugriff erledigen (notfalls nur dafür aktivieren und nach getaner Arbeit wieder abschalten).
 
Zuletzt bearbeitet:
Danke

und dann nenne mir doch bitte meinen Fehler? ich sehe langsam den Wald vor lauter Bäumen nicht mehr? und drehe mich wieder und wieder im Kreis :mad:

CFG-UMTS-7390 mit der IP 192.168.183.1 vor import.
Code:
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "test";
                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 = "https://xxx.spdns.de"; <die funktionierende dyndns der 7490>
                keepalive_ip = 192.168.177.1; <die IP der FB7490>
                localid {
                        fqdn = "";
                }
                remoteid {
                        fqdn = "https://xxx.spdns.de"; <siehe oben>
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "langer Key identisch zu siehe andere cfg";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.183.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.177.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.177.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";
}

Das Pendant in der FB7490 mit Ip192.168.177.1 vor import

Code:
vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "test2";
                boxuser_id = 0;
                always_renew = yes;
                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 = "";
                keepalive_ip = 192.168.183.2;
                localid {
                        fqdn = "https://xxx.spdns.de"; <dieselbe wie aus obiger cfg der 7390>
                }
                remoteid {
                        fqdn = "";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "identischer langer Key";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.177.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.183.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.183.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";
}

Ich hatte schon mit jeweils leeren fqdn`s versucht, den "key" = identisch im Klartext ... jeweils vor dem import.

Als ergänzenden Hinweis: Die FB7490 hört beim https-Fernzugriff auf einen anderen Nonstandard-Port.

Mir ist langsam die Lust vergangen, da der Aufwand in h einfach zu gross.

LG :heul::heul:
 
Du hast aber nicht etwa ernsthaft ein "https://" im Eintrag "remotehostname" bei der 7390, oder?

Die "keepalive_ip" in der 7490-Konfiguration gehört da ebenfalls nicht hin - auch wenn sie vermutlich unschädlich ist, aber was nicht da steht, muß man nicht lesen und kann man auch nicht auf einen falschen Wert setzen.

Und wenn Du mir dann noch verrätst, warum Du unbedingt bei der 7390 darauf bestehst, daß der FQDN "leer" sein soll? Ich hatte in #2 geschrieben, daß da etwas (beliebiges, solange es auf beiden Seiten dasselbe ist) hineingehört, was wie ein FQDN aussieht und dazu gehört nun mal keinesfalls ein Protokoll (wie bei Deiner Angabe "https://xxx.spdns.de", wo eben "https" das Protokoll und "xxx.spdns.de" der FQDN ist). Ein leerer Eintrag funktioniert m.W. tatsächlich auch ... spaßig wird das erst dann, wenn man zwei Verbindungen hat, denn die können dann nicht beide eine leere Angabe in "remoteid" bei der 7490 haben. Warum es also nicht gleich richtig machen? Daß der Name dort nicht existieren muß, steht ebenfalls in #2. Wenn die AVM-Firmware bei der Prüfung des Formats eines FQDN etwas schlampig ist (und damit jeder Quatsch darin funktioniert), steht das wieder auf einem anderen Blatt. Das Kardinalproblem hier wäre die Protokoll-Angabe in "remotehostname".

Nächste Schritte: "https://" überall raus, FQDN für die 7390 in beiden Konfigurationen rein und es sollte funktionieren.

Tut es das nicht, braucht es immer noch eine Fehlernachricht und ein IKE-Protokoll, zumindest auf der 7390 muß das selbst dann erstellt werden, wenn die 7490 überhaupt nicht gefunden werden kann.

Es ist unsinnig, immer nur zu raten ... im IKE-Log hätte auch bei dieser Konfiguration garantiert schon etwas gestanden, was darauf hingewiesen hätte, daß der Name der Gegenstelle (wegen des "https://") nicht aufgelöst werden kann.

Da gibt es auch eigentlich keine "Entschuldigung" für fehlende Protokolle/Fehlermeldungen ... man kennt zwar einige der beliebtesten Fehler, die die Leute immer wieder auf's Neue machen, aber an die Stelle von Raterei und langwierigen Begründungen, warum das denkbar wäre, könnte man bei vorhandenem Protokoll auch einfach die Feststellung "Das ist da und da falsch." setzen, wenn man es denn nur sehen (und damit sicher wissen) könnte.

Und so sehr ich solche "Maskierungen" in konkreten Konfigurationsdateien auch begrüße ... den Teil mit dem "https://" in #1 habe ich gar nicht für voll genommen, da dort ja erkennbar maskiert wurde. Auf die Idee, daß da tatsächlich noch ein Protokoll wie in einer URL stehen könnte, bin ich gar nicht erst gekommen. Wie kommst Du eigentlich darauf? Wenn Du Dir nur eine einzige funktionierende VPN-Verbindung ansiehst, dürfte dort doch auch nichts von "https://" in "remotehostname" stehen.
 
Abgeändert und was sagt die FB7390
Code:
04.11.15
	19:30:34	Netzwerkgerät Name: Micha0815x64, MAC: B8:....hat sich erstmalig mit der FRITZ!Box verbunden.
04.11.15
	19:30:26	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20.
04.11.15
	19:28:19	Die FRITZ!Box-Einstellungen wurden über die Benutzeroberfläche geändert.
04.11.15
	19:28:14	VPN-Fehler: test, IKE-Error 0x2005 [3 Meldungen seit 04.11.15 19:28:05]
04.11.15
	19:28:02	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20.
04.11.15
	19:28:00	VPN-Fehler: test, IKE-Error 0x2005 [943 Meldungen seit 04.11.15 18:07:49]
04.11.15
	18:07:47	Der USB-Speicher 1003 enthält kein unterstütztes Dateisystem oder hat eine ungültige Partitionstabelle. (Das Gerät hat den folgenden Typ: 12d1:1506)
04.11.15
	18:07:44	VPN-Fehler: test, IKE-Error 0x2005 [4 Meldungen seit 04.11.15 18:07:31]
04.11.15
	18:07:26	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20.
04.11.15
	18:07:24	VPN-Fehler: test, IKE-Error 0x2005
04.11.15
	18:07:21	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20 gescheitert (ungültige Sitzungskennung). Zur Sicherheit werden alle noch gültigen Sitzungen zur IP-Adresse 192.168.183.20 beendet.
04.11.15
	18:07:19	VPN-Fehler: test, IKE-Error 0x2005 [2 Meldungen seit 04.11.15 18:07:14]
04.11.15
	18:07:14	Die Systemzeit wurde erfolgreich aktualisiert von Zeitserver 94.154.96.7.
04.11.15
	18:07:14	Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 100.xxx, DNS-Server: 139.7.30.126 und 139.7.30.125, Gateway: -
04.11.15
	18:07:06	UMTS-Modem initialisiert.


Die 7390 versucht es ja nur in der FB7490 sehe ich keinen "Versuch".

Sorry, wenn ich das VPN-Procedere inpunkto

Code:
                localid {
                        fqdn = "$$$$L4QD.......................................................";
                }
                remoteid {
                        fqdn = "$$$$1OVI4.......................................................................";
                }

nicht hinreichend erkenne, was dort jeweils vor Import drinstehen muss?

Ich kann halt nur "Rezepte befolgen" ... ;)

LG und trotzdem lieben Dank für Deine Mühe.

Hintergrund meiner vergeblichen Versuche ist eigentlich, dass ich die entfernte FB7240 @Home1 abschalten möchte und die FB7240@Home3, die ab+an wohl etwas zickt (Elkos,Netzteil,K3765HV ... u.U. auch "nur" das dortige Mobilfunknetz) durch eine FB7390+E3131ersetzen möchte, die ein Kanaren-Nachbar-dessen Flug am 7.11. geht- u.U. installieren kann.

Aus der Ferne habe ich exakt einen Versuch die FB7240 @Home3 (auf den Kanaren) umzukonfigurieren! Sonst muss ich dorthinfliegen ;)

Nachtrag: Ich könnte auch der FB7240 @Home1 eine andere dyndns verpassen und dem hiesigen FB-Verbund unter Abänderung der IP-Range+DYNDNS das umlenken nebst vpn-cfg-import ... das sollte dann 1:1 gehen? Nur hinter der Master7490 am VDSL sind dann etliche Umstrukturierungen notwendig, die ich mir ersparen möchte
 
Zuletzt bearbeitet:
Es gibt keinen Grund sich zu entschuldigen, nur dann, wenn Du nicht auf das "hörst", was man Dir schreibt.

Ich hätte gerne die resultierenden vpn.cfg-Dateien (für die betroffenen Verbindungen natürlich nur) in voller Schönheit mit nur minimalen Maskierungen. Den Key kannst Du - wenn es funktioniert - hinterher immer noch durch einen neuen ersetzen, der bleibt also, wie er ist. Wenn Du bei "fqdn" reale Namen eingetragen hast, dann kannst Du die nach dem Schema "home.mydomain.de" in "xxxx.yyyyyyy.de" verwandeln, ansonsten nichts ändern. Die verwendeten Subnetze kennen wir ohnehin schon, da bleibt es also bitte 1:1, wie es in der Box steht. EDIT: "remotehostname" bei der 7390 wie einen FQDN maskieren.

Dann noch die Supportdaten der 7390 auslesen und dort die ike.log (die gibt es, wenn die 7390 eine VPN-Verbindung aufbauen will) extrahiert.

Daß die 7490 ihrerseits nichts unternimmt und nur auf eine eingehende Verbindung von der 7390 wartet, ist ja gewollt ... kommt da nichts an, muß sie auch nichts protokollieren. Da würde erst ein Fehler in P2 auftauchen, wenn irgendwie bei der 7490 der Eindruck vorher entstanden ist, daß die Gegenstelle tatsächlich "eine Bekannte" sein könnte (dazu muß P1 aber erst einmal klappen).

In der Tat war 0x2005 irgendein häßlicher Fehler, der Code ist m.W. auch nirgendwo beschrieben ... aber in der ike.log kann man wenigstens im Ansatz sehen, was die Ursache sein könnte. Und den Neustart der 7390 zwischendrin nicht vergessen, die alten 943 Meldungen zu diesem Fehler braucht kein Mensch ... außerdem verdrängen sie die wichtigen Informationen aus den Protokollen.

ToDo:

- Konfigurationen mit aktuellen Stand (Maskierungen siehe oben) hier einstellen
- 7390 neu starten
- nach der ersten 0x2005-Meldung im Eventlog die Support-Daten erstellen lassen und den Teil mit der ike.log (den findest Du schon) hier einstellen
- weitere Eventlog-Einträge werden nur dann benötigt, wenn sie andere Fehlercodes als 0x2005 enthalten

Diese 1&1-SIMs haben meines Erachtens (im Vodafone-Netz zumindest) in letzter Zeit zwar ein Problem (die zugewiesene IP-Adresse ist nicht mehr die des CGN-Gateways, sondern irgendeine interne im Providernetz, ich habe da von 10.x.x.x über 100.x.x.x (CGN) bis 172.x.x.x in letzter Zeit mehrere Varianten gehabt), aber das betrifft nur die DynDNS-Aktualisierungen, weil dort nie die Adresse (als Quelle des Requests) ankommt, die die FRITZ!Box zu verwenden glaubt und damit so ein Update immer "incomplete" bleibt (führt dann zum nächsten (unlimitierten) Versuch des Updates - bei mir im 30-Minuten-Rhythmus - und nicht zu einem neuen "1st & 10"). Das sollte bei Dir keine Rolle spielen, sowohl MyFRITZ! als auch DynDNS kannst Du bei der UMTS-Box getrost vergessen.
 
Zuletzt bearbeitet:
Ich gebe es dran

Sorry aber via PN oder [email protected] hätte ich kein Prob gehabt Dir die org-cfgs Zukommenzulassen zwecks Kontrolle. Zur Not auch einen Teamviewer-Account nach Absprache/Termin

Dein Support-Wille in allen Ehren ... aber die Nachforderungen -bin schon etwas müde und frustriert- übersteigen einfach meine Fähigkeiten und meinen Wissenshorizont/Durchblick.

Fatalerweise finde ich auch nichtmehr den AVM-Service-Link, wo sämtliche IKE-Errors dokumentiert waren.

Im Nachgang wäre ich ja bereit, eine kleine HowTo für "Anfänger" zu schreiben (etwas ähnliches habe ich schon für die usbgsm.cfg für ältere FBs in Verbindung E3131 vor/fast fertig) ... Egal ich setze das Thema halt auf "Ungelöst/Zu Blöd" falls angeboten durch die Forensoft.

LG und trotzdem lieben Dank
 
Hallo Micha0815,
Supportdaten kann man per http://fritz.box/support.lua erstellen.

Für VPN-Troubleshooting wären die Dateien /var/tmp/ike.log und wenn vorhanden /var/tmp/ike.old sinnvoll, diese können der supportdata.txt Datei entnommen werden:
Code:
##### BEGIN SECTION vpn VPN
SNIP
##### END SECTION vpn

Gruß
Riverhopper
 
Support per PM ist aber dann wieder individuell und bei der nächsten Frage in dieser Richtung schreibt man wieder dasselbe - ein HowTo für VPN mag ja eine Idee sein, ich glaube trotzdem, daß die mögliche Vielfalt an dieser Stelle so groß ist, daß so ein HowTo entweder speziell auf eine Situation zugeschnitten oder immer unvollständig wäre. Dann soll lieber AVM den VPN-Teil ordentlich dokumentieren ...

Der von Dir gesuchte Link ist vermutlich: http://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/014/hilfe_syslog_122 - was der jetzt (wenn es der gesuchte ist) an meiner Feststellung, daß der Fehlercode 0x2005 nicht dokumentiert ist, ändert, sehe ich nicht.

Wieso das Auslesen der Support-Daten (bei den cfg-Files hast Du es ja schon einmal gezeigt, daß Du das kannst) jetzt Deine Fähigkeiten übersteigen soll, verstehe ich nicht ... wie es weitergehen soll, entscheidest aber ohnehin Du.

Ich will nur nicht den finalen Eindruck des nächsten Lesers hier stärken, daß es in irgendeiner Weise kompliziert wäre, diese Datei selbst auf einer Box ohne Telnet auszulesen - das ist auch das Minimum, was AVM bei einer (nicht offensichtlichen) Support-Anfrage haben will und dann ist das nicht nur der Teil mit der ike.log, sondern die gesamte Datei.
 
Danke hatte ich nichtmehr auf dem Schirm

Hallo Micha0815,
Supportdaten kann man per http://fritz.box/support.lua erstellen.

...
Riverhopper

Aus der FB7390

Code:
VPN avmike
-------
-rw-r--r--    1 root     root         10958 Nov  4 19:28 /var/tmp/ike.log
-rw-r--r--    1 root     root         20501 Nov  4 19:24 /var/tmp/ike.old
2015-11-04 19:17:29 avmike:test: Phase 1 failed (initiator): IKE-Error 0x2005
2015-11-04 19:17:29 avmike:< cb_sa_create_failed(name=test,reason=IKE-Error 0x2005)
2015-11-04 19:17:34 avmike:test: aggr.cpp:347: IKE-Error 0x2005
2015-11-04 19:17:34 avmike:test: Phase 1 failed (initiator): IKE-Error 0x2005
2015-11-04 19:17:34 avmike:< cb_sa_create_failed(name=test,reason=IKE-Error 0x2005)
... mit zig Zeilen Wiederholung

Ergo ein Grund-CFG-Problem in der UMTS-FB7390?

aggr.cpp:347: IKE-Error 0x2005 sagt mir nix ;)

@PeterPawn

Danke für den Link ... den meinte ich!

Ich bin redlich bemüht ... nur magst Du mir zubilligen, dass ich etwas vorsichtig bin, komplette cfg`s public zu posten, wenn ich deren z.T. kryptischen Inhalt nicht hinreichend durchschaue.

OT: Ich habe etliche Deiner "Rechtfertigungs-RE" verfolgt, wenn ein Fragesteller etwas ruppig/Dumpf-Tenormässig geantwortet hat ;)

In diese Phalanx möchte ich mich wahrlich nicht Einreihen! ... Nur manchmal hätte ich mir gewünscht, Du hättest einfach statt episch langer Rechtferigungen mit "Punkt+Komma-Syntax" einfach 1-2mal geschluckt und RE.

Dein jüngstes Statement im Forum zu PM+CO wird eher die "üblichen" Konversationspartner als "Primus inter Pares" zu Themen "in höheren Regionen" treffen, als mich als "Blonden Hans" in diesem für Dich einfach/banal klingenden Thread?

Ob mein generelles Ansinnen/der here Versuch für die folgendene Leserschaft zielführend? K.A.

Nicht umsonst hatte ich eingangs gefragt, ob dies jmd. am "Laufen" hat ;)

Wäre dem so gewesen, hätte ich mir diesen Thread tunlichst erspart und wäre "Inmichgegangen"

Nur nach wirklich VIELEN-VIELEN Stunden vergeblichen Probens magst Du mir Verzeihen ob dieses Threads?

LG
 
@Micha0815:
Ich weiß nicht mehr, was ich darauf nun antworten soll ... wenn Du einfach nur im Labor-Thread Deine Frage gestellt hättest und auf den Nachsatz zu meiner Person verzichtet hättest, wäre ich sicherlich auch nicht darauf angesprungen. Wenn Du jetzt die Nerven verlierst, weil Du schon sehr lange probierst, dann kann ich dafür erstens nichts und ich kann es zweitens auch nicht beeinflussen. Willst Du Dein Problem nach wie vor lösen, helfe ich gerne ... willst Du aufgeben, steht das ganz in Deinem Belieben, ich kann dagegen ohnehin nichts machen.

Zur Sache: Dein Auszug aus der ike.log zeigt genau das, was ich als potentielles Problem bereits angeführt habe ... es ist einfach zu viel Zeit seit dem letzten Start der Box vergangen und die ständig wiederholten Fehlermeldungen haben die relevanten Inhalte verdrängt. Wenn ich raten sollte, würde ich davon ausgehen (das ist aber auch definitiv das letzte Mal, ab hier ist für mich Schluß mit dem Raten, weil man damit eben auch problemlos meilenweit daneben liegen kann), daß Du die Adresse der Gegenstelle immer noch falsch konfiguriert hast und daher die 7390 die Adresse der 7490 gar nicht richtig ermitteln kann. Eine "ordentliche" ike.log beginnt spätestens mit einer Zeile:
Code:
avmike:< add(appl=dsld,cname=[B][I]connection_name[/I][/B],localip=[B][I]eigene IP-Adresse[/I][/B], remoteip=[B][I]entfernte IP-Adresse[/I][/B], p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=192.168.xxx.1 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
Danach fängt der Aufbau einer VPN-Verbindung dann an ... und alles danach ist auch relevant - natürlich nicht x Wiederholungen derselben Fehlernachricht, aber alles bis zu der ersten Wiederholung.

Auch habe ich Dich nicht einmal im Ansatz dazu aufgefordert, eine VPN-Konfiguration mit irgendwelchen kryptischen (und damit für Dich nicht nachvollziehbaren) Daten zu posten ... ganz im Gegenteil. Ich habe versucht den Inhalt der verschlüsselten Werte zu erläutern und Dir Hinweise zu geben, was Du dort als Klartext eintragen sollst - schon für den Import als VPN-Konfiguration. Dazu noch der Hinweis, daß der einzige zwingende FQDN für den "remotehostname"-Wert in der Konfiguration der 7390 "maskiert" werden kann. Wenn Du dann in so einer VPN-Konfiguration noch irgendwelche verschlüsselten Daten haben solltest (ich rede von conntype_lan-Konfigurationen), dann ist da ohnehin etwas faul.

Mit dem "persönlichem Support" ist jedenfalls Schluß, egal ob das die "Veröffentlichung" von Informationen erforderlich macht oder nicht. Das geht auch nicht gegen Dich persönlich, aber andere haben diese Forderung "Support gehört ins Forum" seit Urzeiten in ihrer Signatur und die wissen sicherlich auch, warum.

Ab hier beiße ich mir jetzt dann auch tatsächlich auf die Zunge und stelle die Diskussion (und die Versuche, Dich wieder "zu motivieren") ein ... ich verstehe nicht einmal so richtig, ob Du nun in der 7490-Laborversion einen Fehler vermutest oder nicht. Ich kann nur mit einiger Gewißheit sagen, daß es mit der im Laborthread veröffentlichten Konfiguration nicht funktionieren konnte ... was das jetzt für die Laborversion heißt bzw. woran es im Moment noch klemmt bei Dir, muß man eben testen/ermitteln und ohne Deine "Mitarbeit" an der Stelle wird das nichts werden. TeamViewer oder anderes fällt jedenfalls aus ... das führe ich gar nicht erst ein - wo soll man das am Ende dann abgrenzen, wem man auf diese Weise hilft und wem nicht?

Wenn Dein Bekannter übermorgen abreist, hast Du ja nicht mehr so sehr viel Zeit, falls Du es Dir noch einmal überlegen solltest.
 
Danke @PeterPawn für Deine Hilfe und sorry falls ich zu frustig gepostet habe. Es ist nun eh zu spät für den Versand zu meinem Bekannten.

Ich muss halt erkennen, dass ich zu doof bin eine vnp.cfg richtig zu erstellen.

Die UMTS-FB7390 löst die Gegenstelle nicht auf bzw. findet sie nicht.

Code:
05.11.15
	11:29:58	VPN-Fehler: Deutschland, IKE-Error 0x2005 [38 Meldungen seit 05.11.15 11:26:47]
05.11.15
	11:26:46	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20.
05.11.15
	11:26:42	VPN-Fehler: Deutschland, IKE-Error 0x2005 [72 Meldungen seit 05.11.15 11:20:49]
05.11.15
	11:20:48	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20.
05.11.15
	11:20:43	VPN-Fehler: Deutschland, IKE-Error 0x2005 [285 Meldungen seit 05.11.15 10:55:30]
05.11.15
	10:55:26	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20.
05.11.15
	10:55:24	VPN-Fehler: Deutschland, IKE-Error 0x2005 [27 Meldungen seit 05.11.15 10:53:17]
05.11.15
	10:53:13	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20.
05.11.15
	10:53:11	VPN-Fehler: Deutschland, IKE-Error 0x2005 [10 Meldungen seit 05.11.15 10:52:26]
05.11.15
	10:44:30	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20.
05.11.15
	10:43:10	VPN-Fehler: Deutschland, IKE-Error 0x202c [33 Meldungen seit 05.11.15 10:40:31]
05.11.15
	10:40:30	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.183.20.
05.11.15
	10:40:26	VPN-Fehler: Deutschland, IKE-Error 0x202c [11 Meldungen seit 05.11.15 10:39:35]
05.11.15
	10:39:03	Die FRITZ!Box-Einstellungen wurden über die Benutzeroberfläche geändert.
05.11.15
	10:39:01	VPN-Fehler: Deutschland, IKE-Error 0x202c [22 Meldungen seit 05.11.15 10:37:17]


Der Fehlercode 0x2005 könnte auch mit dem ikeapi_send_request zusammenhängen.

Code:
# cat ike.log
1970-01-01 01:01:15 avmike:< add(appl=dsld,cname=Deutschland,localip=100.78.142.
66, remoteip=0.0.0.0, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1
mode=4 keepalive_ip=192.168.177.1 flags=0x8001 tunnel no_xauth no_cfgmode nat_t
no_certsrv_server_auth)
1970-01-01 01:01:15 avmike:new neighbour Deutschland:  dynamic  nat_t
1970-01-01 01:01:15 avmike:Deutschland start_vpn_keepalive 192.168.177.1
2015-11-05 10:19:22 avmike:< add(appl=dsld,cname=Deutschland,localip=10.193.194.
235, remoteip=0.0.0.0, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p
1mode=4 keepalive_ip=192.168.177.1 flags=0x8001 tunnel no_xauth no_cfgmode nat_t
 no_certsrv_server_auth)
2015-11-05 10:19:22 avmike:new neighbour Deutschland:  dynamic  nat_t
2015-11-05 10:19:22 avmike:Deutschland start_vpn_keepalive 192.168.177.1
# Nov  5 10:36:26 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:36:26 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:39:04 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:39:04 dsld[3549]: ipsecassoc_recvcmd: cb_deleted: vpn connection Deuts
chland not found
Nov  5 10:39:04 dsld[3549]: VPN: ikeapi_send_request(IKEAPI-Func 2): failed
Nov  5 10:39:34 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:39:35 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:43:17 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:43:17 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:52:25 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:52:25 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:54:39 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 10:54:39 dsld[3549]: udslinterface_set_forwardrules: group=2

# Nov  5 11:19:21 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 11:19:22 dsld[3549]: ipsecassoc_recvcmd: cb_deleted: vpn connection Deuts
chland not found
[COLOR="#FF0000"]Nov  5 11:19:22 dsld[3549]: VPN: ikeapi_send_request(IKEAPI-Func 2): failed[/COLOR]
Nov  5 11:19:47 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 11:19:47 dsld[3549]: udslinterface_set_forwardrules: group=2

# Nov  5 11:22:57 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 11:22:57 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 11:28:16 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 11:28:16 dsld[3549]: VPN: ikeapi_send_request(IKEAPI-Func 2): failed
Nov  5 11:28:23 dsld[3549]: udslinterface_set_forwardrules: group=2
Nov  5 11:28:23 dsld[3549]: udslinterface_set_forwardrules: group=2

LG und vielleicht lässt der liebe Herrgott am Weekend etwas Hirn vom Himmel fallen und denkt an mich :D
 
Das sieht dem Protokoll nach etwas anders aus.

Der Eintrag "remoteip=0.0.0.0" (bzw. eigentlich sollte es 255.255.255.255 sein) ist normal für eine dynamische Adresse der Gegenstelle beim Hinzufügen der VPN-Verbindung zu den aktiven Verbindungen des avmike, anhand des Datums dieses Eintrags sieht man ja auch, daß das noch vor dem Herstellen der Internetverbindung (genauer vor dem Setzen der korrekten Zeit) erfolgte und da konnte logischerweise der Hostname der 7490 noch gar nicht per DNS aufgelöst werden.

Jetzt würde ich allerdings nach eigenen Tests immer noch sagen, daß es bei AVM tatsächlich den Unterschied zwischen 0.0.0.0 und 255.255.255.255 macht, ob für die Verbindung ein "remotehostname" konfiguriert ist oder nicht. Danach hättest Du bei der 7390 ebenfalls den "remotehostname"-Eintrag aus der Konfiguration entfernt und damit weiß diese Box jetzt gar nicht, wo sie die 7490 suchen soll - sie versucht also gar nicht erst, die 7490 zu finden.

EDIT: Ehe das noch zu Verwirrungen führt ... die Fehlermeldungen des dsld in Bezug auf die "vpn connection Deutschland" interpretiere ich als Ergebnis der - auch ohne bestehende Verbindung ja gesendeten - Keepalive-Pings, wo (alles geraten) der dsld dann versucht, die Verbindung zu starten, der avmike das aber wegen fehlender Adresse nicht kann und dann nach irgendeinem Timeout die - ohnehin nicht aufgebaute - VPN-Verbindung wieder abgebaut werden soll wegen eines Fehlers. Das sind ja erst einmal zwei unabhängige Prozesse ... der avmike sorgt für den Schlüsselaustausch (das Erstellen einer SA) und der dsld übernimmt das eigentliche "Routing" der Daten durch den Tunnel (bzw. erst einmal an die Ver-/Entschlüsselung).
 
Zuletzt bearbeitet:
Wenn ich den remotehostname ...spdns.de eintrage (ich habe es auch schon mit der aktuellen IP der DSL-Verbindung versucht), bleibt der Fehler.
Code:
password:


BusyBox v1.20.2 (2015-03-09 15:52:46 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
# cd /var/tmp
# cat ike.log
2015-11-05 12:51:11 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:51:11 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:51:17 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:51:17 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:51:17 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:51:22 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:51:22 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:51:22 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:51:26 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:51:26 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:51:26 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:51:32 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:51:32 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:51:32 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:51:37 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:51:37 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:51:37 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:51:44 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:51:44 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:51:44 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:51:46 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:51:46 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:51:46 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:52:26 avmike:< add(appl=dsld,cname=Deutschland,localip=10.245.55.1
98, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-al
l/pfs p1mode=4 keepalive_ip=192.168.177.1 flags=0x8001 tunnel no_xauth no_cfgmod
e nat_t no_certsrv_server_auth)
2015-11-05 12:52:26 avmike:new neighbour Deutschland:  nat_t
2015-11-05 12:52:26 avmike:Deutschland start_vpn_keepalive 192.168.177.1
2015-11-05 12:52:26 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:52:26 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:52:26 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:52:32 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:52:32 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:52:32 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:52:36 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:52:36 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:52:36 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:52:43 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:52:43 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:52:43 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:52:48 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:52:48 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:52:48 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:52:52 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:52:52 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:52:52 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:52:56 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:52:56 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:52:56 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:53:03 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:53:03 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:53:03 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:53:07 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:53:07 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:53:07 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)
2015-11-05 12:53:11 avmike:Deutschland: aggr.cpp:347: IKE-Error 0x2005
2015-11-05 12:53:11 avmike:Deutschland: Phase 1 failed (initiator): IKE-Error 0x
2005
2015-11-05 12:53:11 avmike:< cb_sa_create_failed(name=Deutschland,reason=IKE-Err
or 0x2005)

LG
 
Dafür finden jetzt wenigstens wieder Verbindungsversuche statt. In #14 sieht man ja, daß von 10:19:22 Uhr bis 10:36:26 Uhr (der Zeitstempel der Meldung vom dsld) praktisch nichts beim VPN passiert ist, das ist jetzt (wieder) anders.

Eigentlich folgt jetzt bei korrekter Konfiguration etwas in der Art
Code:
1970-01-01 01:01:17 avmike:< add(appl=dsld,cname=[I]connection_name[/I],localip=79.212.61.193, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=[I]remove_internal_ip[/I] flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
1970-01-01 01:01:17 avmike:new neighbour [I]connection_name[/I]:  nat_t
1970-01-01 01:01:17 avmike:[I]connection_name[/I] start_vpn_keepalive [I]remote_internal_ip[/I]
[COLOR="#008000"]2015-11-05 13:54:56 avmike:[I]connection_name[/I]: Warning: source changed from 0.0.0.0:500 to [I]current_remote_ip[/I]:500[/COLOR]
wenn die Auflösung des DynDNS-Namens nach dem Herstellen der Internetverbindung dann funktioniert hat (ich habe extra mal eine entfernte Box neu gestartet, die meine 7490 als passiven Responder verwendet, damit ich an die richtige Reihenfolge der Nachrichten komme).

Irgendetwas verhindert also bei der 7390 bei Dir die Auflösung des Namens, event. sogar schon die DNS-Abfrage an sich ... die ersten drei Einträge sind ja auch bei Dir vorhanden - die cfg-Files wären hier eben hilfreich.

Offensichtlich wird der avmike vom dsld auch erst dann getriggert, wenn die eigene IP-Adresse bereits bekannt ist (oben die 79.212.61.193, eine dynamische IP eines 1&1-Anschlusses), aber der multid wohl noch nicht mit dem chrony-Start und dem Setzen der Uhrzeit fertig ist.

Mal abgesehen davon, Du hast meine "Anspielung" aus irgendeinem vorhergehenden Beitrag richtig verstanden und bei der 7390 sowohl DynDNS als auch die MyFRITZ!-Registrierung deaktiviert? Es sollte eigentlich keinen ursächlichen Zusammenhang geben, aber man weiß ja nie so genau, was AVM da intern miteinander verquickt hat. Es gab m.W. vereinzelte Berichte, daß der Fehler 0x2005 nur dann auftritt, wenn eine MyFRITZ!-Anmeldung der Box bei AVM erfolgt.

EDIT:
Ob tatsächlich das "source changed from ... to ..." kommen muß, will ich nicht mehr zu 100% behaupten - das könnte auch auf einen Kontaktversuch der Gegenstelle (also meiner 7490) zurückzuführen sein, weil sich wohl die IP-Adresse nicht geändert hatte und bei meiner 7490 tatsächlich ein eigenes "keepalive ping" für diese Verbindung konfiguriert ist (hat andere Ursachen). Es bleibt dabei: DynDNS/MyFRITZ! deaktivieren, neu starten, Fehlermeldung beobachten, bleibt es bei 0x2005, reicht die ike.log. Ansonsten Trotzdem braucht es tatsächlich die zwei Konfigurationsdateien, insbesondere bei den IDs für P1 muß man als nächstes sichergehen, daß es tatsächlich zueinander paßt. Auch wäre die ike.log der 7490 nun doch mal interessant ... wenn die nur als passiver Responder vor sich hinsteht und keine Verbindungsversuche seitens der 7390 ankommen, dann dürfte dort die ike.log ja nur so aussehen, wie die der 7390 in #14 ... Hinzufügen der VPN-Verbindung und gut ist's, dann folgt das Warten auf eingehende Verbindungen.

EDIT2:
Nein, das kann doch kein externer Kontaktversuch gewesen sein, die IP-Adresse der entfernten Box hatte sich beim Neustart doch geändert und die neue Adresse war auch noch nicht per DynDNS-Update aktualisiert (das erfolgt mit einiger Verzögerung). Damit kann also meine Box gar nicht gewußt haben, wo sich die Box am 1&1-Anschluß nach dem Neustart finden ließ und es muß sich bei der Meldung um das Ergebnis der Namensauflösung der entfernten Box für die Adresse meiner eigenen gehandelt haben oder um die Reaktion auf die erste Antwort der 7490. Damit bleibe ich bei der Meinung, daß bei Dir bereits die Namensauslösung nicht funktioniert oder - je nach Inhalt der (zeitgleichen) ike.log der 7490 - die beiden Boxen in P1 nichts miteinander anzufangen wissen, weil schlicht die IDs nicht passen und die 7390 bereits auf das erste Paket im "aggressive mode" keine oder eine falsche Antwort erhält.
 
Zuletzt bearbeitet:
...
Irgendetwas verhindert also bei der 7390 bei Dir die Auflösung des Namens, event. sogar schon die DNS-Abfrage an sich ... die ersten drei Einträge sind ja auch bei Dir vorhanden - die cfg-Files wären hier eben hilfreich. ...

Bitteschön die vpn.cfg der 7390

Code:
vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "Deutschland";
                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 = "*.spdns.de";
                keepalive_ip = 192.168.177.1;
                localid {
                        fqdn = "";
                }
                remoteid {
                        fqdn = "*spdns.de";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "key identisch zu der FB7490";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.183.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.177.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.177.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";
}


Mal abgesehen davon, Du hast meine "Anspielung" aus irgendeinem vorhergehenden Beitrag richtig verstanden und bei der 7390 sowohl DynDNS als auch die MyFRITZ!-Registrierung deaktiviert? Es sollte eigentlich keinen ursächlichen Zusammenhang geben, aber man weiß ja nie so genau, was AVM da intern miteinander verquickt hat. Es gab m.W. vereinzelte Berichte, daß der Fehler 0x2005 nur dann auftritt, wenn eine MyFRITZ!-Anmeldung der Box bei AVM erfolgt.

Weder dyndns noch myfritz ist aktiviert.

LG
 
Zuletzt bearbeitet:
Dann probiere es bitte mal mit den folgenden Zeilen in der 7390:
Code:
localid {
   fqdn = "esp.vpn.local";
}
remoteid {
   fqdn = "de.vpn.local";
}
und in der 7490 dann das gespiegelte
Code:
localid {
   fqdn = "de.vpn.local";
}
remoteid {
   fqdn = "esp.vpn.local";
}
Damit wird der (vom FRITZ!Box-GUI der Einfachheit halber angenommene) direkte Zusammenhang zwischen "localid" und dem eigenen "Hostnamen", den es ja bei der UMTS-Box nicht gibt, aufgebrochen und man kann sich wirklich sicher sein, daß da auch jeweils die richtigen IDs konfiguriert sind.

Eine mit dem AVM-GUI konfigurierte 7490, bei der man dank Verschlüsselung nicht sieht, was bei der "localid" am Ende in "fqdn" steht, könnte auch die Erklärung sein, warum einige Meldungen das mit dem MyFRITZ!-Service in Verbindung bringen. Solange die Box dort ihren MyFRITZ!-Namen einträgt und von der anderen Seite aber mit einem anderen (zusätzlichen) DynDNS-Namen der Verbindungsaufbau versucht wird, kann das auch wieder nicht klappen.

Ich wüßte jetzt nicht, wo man beim AVM-GUI auswählen kann, was eine Box bei gleichzeitigem DynDNS- und MyFRITZ!-Account als "localid" verwenden soll - ja, ich weiß nicht einmal genau, welchen Namen der Assistent dann verwendet und ob das immer derselbe ist oder sogar die Reihenfolge der Einrichtung in der Box eine Rolle spielt.

Bei der Gegenstelle wird vom AVM-GUI einfach "remoteid fqdn" == "remotehostname" angenommen (was auch nicht zwingend ist, aber der Assistent ist ohnehin nur der Vorschlaghammer und für Uhrenreparaturen ungeeignet). Es gibt auch genug Leute, die den MyFRITZ!-Service parallel zu einem eigenen DynDNS-Account einsetzen, praktisch als "Reserve".

EDIT: Die Domain "vpn.local" könnte eventuell doch Problem bereiten (ich habe das nicht selbst getestet, sondern nur in diesem Thread gelesen), also besser eine andere nehmen, wobei da m.E. immer noch kein zwingender Zusammenhang zum DynDNS-Namen besteht (und zwar weder zu einem eigenen noch zu einem von MyFRITZ!).
 
Zuletzt bearbeitet:
Danke

aber das führte auch nicht zum Ziel. Gebe ich in der FB7490 eine remote-id fqdn ein, sehe ich den ike-Fehler 0x202C (Remote nicht gefunden).

Mit "leerer" ID geht wohl an der FB7490 (mit aktueller Labor 113.06.36-31739) nichts mehr. Ich hatte spasseshalber mal editable = yes in meine cfgs. eingefügt. Die 7490 besteht bei Änderungen auf einer Remote ID. Ohne (leeres Feld) ist ein Abspeichern in der GUI nicht möglich. Zudem schlägt die GUI auch LAN-Anschlüsse mit eigenem Adressbereich vor für den VPN-Zugriff.

Screen Shot 11-06-15 at 03.44 PM.JPG

Den Hintergrund durchschaue ich nicht wirklich. Wenn 2 FBs per VPN verbunden sind, sollten doch auch WLAN-Clients den VPN-Tunnel nutzen können?



Wenn Du der Sache auf den Grund gehen möchtest, tausche doch mal bei Gelegenheit Deine FB7270+E3131 gegen eine Deiner FB7390 Testboxen?

Mit Deinem Wissen/Werkzeugen usw. wirst Du sicherlich in Windeseile erkennen, ob und wie es ggfs. laufen könnte? oder auch nicht.

LG
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

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

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.