VPN Fehler IKE-Error 0x1c zwischen zwei Fritz-Boxen

[mdline]

Hallo miteinander,

versuche eine VPN Verbindung zwischen dem Router 7270 und 7490 aufzubauen.
Verzweifle schon, bekomme ständig die Fehlermeldung IKE-Error 0x1c.
Also zu meinen Schritten:

Beide verwenden das gleiche MyFritz-Konto, haben aber natürlich unterschiedliche MyFritz-Domainnamen.
FritzBox A:
Ip-Adresse 192.168.10.1
Domainname: ...A.myfritz.net

FritzBox B:
Ip-Adresse 192.168.20.1
Domainname: ...B.myfritz.net

Ich habe eine Lan-Lan Kopplung angelegt auf beiden Routern.
Das Preshared-Key wurde auf beiden Routern gleich vergeben.
Im Feld Internetadresse und entferntes Netzwerk wurden jeweils die Daten der Gegenstelle eingetragen.

Im Falle von Fritz..A:
Internetadresse: ...B.myfritz.net
Entferntes Netzwerk: 192.168.20.1


Im Falle von Fritz..B:
Internetadresse: ...A.myfritz.net
Entferntes Netzwerk: 192.168.10.1

und natürlich "VPN-Verbindung dauerhaft halten" auf beiden auf ja gestellt.
Sofern ich im Ereignisfenster beobachten konnte von FritzBox A wird der Fehler
VPN-Fehler: ..A.myfritz.net, IKE-Error 0x1c
angezeigt. Jedoch wird im Ereignisfenster der FritzBox B nix angezeigt.

Bitte um Hilfe.

 

[PeterPawn]

Das ist das entfernte Netzwerk, was da zu konfigurieren ist und kein entfernter Host.

Ansonsten gibt es genug Threads, wo die Bestandteile einer "ordentlichen Fehlermeldung" (Konfigurationsdateien, Protokolle) erläutert sind und wie man da herankommt.

Wir wissen zwar nun dank #1, um welche Modelle es sich handelt, aber die verwendete Firmware ist nach wie vor "geheim"?

Mit der 06.20 hat sich gerade beim VPN vieles getan (die Suchfunktion hilft da sicherlich), mit ein wenig Pech scheitert das bei der Konfiguration über das GUI schon an den unterschiedlichen Proposals zwischen einer - anzunehmenden - 06.06 und der 06.30 oder sogar 06.50.

Dann bliebe nichts weiter übrig, als auf beiden Seiten die Verbindung anhand von "templates" oder mit dem Programm "FRITZ!Fernzugang konfigurieren" auf der Basis von Dateien zu konfigurieren, die dann im GUI nur noch importiert werden. Mit der Template-Methode hat man dabei die größte Kontrolle über die notwendigen Einstellungen - die würde ich in jedem Falle ggü. dem alten Konfigurationsprogramm bevorzugen, wenn ich es machen müßte.

 

[mdline]

Also falsche Angabe, natürlich das entfernte Netzwerk 192.168.10.0 und 192.168.20.0.
Also der 7270 Version FRITZ!OS 06.06 und der 7490 FRITZ!OS 06.30.
Wenn ich es über das Tool mache, was soll ich in das Feld DynamicDns eintragen, d.h. würde es ausreichen dort ...A.myfritz.net zu schreiben?

 

[PeterPawn]

Ja, reicht aus ... wird aber vermutlich auch nicht auf Anhieb klappen, dann bitte die Konfigurationen hier einstellen und max. die DynDNS-Namen (bzw. die MyFRITZ!-Namen) verfremden - event. noch die Netzwerksegmente. Den Rest dann 1:1 so belassen, selbst einen PSK kannst Du beim nächsten Versuch dann noch einmal gegen einen neuen austauschen in beiden Konfigurationen ... aber wir hatten es auch schon oft genug, daß gerade beim Verfremden dann die Fehler mit "beseitigt" wurden und dann geht das Kopfzerbrechen los.

Was Du vermutlich auch noch brauchen wirst (und was an anderen Stellen eher selten aufgeführt ist), ist der Inhalt der Datei /etc/default.$CONFIG_PRODUKT/$OEM/ipsec.cfg der jeweiligen Box. Die Angaben in den Feldern "phase1ss" und "phase2ss" selektieren nämlich nur aus dieser Datei einen Listeneintrag mit verschiedenen Proposals für die Verschlüsselung und die übliche Angabe "all/all/all" umfaßt bei der 06.06 andere Einträge als bei der 06.20, daher klappt damit die Verbindung in der Regel nicht. Man muß sich also auf beiden Seiten jeweils zueinander passende (sichere) Sets zusammensuchen und dann deren Selektoren in der Konfigurationsdatei angeben.

