Es geht in eine weitere Runde bei den VPNs von und zur FRITZ!Box. Nach den unglücklichen Änderungen in Version 06.20 hat AVM wieder ein paar Phase 2 Proposals hinzugenommen, die komplett ohne Kompression laufen. Somit ist es wieder möglich, die FRITZ!Box im Aggressive Mode VPN-Verbindungen zu diversen Firewalls aufbauen zu lassen. Komisch nur, dass noch nicht alles ganz wie erwartet funktioniert. Hier kommen meine Testergebnisse.
IPsec Proposals
Auf Anfrage hat mir AVM die “Strategien” für IPsec in der Version 06.23 zur Verfügung gestellt. Diese sind wie folgt:
Phase 1:
- dh5/aes/sha
- dh14/aes/sha
- dh15/aes/sha
- def/all/all
- alt/all/all
- all/all/all
- LT8h/all/all/all
Phase 2:
- esp-aes-sha/ah-all/comp-lzjh-no/pfs
- esp-all-all/ah-all/comp-all/pfs
- esp-all-all/ah-all/comp-all/no-pfs
- esp-all-all/ah-none/comp-all/pfs
- esp-3des-sha/ah-no/comp-no/no-pfs
- esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs
- esp-all-all/ah-none/comp-all/no-pfs
- LT8h/esp-all-all/ah-none/comp-all/pfs
- LT8h/esp-all-all/ah-none/comp-all/no-pfs
Mein Ziel war es also, in beiden Phase möglichst DH-14 und AES-256 einzusetzen, wobei Phase 1 gerne eine Lifetime von 8 Stunden haben darf, während Phase 2 nur eine Stunde laufen soll. (Hintergrund: Da es ständig zu Verbindungsabbrüchen beim Rekeying kommt, sind längere Lifetimes hier wohl besser.) Leider hat das nicht exakt so geklappt…
Tests
Die folgenden Tests habe ich extra alle im Aggressive Mode laufen lassen, so dass stets die FRITZ!Box (hinter einer dynamischen IP) die VPN-Verbindung initiiert. Bei einigen Kunden scheint das Voraussetzung zu sein. Als Gegenstelle hatte ich eine Juniper ScreenOS SSG 5 mit Version 6.3.0r18.0 im Labor (siehe hier). Die FRITZ!Box ist eine 7390 und wie gesagt mit FRITZ!OS Version 06.23.
Folgende Tabelle zeigt immer zweizeilig die Einstellungen für Phase 1 und 2:
# | FRITZ!Box | Juniper | Läuft? | Kommentar |
---|---|---|---|---|
1 | dh14/aes/sha | pre-g14-aes256-sha1-3600s | Ja | Leider nur mit 1 h bei Phase 1. |
esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs | g14-esp-aes256-sha1-3600s | Ja | ||
2 | LT8h/all/all/all | pre-g14-aes256-sha1-28800s | Nein | Phase 1 Mismatch, also scheint DH-14 hier nicht zu klappen |
esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs | g14-esp-aes256-sha1-3600s | |||
3 | LT8h/all/all/all | pre-g2-aes256-sha1-28800s | Ja | Aha, also mit DH-2 und 8 h klappt es |
esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs | g14-esp-aes256-sha1-3600s | Nein | There were no acceptable Phase 2 proposals. WARUM? | |
4 | LT8h/all/all/all | pre-g2-aes256-sha1-28800s | Ja | |
esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs | g2-esp-aes256-sha1-3600s | Ja | Mit DH-2 klappt es auch hier. Komisch, weil es bei Test 1 ja exakt mit diesem Proposal lief. |
Sehr komisch ist also zum Beispiel, dass bei Tests 1 und 3 für Phase 2 jeweils das gleiche Proposal seitens der FRITZ!Box verwendet wurde, es aber in Test 1 mit DH-14 funktioniert hat, in Test 3 aber nicht. Hm.
Bei Variante 1 sah es auf der Juniper SSG also so aus:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
fd-wv-fw01-> get ike cookies IKEv1 SA -- Active: 9, Dead: 0, Total 9 80182f/0006, 95.116.94.50:500->172.16.0.2:500, PRESHR/grp14/AES256/SHA, xchg(4) (fdorf-foobar.webernetz.net/grp-1/usr-1) resent-tmr 322 lifetime 3600 lt-recv 3600 nxt_rekey 3040 cert-expire 0 responder, err cnt 0, send dir 1, cond 0xc0 nat-traversal map not available ike heartbeat : disabled ike heartbeat last rcv time: 0 ike heartbeat last snd time: 0 XAUTH status: 0 DPD seq local 0, peer 0 fd-wv-fw01-> fd-wv-fw01-> fd-wv-fw01-> get sa id 6 index 4, name fdorf-foobar.webernetz.net, peer gateway ip 95.116.94.50. vsys auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1> vpngrp:<-1>. sa_list_nxt:<-1>. tunnel id 6, peer id 4, NSRP Local. site-to-site. Local interface is ethernet0/0 <172.16.0.2>. esp, group 14, a256 encryption, sha1 authentication autokey, IN active, OUT active monitor<1>, latency: 37, availability: 100 DF bit: clear app_sa_flags: 0x24001a7 proxy id: local 192.168.96.0/255.255.224.0, remote 192.168.29.0/255.255.255.0, proto 0, port 0/0 ike activity timestamp: -1633079230 DSCP-mark : enabled, value : 0 nat-traversal map not available incoming: SPI f41f788e, flag 00004000, tunnel info 40000006, pipeline life 3600 sec, 3001 remain, 0 kb, 0 bytes remain anti-replay on, last 0x263, window 0xffffffff, idle timeout value <0>, idled 1 seconds next pak sequence number: 0x0 bytes/paks:105778793/531384; sw bytes/paks:105772872/531377 outgoing: SPI d8c63b56, flag 00000000, tunnel info 40000006, pipeline life 3600 sec, 3001 remain, 0 kb, 0 bytes remain anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 0 seconds next pak sequence number: 0x271 bytes/paks:48706409/564603; sw bytes/paks:48706409/564603 |
Variante 4 entsprechend so:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
fd-wv-fw01-> get ike cookies IKEv1 SA -- Active: 9, Dead: 0, Total 9 80182f/0006, 95.116.94.50:500->172.16.0.2:500, PRESHR/grp2/AES256/SHA, xchg(4) (fdorf-foobar.webernetz.net/grp-1/usr-1) resent-tmr 322 lifetime 28800 lt-recv 28800 nxt_rekey 28762 cert-expire 0 responder, err cnt 0, send dir 1, cond 0x0 nat-traversal map not available ike heartbeat : disabled ike heartbeat last rcv time: 0 ike heartbeat last snd time: 0 XAUTH status: 0 DPD seq local 0, peer 0 fd-wv-fw01-> fd-wv-fw01-> fd-wv-fw01-> get sa id 6 index 4, name fdorf-foobar.webernetz.net, peer gateway ip 95.116.94.50. vsys auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1> vpngrp:<-1>. sa_list_nxt:<-1>. tunnel id 6, peer id 4, NSRP Local. site-to-site. Local interface is ethernet0/0 <172.16.0.2>. esp, group 2, a256 encryption, sha1 authentication autokey, IN active, OUT active monitor<0>, latency: -1, availability: 0 DF bit: clear app_sa_flags: 0x2400027 proxy id: local 192.168.96.0/255.255.224.0, remote 192.168.29.0/255.255.255.0, proto 0, port 0/0 ike activity timestamp: -1630958802 DSCP-mark : enabled, value : 0 nat-traversal map not available incoming: SPI f41f789d, flag 00004000, tunnel info 40000006, pipeline life 3600 sec, 3518 remain, 0 kb, 0 bytes remain anti-replay on, last 0x56, window 0xffffffff, idle timeout value <0>, idled 0 seconds next pak sequence number: 0x0 bytes/paks:105813717/531796; sw bytes/paks:105807796/531789 outgoing: SPI 6381d8bc, flag 00000000, tunnel info 40000006, pipeline life 3600 sec, 3518 remain, 0 kb, 0 bytes remain anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 0 seconds next pak sequence number: 0x58 bytes/paks:48741197/565019; sw bytes/paks:48741197/565019 |
Und hier noch ein Screenshot von einem Test zur Cisco ASA Version 8.4(7). Hier wurde ebenfalls die Variante mit einer IKE Lifetime von 8 h verwendet. Die Gegenstelle hatte sogar bereits FRITZ!OS 06.24 installiert:
Fazit
So ganz eindeutig scheint es noch nicht zu sein. Die “all/all/all” Varianten decken doch nicht alles ab und die anderen klappen manchmal und manchmal aber auch nicht. Man hat aktuell die Wahl, ob man DH-14 in beiden Phasen verwenden möchte (was aus sicherheitstechnischer Sicht Sinn macht) oder lieber auf eine Lifetime von 8 h in Phase 1 zurückgreift, dann aber nur DH-2 zum Laufen bekommt.
Templates
Hier noch mal zwei komplette Templates, so wie ich sie aktuell verwende. Bei beiden wird davon ausgegangen, dass die FRITZ!Box eine dynamische IP Adresse hat, also der Aggressive Mode verwendet wird.
DH-14 mit Lifetime 1 h
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
vpncfg { connections { enabled = yes; conn_type = conntype_lan; name = "NAME-OF-THE-VPN"; always_renew = yes; reject_not_encrypted = no; dont_filter_netbios = yes; localip = 0.0.0.0; local_virtualip = 0.0.0.0; remoteip = 192.0.2.86; remote_virtualip = 0.0.0.0; localid { fqdn = "foobar.webernetz.net"; } remoteid { ipaddr = "192.0.2.86"; } mode = phase1_mode_aggressive; phase1ss = "dh14/aes/sha"; keytype = connkeytype_pre_shared; key = "ThisIsThePSKAndShouldBeGeneratedRandomly"; cert_do_server_auth = no; use_nat_t = no; 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-aes256-3des-sha/ah-no/comp-lzs-no/pfs"; accesslist = "permit ip any 192.168.0.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"; } |
Lifetime 8 h aber nur DH-2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
vpncfg { connections { enabled = yes; conn_type = conntype_lan; name = "NAME-OF-THE-VPN"; always_renew = yes; reject_not_encrypted = no; dont_filter_netbios = yes; localip = 0.0.0.0; local_virtualip = 0.0.0.0; remoteip = 192.0.2.86; remote_virtualip = 0.0.0.0; localid { fqdn = "foobar.webernetz.net"; } remoteid { ipaddr = "192.0.2.86"; } mode = phase1_mode_aggressive; phase1ss = "LT8h/all/all/all"; keytype = connkeytype_pre_shared; key = "ThisIsThePSKAndShouldBeGeneratedRandomly"; cert_do_server_auth = no; use_nat_t = no; 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-aes256-3des-sha/ah-no/comp-lzs-no/pfs"; accesslist = "permit ip any 192.168.0.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"; } |
Featured image “ESA_2794” by Metropolitan Transportation Authority of the State of New York is licensed under CC BY 2.0.
Hallo,
haben Sie es wieder geschafft eine Verbindung von der FritzBox Seite aus zu initieren oder besteht auch weiterhin die ” IKE-Error 0x2027″ Problematik?
Viele Grüße und Danke im Voraus für die Antwort
Ja, genau das hat hiermit wieder geklappt. Wie im Post beschrieben initiiert die FRITZ!Box die VPN-Verbindung. Dies ist durch das Vorhandensein der “comp-no” Proposals wieder möglich.
Danke für die super Arbeit. Gibts schon etwas neues dazu. Würde auch gerne mit DH14 arbeiten, aber nach 1h +/- 30min bricht es immer ab.
Sei gegrüßt.
Ich habe folgende Konstellation an einer Sonic Wall mit einer Fritz Box, siehe bitte weiter weiter unten.
Ich habe das Problem, dass die VPN nach einer Stunde trennt und dann wieder aber reconnected. Noch heute morgen, hatte ich das Pech, dass diese Strecke nach einer Stunden trennte, aber nicht mehr verbunden werden konnte.
Dank dieser Seite, habe ich noch diese LT8H hinzugefügt, dass wenigstens die Verbindung nach einer Stunde wieder zustande kommt. Was kann ich da noch optimieren, dass diese Reconnect, zu einer schlechten Erinnerung wird?
Viele Grüße, und über Ideen würde ich mich freuen.
PS= Eine tolle Seite.
SONICWALL Seite sieht so aus:
Sonic Wall Einstellungen
IKE Phase 1 Proposal
Exchange= Main Mode
DH Group = Group 2
Encyription= 3DES
Authentication= SHA1
Life Time in Seconds = 28800
Ip Sec Phase 2 Proposal
Protocol= ESP
Encyription= 3DES
Authentication= SHA1
Perfect Forward Secrecy = Enabled
DH Group = Group 2
Life Time in Seconds = 28800
FRITZBOX SEITE SIEHT SO AUS:
// BEISPIEL DATEI FÜR SONIC WALL
vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = “*************”; //NAME DER VERBINDUNG
always_renew = yes; // UMSTELLEN AUF YES
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = REMOTE EXTERN IP; //REMOTE NETZWERK FESTE IP
remote_virtualip = 0.0.0.0;
localid {
ipaddr = LOKAL EXTERN IP; // LOKALE NETZWERK FESTE IP
}
remoteid {
ipaddr = REMOTE EXTERN IP;//REMOTE NETZWERK FESTE IP
}
mode = phase1_mode_aggressive;
phase1ss = “LT8h/all/all/all”; //LT8H bedeutet Lifetime von 8 Stunden
keytype = connkeytype_pre_shared;
key = “gd/ena”; //SCHLÜSSEL HIER EINTRAGEN
cert_do_server_auth = no;
use_nat_t = no; // NO BEI FESTE IP, YES BEI DYNDNS o. ä.
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = Lokale Interne IP Adresse; //LOKALE INTERNE IP ADRESSE
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = Entfernte interne IP Adresse; //ENTFERNTE INTERNE IP ADRESSE
mask = 255.255.255.0;
}
}
phase2ss = “esp-all-all/ah-none/comp-all/pfs”;
accesslist = “permit ip any Entfernte interne IP Adresse 255.255.255.0”; //ENTFERNTE INTERNE IP ADRESSE
}
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
Hi Salih,
ich habe in den letzten Wochen auch nicht mehr mit der FRITZ!Box herumexperimentiert. Daher kann ich ad-hoc auch nichts dazu sagen.
Kannst du den VPN-Tunnel auch von der Sonicwall aufbauen? Dann könntest du mal mit dem Phase 2 Proposal “LT8h/esp-all-all/ah-none/comp-all/pfs” herumtesten. Falls das klappt hättest du immerhin eine Lifetime von beiden Phasen mit 8 h. (Da dieses Proposal allerdings kein “comp-no” beinhält, wird es vermutlich nicht klappen, wenn die FRITZ!Box das VPN aufbaut. Dieses Problem hatte ich in einem vorherigen Blogpost beschrieben.)
Bezüglich des Reconnects kann ich immerhin sagen, dass das bei mir nie ein Problem war. Es hatte halt nur immer kurz geruckelt, was ich auf die nicht so gute Leistungsfähigkeit der FRITZ!Box zurückführe. Also “eigentlich” sollte das klappen. Klappt der Reconnect denn wirklich gar nicht? Erst nach einem Reboot der FRITZ!Box, oder wie?
Oh das mit dem Reconnect klappt nunmehr, Gott sei Dank. Und Deine Hinweise hier, waren ein Segen.
Noch heute morgen bis Mittag ging gar nichts.
Hatte letzten Freitag die alten Router entfernt und anstelle dessen, eben diese Fritzbox gesetzt. Die Tests waren einwandfrei, natürlich komme ich nicht auf die Idee, dass die Verbindung nach einer Stunden abreisst und danach kein Reconnect mehr zustanden kommt.
Mit der oben mitgeteilte Datei, kommt die Verbindung schwupps zustande und nach einer Stunde reisst die Verbindung wegen lifetime Fehler ab um dann sofort wieder eine Verbindung herzustellen. Und das nur, ich vermute da ich diese LT8H noch davor gesetzt habe.
Leider kann ich den Tunnel von drüben nicht testen, da Fremd Betreut und nicht von mir. Der Initiator ist tatsächlich der Fritzbox, und da komme ich nicht drumrum.
Wenn also diese eine Stunde Reconnect nicht zu beseitigen ist, weil die zweite Phase nicht auf 8 Stunden getrimmt werden kann, ich hatte das auch schon probiert, bin gescheitert, und diese Eine Stunden Aussetzer sowie Logs weiter und wirklich als Ruckler anzusehen sind, lasse ich das so. Seit drei Stunden sind die Reconnects wirklich eine Sekunde und damit können die leben. Vorher nach der eine Stunde ging nichts.
Siehe unten bitte logs, das grad von jetzt stammt. Bin grad auf FB drauf
20.04.15 18:36:05 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.1.200.
20.04.15 17:49:56 VPN-Verbindung zu xxxxxxxxxxxxxxx wurde erfolgreich hergestellt.
20.04.15 17:49:56 VPN-Verbindung zu xxxxxxxxxxx wurde getrennt. Ursache: 1 Lifetime expired
20.04.15 16:59:51 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.1.200.
20.04.15 16:55:56 VPN-Verbindung zu xxxxxxxxxx wurde erfolgreich hergestellt.
20.04.15 16:55:56 VPN-Fehler: xxxxxxxxxxxxxxxx, IKE-Error 0x2026
20.04.15 16:55:12 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xxxxxxxxxxxxxx, DNS-Server: xxxxxxxxxxxx und xxxxxxxxxxx, Gateway: xxxxxxxxxxxx, Breitband-PoP: MUNX47-erx
20.04.15 16:55:10 Internetverbindung wurde getrennt.
20.04.15 16:54:57 VPN-Verbindung zuxxxxxxxxxxxx wurde getrennt. Ursache: 12 SA loss
20.04.15 16:54:57 Die FRITZ!Box-Einstellungen wurden über die Benutzeroberfläche geändert.
20.04.15 16:52:25 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.1.200.
20.04.15 16:42:08 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.1.200.
20.04.15 16:27:45 VPN-Verbindung zu xxxxxxxxxxxx wurde erfolgreich hergestellt.
20.04.15 16:27:45 VPN-Fehler: xxxxxxxxxxxxxx, IKE-Error 0x2026
20.04.15 16:27:29 VPN-Fehler: xxxxxxxxxxxxxxx, IKE-Error 0x2027
20.04.15 16:26:59 VPN-Verbindung zu xxxxxxxxxxxxxxxxxx wurde getrennt. Ursache: 12 SA loss
20.04.15 16:26:29 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xxxxxxxxxxxxxxx6, DNS-Server: xxxxxxxxxxxxxxx und xxxxxxxxxxxx, Gateway:xxxxxxxxxxxxxx, Breitband-PoP: MUNX47-erx
20.04.15 16:26:26 Internetverbindung wurde getrennt.
Hallo, vielen Dank für die klasse Anleitung. Wir haben unteranderen eine FB7490 mit FritzOS 6.30 und einen PaloAlto Cluster 3020 mit Software 6.1.6.
Es funktionierte auf anhieb nur konnte nach der 1.Stunde keine Verbindung mehr aufgebaut werden, Fritzbox VPN ausschalten und wieder anschalten, dann ging es wieder. Mit der Config oben bzw. LT8h/all/all/all funktionierte es auf anhieb. Danke, Klasse Blog.
Haha, sehr cool. Als langjähriger Thomann Kunde freut es mich an dieser Stelle besonders, dass ich euch damit helfen konnte! ;)
Hallo Herr Weber,
zunächst mal: sehr gute Dokumentation. Danke dafür. Frage:
Haben Sie eine funktionierende Konfiguration bzw. Tips für VPN SonicWALL 8aktuelles OS) Fritzbox (OS 6.51) mit statischer IP? Einige der obigen VPNs laufen stabil, andere brechen nach 1 h ab ohne erneuten Verbindungsaufbau. Rekeying von SonicWALL-Seite möglich, von Fritzbox nicht. Danke für einen Tip.
Gruß
Roland Wächter
Hallo,
vielen Dank für die guten Informationen.
Hat jemand schonmal Verbindungen zwischen zwei Fritzbox-Modellen ausprobiert?
Was wären dann die optimalen Parameter für phase1ss und phase2ss,…?
Viele Grüße
Cord
Guten Tag zusammen,
danke für die optimalen Anleitungen, die zu einem erfolgreichen S2S-Tunnel zwischen der Fritzbox (6490) und eine Cisco ASA 5515-X Firewall geführt haben.
Leider scheint es mit dem rekey Verfahren in Phase2 noch insofern Probleme zu geben, dass alle 3600 Sekunden, die Verbindung kurz unterbrochen wird.
Phase 1 konnte dank LT8h erfolgreich auf 28800 Sek. erhöht werden.
Mit den Einstellungen für phase 2 …
LT8h/esp-all-all/ah-none/comp-all/pfs
LT8h/esp-all-all/ah-none/comp-all/no-pfs
… konnte kein VPN-Tunnel mehr aufgebaut werden.
Jemand noch einen Tipp ?
Hallo,
vielen Dank für die Informationen!
Haben Sie Informationen, ob man VPN-Bridge-Interfaces (zur VPN Abkapselung) auch über eine VPN-Konfigurationsdatei hinzuladen kann ? Im Webinterface ist es ja möglich, separate Interfaces anzugeben.
Hallo Fabius,
uh, solche VPN-Bridge-Interfaces sagen mir gar nichts. Kann ich dir leider nichts zu sagen. ;(
Was du aber selber ausprobieren kannst: Lege mal eines an, mache ein Backup der FRITZ!Box, öffne es in einem Notepad++ und suche nach “vpncfg”. Alles was in diesem Bereich steht kann auch über solche Konfigurationsdateien kommen. So habe ich immer einiges herausgefunden.
Hallo,
ich muss mit einer Fritzbox 7490 ein VPN gegen einen ( unbekannten ) Cisco-Router im Rechenzentrum aufbauen. Die notwendigen Parameter sin :
#1: Internet Key Exchange Configuration
==================================
– Authentication Method : Pre-Shared Key
– Pre-Shared Key :
– Authentication Algorithm : sha1
– Encryption Algorithm : aes-128-cbc
– Lifetime : 28800 seconds
– Phase 1 Negotiation Mode : main
– Perfect Forward Secrecy : Diffie-Hellman Group 2
#2: IPSec Configuration
====================
– Protocol : esp
– Authentication Algorithm : hmac-sha1-96
– Encryption Algorithm : aes-128-cbc
– Lifetime : 3600 seconds
– Mode : tunnel
– Perfect Forward Secrecy : Diffie-Hellman Group 2
– DPD Interval : 10
– DPD Retries : 3
– TCP MSS Adjustment : 1387 bytes
– Clear Don’t Fragment Bit : enabled
– Fragmentation : Before encryption
Frage : Wie müssten die Phase1SS und Phhase2SS aussehen, um diese Parameter zu verwenden ? Wie kann ich die DeadPeerdetection konfigurieren ?
Vielen Dank für Hilfe !
Robert
Hi Robert-Peter,
du musst “eigentlich” nur die von mir gelisteten Phase1SS und Phase2SS irgendwie auf deine Anforderungen mergen. Zugegebenermaßen ist das unter Umständen nicht so einfach. ;)
Für Phase 1 würde ich mal folgenden probieren: def/all/all
Für Phase 2 diesen: esp-all-all/ah-none/comp-all/pfs
oder diesen: esp-aes-sha/ah-all/comp-lzjh-no/pfs
Ansonsten musst du einfach viel der Reihe nach ausprobieren. Außerdem wirst du nicht drum herum kommen, mit der Gegenseite zu reden. Aus einem Cisco Router lassen sich viel aussagekräftigere Logs auslesen als das Orakeln bei einer FRITZ!Box.
Bzgl der DPD: Die lässt sich meines Wissens nach bei der FRITZ!Box nicht direkt einstellen. Ist aber zunächst auch nicht so wichtig. Also es sollte nicht direkt zu einem Problem führen, wenn du es nicht eingerichtet hast.
Viel Glück!
Johannes
Guten Morgen,
ich bin seit ca. 2 Tagen mit dem VPN Tunnel zwischen:
FritzBox 3390 – OS: 06.54 und
TERRA Black Dwarf – Securepoint V. 11.6.10
beschäfdtigt und erhalte ja nach Anpassung die Fehler:
IKE-Error 0x2031 – unspecified error
IKE-Error 0x2026 – no proposal chosen
IKE-Error 0x2027 – timeout
im Log der FritzBox 3390
und
im Log der Securepoint V. 11.6.10
initial Main Mode message received ***:* but no connection has been autorized with policy=PSK
no config named ‘FritzBox3390’
Die Konfig der Fritzbox:
vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = “VPN”;
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 = “AAAA”;
localid {
fqdn = “BBBB”;
}
remoteid {
fqdn = “AAAA”;
}
mode = phase1_mode_idp;
phase1ss = “all/all/all”;
keytype = connkeytype_pre_shared;
key = “pwd”;
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = CCCC;
mask = DDDD;
}
}
phase2remoteid {
ipnet {
ipaddr = EEEE;
mask = FFFF;
}
}
phase2ss = “esp-all-all/ah-all/comp-all/pfs”;
accesslist = “permit ip any EEEE FFFF”;
}
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”;
}
Securepoint V11.6.10:
Phase 1:
IKEv1
pre shared key
Start: incoming
dead peer detection = yes
compression = no
AES256
SHA1
MODP1536
3600 sec.
Phase 2:
3DES
SHA1
MODP1536
28.800 sec.
perfect forward secrecy = yes
Hat jemand eine Hilfestellung für mich?
Danke für die Unterstützung im Voraus.
Gruß Lars
Hi Lars,
ich habe es zwar nicht komplett durchdacht, aber hier ein paar Fragen, die dir vielleicht weiterhelfen könnten:
– Du verwendest ein phase2ss mit “…comp-all…”. Damit hatte ich immer Probleme. Nimm bitte mal eines mit “…comp-lzs-no…”. Auf der SecurePoint hast du ja “compression = no” ausgewählt.
– Sind beide Kisten hinter dynamischen IPs mit DynDNS Namen? Wenn ja, dann könnte es evtl nicht klappen, weil deine SecurePoint auf eingehende VPN Verbindungen wartet (Start: incoming). Es gibt Firewalls, die mögen keine VPNs wenn beide Seiten dynamisch sind.
– Sollte die SecurePoint statische IPs haben, dann verwende bei der FRITZ!Box mal anstelle das “remotehostname = “AAAA”;” ein “remoteip = 80.154.108.232;”.
– Achso, außerdem ist dein Mode falsch: “mode = phase1_mode_idp;” <- geht nur bei festen IPs. Du brauchst (auch wenn nur eine Seite dynamische IPs hat) immer: "mode = phase1_mode_aggressive;" Viel Erfolg beim weiteren Durchprobieren. ;) Johannes
Hallo, vielen Dank für die vielen Infos und Tipps.
Ich habe sehr viel probiert, bekomme aber noch immer einen hash mismatch (IKE-Error 0x2020 “hash mismatch in received packet”), gibt’s da vielleicht einen Trick?
Danke
vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = “…”;
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = …;
remote_virtualip = 0.0.0.0;
remoteid {
key_id = “…”;
}
mode = phase1_mode_aggressive;
phase1ss = “all/all/all”;
keytype = connkeytype_pre_shared;
key = “…”;
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = yes;
xauth {
valid = yes;
username = “…”;
passwd = “…”;
}
use_cfgmode = no; // dont set default route
phase2localid {
ipnet {
ipaddr = 192.168.179.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 178.16.50.0;
mask = 255.255.255.0;
}
}
phase2ss = “esp-aes-sha/ah-all/comp-lzjh-no/pfs”;
accesslist =
“permit ip any any”;
}
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 def/all/all bekomme ich IKE-Error 0x2026 “no proposal chosen”.
Mit alt/all/all wieder 2020.
Mit dh5/aes/sha wieder 2026.
OK, es lag doch an der Authentifizierung. Bei Cisco auf der Gegenseite musste ich den Gruppennamen hier eintragen: localid {
key_id = “gruppenname”;
}
und nicht in remoteid.
Hi Johannes, zu Deinem Test Nr. 2 und dem Ergebnis “Phase 1 Mismatch, also scheint DH-14 hier nicht zu klappen” wollte ich noch anmerken, dass in den FAQs von AVM explizit steht (auch wenn sich dieser Artikel auf eine Client-to-LAN-Koppelung bezieht):
“Die FRITZ!Box nutzt beim Schlüsselaustausch über Diffie-Hellman initial 1024 Bit (DH-Gruppe 2). Sie akzeptiert danach aber auch 768, 1536, 2048 und 3072 Bit (DH-Gruppe 1, 5, 14 und 15).”
(https://avm.de/service/vpn/tipps-tricks/fritzbox-mit-einem-firmen-vpn-verbinden/)
Vom Verständnis her: Bedeutet das denn nicht, dass man an der Gegenstelle (Juniper etc.) dafür sorgen muss, dass in Phase 1 DH-Gruppe 2 vorgeschlagen wird und in Phase 2 dann DH-Gruppe 14 oder 15? Oder habe ich einen Denkfehler?
Hi Lars. Ich glaube, dass du da den Text von AVM falsch verstehst. Dein Zitat steht ja unter der Unterschrift “Unterstützte IPSec-Algorithmen für IKE-Phase 1:”. Die Angaben beziehen sich also rein auf Phase 1 und geben meiner Einschätzung nach nur die Reihenfolge der Proposals an.
(Bei IKE und auch ESP ist die Angabe der Proposals immer in einer Liste sortiert, je nach Konfiguration durch den Admin.)
Interessant finde ich aber noch folgende Satz bzgl. Phase 2: “Die Diffie-Hellman-Gruppe wird durch IKE-Phase 1 bestimmt”. Aha, also evtl. muss man für Phase 2 immer genau die gleiche DH-Gruppe wie für Phase 1 nehmen? Das würde erklären, warum mein 3. Tests nicht lief.
Danke dir, Johannes
Moin,
erstmal danke für deine tolle Arbeit hier!
Zur Info:
# Weitere Verbesserungen im FRITZ!OS 7.00
– **Verbesserung:** SHA-2 unterstützung für VPN Verbindungen
– **Behoben:** Die LAN-Anschlüsse bei der VPN LAN-LAN-Kopplung sind vertauscht
– **Behoben:** VPN Interoperabilität verbessert
Gruß,
Simon
Hallo,
der eingerichtet VPN zur Box funktioniert, nur bei einer APP funktioniert es nicht.
Diese APP sucht Ihre Geräte mittels eines Scans und bekommt keine Ergebnisse.
Natürlich steht alles im gleichen Segment, wenn die App aus dem gleichen lokalen Segment zugreift funktioniert es.
Wass ist bei der Manuellen Konfiguration noch an zupassen?
Danke.
Gruss Frank
Hallo Frank,
also du willst mit der App aus IP-Segment A über den VPN-Tunnel ins IP-Segment B auf der anderen Seite scannen? Dann vermute ich, dass es entweder an der App selbst liegt (kann sie überhaupt in nicht-lokalen Segmenten scannen?) oder an irgendwelchen ACLs auf den Routern. Sind es beides Fritzboxen? Oder ist eine Seite eine richtige Firewall? Dann könnte da eine Security Policy (ACL) drauf sein, die das blockiert? Was sagen die Logs?
Ciao
Johannes
Hallo Johannes,
die VPN wird von einem iphone(IPSec) eröffnet und dieses hat dann eine IP aus dem gleichen Segment, wie die Geräte, sieht man in der Fritz auch. Die App versucht dann den Scan zu machen, um zu schauen ob es Geräte gibt, die sie kennt und dies funktioniert nicht. Wenn das iphone lokal im Segment ist kann es die Geräte finden, diese behalten immer die gleiche IP. Der Hersteller Daikin läst sich da nicht in die Karten schauen, aber es ist eine REST-API die auf Port 80 liegt wie ich in einem Git-Hub Projekt gefunden habe. Die APP kann auch keine IP´s der Geräte konfigurieren und User/PWD ist für die auch ein Fremdwort, daher sollte der VPN das Heilmittel sein, aber derläßt wie es aussieht nicht alle Anfragen/Antworten durch?!
Gruss
Frank
Hi Frank.
Achso, du meintest gar nicht ein Site-2-Site VPN (wie quasi alle hier beschriebenen auf meiner Seite), sondern ein Remote Access VPN. Jetzt komme ich langsam auf den richtigen Dampfer. ;)
Leider kenne ich mich mit dem Funktionsumfang der RA VPNs von den FRITZ!Boxen nicht so gut aus. Ich hätte aber vermutet, das *alle* IP Verbindungen darüber getunnelt werden und auch erlaubt sind. Erst recht der Port 80, welcher ja wirklich Standard ist. Die REST-API sollte also über den VPN-Tunnel funktionieren. Und welche IPv4 Adresse dein Server im Netzwerk der Fritzbox hat kannst du ja auch über die Fritzbox direkt rausfinden. Hierfür benötigst du den Scan ja eigentlich nicht mehr, oder?
Ciao
Johannes
Viel hat sich aber scheinbar auch bei der neuen 7.51 (beta) nicht getan in puncto IPsec Proposals.
Hier gibt es wie oben einen ganz interessanten aktuellen Test zu der Thematik:
https://administrator.de/forum/routingprobleme-ueber-openvpn-auf-fritzbox-4941192029.html#comment-5484777600
Falls jemand hier landet,
Ich hab gestern von einer 7490 auf eine 7583 gewechselt, und bekomme mit den gleichen Parametern (selbst wenn ich die vpn.cfg manuell importierte) nun keine Verbindung mehr.
Vermutung: Irgendwann zwischen den Versionen zur 07.31 scheint AVM ein paar Security Parameter nun verbessert zu haben.
Hey darkfader. Ich habe aktuell eine 7490 mit FRITZ!OS 7.57 auf der ich ein VPN zu einer FortiGate mit folgenden Parametern am laufen habe:
phase1ss = “dh14/aes/sha”;
phase2ss = “esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs”;
Mit einer 7530 AX und dem gleichen FRITZ!OS 7.57 ebenso.
Konntest du in der Zwischenzeit was herausfinden?
Zu o.a. Testlink gibt es ein kleines Update:
https://administrator.de/forum/routingprobleme-ueber-openvpn-auf-fritzbox-4941192029.html#comment-5529769659
Interessant ist dort auch eine Strongswan Jumphost Konfiguration für die Fritzbox:
https://administrator.de/tutorial/ikev2-vpn-server-fuer-windows-und-apple-clients-mit-raspberry-pi-1754377434.html#toc-13
Mit einem entsprechenden Setup in dem Server könnte man die verschiedenen Crypto Credentials der Fritzbox problemlos testen.