Wenn Du nicht wissen solltest, wie Du an diese Dateien auf den jeweiligen Boxen kommen sollst, kannst Du die auch aus der AVM-Firmware extrahieren, denn die sind dort statisch hinterlegt und ändern sich auch in der Box nicht. Die bei AVM an einigen Stellen zu findende schriftliche Aufstellung (z.B. hier und dann den Links folgen) ist jedenfalls ab 06.20 nicht mehr gültig. Wenn Du so eine Aufstellung finden solltest, muß die max. vom Sommer 2014 sein (da ging die 06.10-Laborreihe um in Europa).

 

[mdline]

Hier erstmal die Konfig-Dateien:
Konfig Fritz A:
vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "xxx.myfritz.net";
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 = "xxx.myfritz.net";
localid {
fqdn = "yyy.myfritz.net";
}
remoteid {
fqdn = "xxx.myfritz.net";x
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "[Pic2bS@1198N1a069718Q3b8Lf5)";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.10.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.20.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.20.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";
}

Konfig Fritz B:

vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "yyy.myfritz.net";
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 = "yyy.myfritz.net";
localid {
fqdn = "yyy.myfritz.net";
}
remoteid {
fqdn = "yyy.myfritz.net";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "[Pic2bS@1198N1a069718Q3b8Lf5)";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.20.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.10.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.10.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";
}

 

[PeterPawn]

Ok, dann hier im Anhang als Service meinerseits die ipsec.cfg-Dateien der beiden Versionen (ich habe die ohnehin ausgepackt vorliegen) - wenn es eine passende Schnittmenge der Proposal-Auswahl (anhand Deiner Konfigurationsdateien) gibt, sollte die Verbindung auch funktionieren, die Dateien sehen auf den ersten Blick richtig aus.

Ich würde noch etwas "optimieren", indem man die "unzuverlässigere" Seite (die öfter neu gestartet/neu verbunden wird - wenn es keine solche gibt, greift man zum Würfel) als "Initiator" bevorzugt und die andere Box als "Responder".

Wenn die Angaben in der ipsec.cfg stimmen:

dynamicdns {
        ttlborder = 2m;
        checkinterval = 2m;
}

, prüft die Firmware ohnehin nur in 2-Minuten-Intervallen, ob sich eine IP-Adresse geändert hat.

Damit ergibt sich bei einem Adresswechsel immer eine potentielle Lücke in der VPN-Verbindung - nur wenn man diese 100% vermeiden kann und muß, sollte man auf beiden Seiten den Verbindungsaufbau gestatten, weil sich unter ungünstigen Umständen (beide Boxen versuchen nahezu zeitgleich eine Verbindung aufzubauen) das schon mal so aufschaukeln kann, daß am Ende gar nichts geht, weil die eine Box immer wieder beim vermeintlichen Timeout für ihren Verbindungsaufbau die bereits von der anderen Box initiierte Verbindung ebenfalls wieder abschießt.

Eine Box, die keine Angabe bei "remotehostname" oder "remoteip" hat, wo sich die Gegenstelle befinden könnte, wartet "ganz brav" auf eingehende Verbindungen.

Du hattest ohnehin in #1 etwas von "dauerhaft halten" geschrieben, dafür bräuchte es noch einen Eintrag "keepalive_ip = IP-Adresse(!);" auf mindestens einer Seite, weil auf der Basis eines ICMP-Echo-Requests an diese Adresse dann eine Verbindung automatisch aufgebaut wird. Das kann man natürlich auch auf beiden Seiten einbauen (und das muß man auch, wenn beide die Verbindung aufbauen sollen und man keine "Lücke" riskieren will), wenn eine Seite nur "Responder" ist, stört das "keepalive_ip" auch nicht, dann kann diese Box trotzdem keine Verbindung aufbauen.

 

[Riverhopper]

Ok, dann hier im Anhang als Service meinerseits die ipsec.cfg-Dateien der beiden Versionen ... wenn es eine passende Schnittmenge der Proposal-Auswahl (anhand Deiner Konfigurationsdateien) gibt, sollte die Verbindung auch funktionieren

Hallo PeterPawn, Hallo mdline,
ich habe die beiden ipsec.cfg Dateien quergecheckt;
die beiden von mdline in vpn.cfg configurierten Proposals:
phase1ss = "all/all/all";
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
sind in beiden ipsec.cfg Configfiles bei Vergleich der zugehörigen Abschnitte identisch.

ipsec.cfg:
cfg_security_strategien {
SNIP
        ike_strategien {
SNIP
                name = "all/all/all";
                comment = "Alle Algorithmen, DH-Gruppe alternate (ausgehend)";
SNIP
        ipsec_strategien {
SNIP
                name = "esp-all-all/ah-none/comp-all/pfs";
                comment = "Alle Algorithmen, ohne AH, mit PFS";
SNIP
}

ich denke es macht Sinn, nachdem Deine Optimierungsvorschläge ("remotehostname", "keepalive_ip") umgesetzt sind, einen Blick auf die VPN-Logfiles (ike.log und ike.old aus den supportdata Dateien) der beiden Fritzboxen zu werfen.

LG Riverhopper

 

[mdline]

Besten Dank, hat gefunkt.
Die Proposals waren gleich, musste keine Änderung in der .cfg vornehmen.
Allerding hat nicht getan, Fehler beim Import.

dynamicdns { ttlborder = 2m; checkinterval = 2m; }

Ich habe die "keepalive_ip" eingetragen in beide configs mit jeweils der IP der Gegenstelle und es hat getan.
Mein Ziel ist es eigentlich dass Fritz A für einen bestimmte IP (verbunden über LAN) den VPN Tunnel verwendet (soll die öffentliche IP des Fritz B verwenden) .
Kann ich es in die cfg mit aufnehmen?

 

[mdline]

Also was ich gemacht habe, die statische Routing Tabelle ergänzt in FritzBox A.
Also Verbindungen vom Gerät 192.168.10.20 sollen auf den FritzBox B weitergeleitet werden.
Dafür habe ich unter IPvNetzwerk eingetragen: 192.168.10.20
Subnetzmaske: 255.255.255.0
Gateway: 192.168.20.1

Habe geprüft ping auf die FritzBox B 192.168.20.1 geht durch.
Allerdings erhalte ich die Meldung "Die IPv4-Adresse liegt nicht innerhalb des IPv4-Netzwerkes der FRITZ!Box" beim Erstellen.
Bitte um Hilfe.

 

[PeterPawn]

Da stellt sich dann allerdings wieder die Frage, ob Du überhaupt versucht hast, andere Beiträge/Threads dazu zu lesen.

Seit wann regelt eine Route denn, von welchem Gerät Daten an ein anderes übertragen werden sollen? Da steht nur, wer die Daten an den Empfänger weiterleiten könnte.

Für die Lösung Deines Problems brauchst Du einen zusätzlichen Eintrag in der "accesslist" für die VPN-Verbindung oder Du mußt auf dem Gerät mit der 192.168.10.20 eine "default"-Route über die 192.168.20.1 einrichten. Die FRITZ!Box A interessiert sich bei reinem Routing keinen Deut dafür, woher die Daten kamen ... da ist nur wichtig, wohin sie diese Daten senden soll.

PS: Was Du mit "Fehler beim Import" meinst bzw. wo Du den dynamicdns-Abschnitt vielleicht importieren wolltest, verstehe ich gar nicht ... das war lediglich ein "Zitat" aus der ipsec.cfg einer FRITZ!Box, der das Handling von DNS-Abfragen für "remotehostname" verdeutlichen sollte. Die Box fragt nämlich in regelmäßigen Intervallen diesen Namen ab und wenn sich die Adresse dahinter ändert, wird die VPN-Verbindung ab- und neu aufgebaut. Das merkt man bei zwei FRITZ!Boxen in der Regel nicht, aber bei einer FRITZ!Box zu einem Provider mit mehreren Adressen hinter einem DNS-Namen führt das zu Problemen und bei zwei Boxen mit dynamischen Adressen ergibt sich dann eben auch eine "Versorgungslücke", wenn nur eine Box die Verbindung aufbauen darf und diese erst nach der Aktualisierung der MyFRITZ!-Adresse die neue Adresse erfährt.

Im ungünstigsten Fall summieren sich da Verzögerungen:

- der DNS-Eintrag für eine MyFRITZ!-Adresse hat eine TTL von 60 Sekunden
- es gibt eine einstellbare Verzögerung (livedelay) beim DynDNS-Update der FRITZ!Box
- die DNS-Abfrage für VPN-"remotehostname"-Angaben erfolgt vermutlich in 120-Sekunden-Intervallen

Das ergibt eine (worst case-)Verzögerung von 180 Sekunden plus "livedelay" bei MyFRITZ!-Updates (was mangels explizitem Eintrag nicht einfach festzustellen ist) minus ein paar Millisekunden - die Zeit zum Neuverbinden der Gegenseite mit dem Internet (wo auch schon keine Datenübertragung stattfinden kann) mal komplett ausgeklammert.

 

[mdline]

Danke für die inforeiche Beschreibung.
Ich weiß allerdings nicht die Syntax wie ich die Default-Route in der config eintrage.

 

[PeterPawn]

Ich weiß allerdings nicht die Syntax wie ich die Default-Route in der config eintrage.

Da ich Dir zwei mögliche Lösungen vorgeschlagen habe (1x in der Box, 1x auf dem Gerät), kann man diesem Satz praktisch nichts entnehmen.

Ansonsten gibt es genug Beiträge zur "accesslist" (wenn sich jemand anderes berufen fühlt, das erneut zu erläutern, hast Du Glück und es ist sein Problem) - da hilft die Suchfunktion des Forums oder notfalls eine Suchmaschine mit Beschränkung der Ergebnisse auf dieses Forum.

Wenn hingegen damit gemeint sein sollte, wie Du eine abweichende "default route" in das Gerät mit der IP-Adresse 192.168.10.20 kriegen sollst, fällt Dir sicherlich selbst auf, daß hier niemand auch nur eine ungefähre Vorstellung (jedenfalls keine irgendwie zu begründende) davon haben kann, um was für ein Gerät es sich handelt ... wir wissen nur, daß es über einen Anschluß für ein Ethernet-Kabel verfügt.

 

[Riverhopper]

Hallo mdline sowie alle VPN-Interessierte,
ich habe mal für deinen Netzknoten 192.168.10.20 eine "Catch-All-Config" erstellt;
d.h. aller Traffic von IP-Adresse 192.168.10.20 aus dem FB_A-LAN wird in den Tunnel "geworfen",
analog sorgt FB_B dafür, dass nur Traffic an die IP 192.168.10.20 in den Tunnel "gesteckt wird".

Lösungsvorschlag:

Konfig Fritz A:

vpncfg {
SNIP
/* accesslist = "permit ip any 192.168.20.0 255.255.255.0"; */
accesslist = "permit ip 192.168.10.20 255.255.255.255 any";
SNIP

Konfig Fritz B:

vpncfg {
SNIP
/* accesslist = "permit ip any 192.168.10.0 255.255.255.0"; */
accesslist = "permit ip any 192.168.10.20 255.255.255.255";
SNIP

Bitte auch Sorge dafür tragen, dass der Netzknoten 192.168.10.20 nicht nach lokalen Netzwerk-Ressourcen aus Netz 192.168.10.0/24 ruft, sondern sich exclusiv via Tunnel versorgt, ggf. ist DNS-Client,... bei diesem Netzknoten anzupassen.

LG Riverhopper

 

[mdline]

danke für die Info.
Ich verscuche gerade von einem PC aus dem Subnetz von FritzA den PC aus dem Subnetz von FritzB anzupingen.
Klappt leider nicht, wen ich aber ein Handy anpinge aus dem Subnetz von B klappt es.
Tracert auf den Rechner von Subnetz B liefert folgendes:

tracert 192.168.20.20
Routenverfolgung zu 192.168.20.20 über maximal 30 Abschnitte

1 86 ms 3 ms 6 ms fritz.box [192.168.10.1]
2 63 ms 65 ms 68 ms 192.168.20.20
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5

 

[Riverhopper]

Hallo Mdline,
aus #14 ergeben sich folgende Anforderungen:
"jeder Netzteilnehmer aus Netz A kann mit Netzteilnehmer aus Netz B sprechen, sowie umgekehrt;
ferner ist für für Netzteilnehmer mit IP 192.168.10.20 aus Netz A die 'Catch-All-Traffic' anzuwenden"

hieraus ergibt sich neue accesslist in den vpn.cfg:

Konfig Fritz A:

vpncfg {
SNIP
accesslist = "permit ip 192.168.10.20 255.255.255.255 any",
"permit ip any 192.168.20.0 255.255.255.0";
SNIP

Konfig Fritz B:

vpncfg {
SNIP
accesslist = "permit ip any 192.168.10.20 255.255.255.255",
"permit ip any 192.168.10.0 255.255.255.0";
SNIP

LG Riverhopper

 

[mdline]

Hat leider nicht geklappt, Ping geht nicht.

 

[PeterPawn]

@Riverhopper:
Bei FRITZ!Box B sollte doch aber "permit ip any 192.168.10.20 255.255.255.255" auch unter die Regel "permit ip any 192.168.10.0 255.255.255.0" fallen, oder? Der zusätzliche Eintrag dürfte daher unnötig sein. Wenn mdline den Zugriff von 192.168.20.0/24 auf beliebige Adressen in 192.168.10.0/24 gar nicht einschränken will, sondern nur 192.168.10.20/32 immer über den Tunnel schicken will, kann die "accesslist" bei B logischerweise unverändert so bleiben, wie sie seit #5 sein sollte.

Ansonsten ziehe ich den Hut vor Dir ... ich blicke durch die sehr rudimentären Angaben und das Durcheinanderwerfen von Beschreibungen - Beispiel gefällig?

Ich verscuche gerade von einem PC aus dem Subnetz von FritzA den PC aus dem Subnetz von FritzB anzupingen.
Klappt leider nicht, wen ich aber ein Handy anpinge aus dem Subnetz von B klappt es.
Tracert auf den Rechner von Subnetz B liefert folgendes:

tracert 192.168.20.20
Routenverfolgung zu 192.168.20.20 über maximal 30 Abschnitte

- schon lange nicht mehr durch.

Wenn das

Tracert auf den Rechner von in Subnetz B (von Subnetz A aus)

sein soll, dann paßt die Adresse zumindest zu dem, was davor geschrieben wurde.

Ist das hingegen als

Tracert auf den Rechner von Subnetz B aus

zu verstehen (das ist derselbe Abstand beim "Schriftdeuten" zum originalen Text), stimmt ja schon die IP-Adresse des Ziels nicht, weil das lokal wäre und der Tunnel gar nicht involviert ist.

Diese "Detektivarbeit", was mdline da nun wirklich meinen mag, ist sicherlich sehr spannend und bestimmt ist es auch schön, wenn es am Ende funktioniert ... damit das aber nicht noch ein weiterer Thread mit vollkommen unverständlichen Fragestellungen bzgl. VPN wird, würde ich vorschlagen, daß ihr zumindest zum Ende hin (und unter schriftlicher - verständlicher - Zusammenfassung der finalen Lösung) noch einmal etwas mehr Klarheit in die Geschichte bringt.

So, wie das im Moment zu lesen ist, ist es m.E. nur ein Negativ-Beispiel, das bei anderen Lesern, die bei der Suche darauf stoßen, eher größeres Unverständnis hervorrufen dürfte als zu irgendeiner Klärung beizutragen.

 

[Riverhopper]

Hat leider nicht geklappt, Ping geht nicht.

Hallo Mdline,
ich habe die Glaskugel gerade nicht zur Hand;
Bitte Details zu "Ping geht nicht"
z.B. "ping <IP>" mit Angabe von welchem Gerät mit welcher IP aus welchem Netz ?
gerne auch mit Befehlslog untermauern.

LG Riverhopper

EDIT/Nachtrag: Sorry habe PeterPawns Beitrag #17 erst jetzt gelesen,
@Mdline: Bitte die gewünschte Zielsetzung für alle transparent beschreiben, so dass dies auch für zukünftige Leser nachvollziehbar ist.

 

[mdline]

Sorry für die nicht genaue Beschreibung.
Sollte so sein:
Bin auf dem Rechner 192.168.10.22 (Subnetz A) und pinge von dort aus 192.168.20.21 an (Subnetz B).

 

[PeterPawn]

Ja, das sollte allerdings mit der "accesslist" aus #15 für Box A und aus #5 für Box B einwandfrei funktionieren.

Wenn die VPN-Konfigurationen stimmen sollten (das gehört auch zu einer klaren Dokumentation, daß man nicht erwartet, daß sich jeder Leser selbst irgendetwas ausmalt, was da gerade konfiguriert sein könnte und daß man stattdessen jede geänderte Konfiguration auch in ihrer aktuellen Form (wenigstens nach klaren Änderungen) präsentiert), dann würde ich mal über eventuell hinderliche Firewall-Einstellungen nachdenken, je nachdem, was das für "Rechner" sind.

Es sind nun mal zwei unterschiedliche Subnetze, die z.B. einer Windows-Firewall auch mal quer vorm Magen liegen können.