IPSec Fritzbox 6850 zu PFSense

Hi,
ich verzweifle. Ich habe eine Fritzbox 6850 und eine PFSense und der IPSec Tunnel will nicht.

Ich habe die peer identifier willkürlich in den Screenshots und der Datei abgeschnitten. Sorry.

In der CFG steht folgendes:

vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "pfsense";    
                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;
		localid {
                        fqdn = "3yt3.myfritz.net";    
                }
		remotehostname = "965.hotsrv.de";    
                remoteip = 212.123.234.145;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        fqdn = "965.hotsrv.de";  
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";    
                keytype = connkeytype_pre_shared;
                key = "4afef6a0e7d8e8eb9a01c36a1107a5c51af744c6237a9915d36bd5ac";    
                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.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";    
                accesslist = "permit ip any 192.168.1.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";    
} 

Irgendwas übersehe ich. Auch Phase 1 kommt nicht zustande.

Sieht jemand den Fehler? PS: Den Key habe ich geändert, keine Angst

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 8055059269

Url: https://administrator.de/forum/ipsec-fritzbox-6850-zu-pfsense-8055059269.html

Ausgedruckt am: 23.12.2024 um 06:12 Uhr

13 Kommentare

Neuester Kommentar

Moin.

Deine Peer-Identifier auf dem Screenshot stimmen nicht mit der Datei überein.

Cheers,
jsysde

EDITH:
Diffie Hellmann Group sollte auf 14 gesetzt sein.

Hi,
sorry, die Peer-Identifier hatte ich zufällig abgeschnitten. DH14 bringt auch nix.

Für DH14 musst du den Phase 1 Mode in der FB ändern. Siehe folgenden Thread am Ende...
Lies dir diesen Thread und die Folgekommentare zu der Thematik durch da findest du auch entsprechende Beispielkonfigs.
Fritzbox pfSense IPsec VPN Setups
Bei deinem Peer Identifier fehlt außerdem eine „3“ oben aber das war ja vermutlich der cut and paste Fehler?!

Bei der FB Konfig Datei solltest du entweder nur den remote Hostname oder die remote IP verwenden aber nicht beides.
Im Zweifel testest du auch mal den Agressive Mode.
Wenn alles rennt solltest
Du ggf. auf der FB in den „LT8“ Mode der Phase 1 wechseln was die üblichen 8 Stunden Lifetime in der Phase 1 verwendet. Siehe dazu auch hier.

Weitere Beispielkonfigs auch hier:
PFsense VPN tunnel zur FritzBox 7390 (IPSec)
Zwei Standorte in Deutschland und EU mit pfSense und FritzBox 7490 für VoIP verbinden

Ich habe auch die o.g. Konfig getestet. Ohne Erfolg.

Ich habe auch eine 7590 getestet. Erfolglos.

Ich habe den Verdacht das sich mit 7.56 etwas grundlegendes geändert hat

Ja, der IDP Mode (Main Mode) wird dort erheblich strikter gehandhabt. Da ist es dann meist besser die remote ID mit der festen IP auf die IP Adresse zu setzen und bei der FB ggf. wieder auf den Agressive Mode zurückzugehen.

Ganz wichtig fürs Troubleshooting ist immer das IPsec Log der pfSense!!
Hier in den Settings die Reihenfolge setzen das die aktuellsten Messages oben geloggt werden und VOR dem Zugriffsversuch der FB vorher löschen damit nicht alles mit Meldungen vollgemüllt wird. Das Log zeigt in der Regel recht genau wo der Fehler ist.

Ich schaffe es nun, dass P1 und P2 funktioniert, allerdings geht kein Traffic drüber.

Das sagt das log:

Aug 5 23:06:59	charon	56329	11[IKE] <con1|23> sending NAT-T (RFC 3947) vendor ID
Aug 5 23:06:59	charon	56329	11[IKE] <con1|23> sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Aug 5 23:06:59	charon	56329	11[IKE] <con1|23> initiating Aggressive Mode IKE_SA con1[23] to 46.*.*.*
Aug 5 23:06:59	charon	56329	11[IKE] <con1|23> IKE_SA con1[23] state change: CREATED => CONNECTING
Aug 5 23:06:59	charon	56329	11[CFG] <con1|23> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
Aug 5 23:06:59	charon	56329	11[ENC] <con1|23> generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
Aug 5 23:06:59	charon	56329	11[NET] <con1|23> sending packet: from 202.*.*.*[500] to 46.*.*.*[500] (396 bytes)
Aug 5 23:06:59	charon	56329	02[NET] <con1|23> received packet: from 46.*.*.*[500] to 202.*.*.*[500] (624 bytes)
Aug 5 23:06:59	charon	56329	02[ENC] <con1|23> parsed AGGRESSIVE response 0 [ SA KE No ID HASH N((24576)) V V V V V V NAT-D NAT-D ]
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> received XAuth vendor ID
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> received DPD vendor ID
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> received NAT-T (RFC 3947) vendor ID
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Aug 5 23:06:59	charon	56329	02[ENC] <con1|23> received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> selecting proposal:
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> no acceptable INTEGRITY_ALGORITHM found
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> selecting proposal:
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> proposal matches
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> received proposals: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> reinitiating already active tasks
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> ISAKMP_VENDOR task
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> AGGRESSIVE_MODE task
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> IKE_SA con1[23] established between 202.*.*.*[202.*.*.*]...46.*.*.*[33.myfritz.net]
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> IKE_SA con1[23] state change: CONNECTING => ESTABLISHED
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> scheduling reauthentication in 24486s
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> maximum IKE_SA lifetime 27366s
Aug 5 23:06:59	charon	56329	02[ENC] <con1|23> generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
Aug 5 23:06:59	charon	56329	02[NET] <con1|23> sending packet: from 202.*.*.*[500] to 46.*.*.*[500] (236 bytes)
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> activating new tasks
Aug 5 23:06:59	charon	56329	02[IKE] <con1|23> activating QUICK_MODE task
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> proposing traffic selectors for us:
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> 192.168.1.0/24|/0
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> proposing traffic selectors for other:
Aug 5 23:06:59	charon	56329	02[CFG] <con1|23> 192.168.20.0/24|/0
Aug 5 23:06:59	charon	56329	02[ENC] <con1|23> generating QUICK_MODE request 4141600609 [ HASH SA No KE ID ID ]
Aug 5 23:06:59	charon	56329	02[NET] <con1|23> sending packet: from 202.*.*.*[500] to 46.*.*.*[500] (364 bytes)
Aug 5 23:06:59	charon	56329	11[NET] <con1|23> received packet: from 46.*.*.*[500] to 202.*.*.*[500] (124 bytes)
Aug 5 23:06:59	charon	56329	11[ENC] <con1|23> parsed INFORMATIONAL_V1 request 994194251 [ HASH N(INITIAL_CONTACT) ]
Aug 5 23:07:00	charon	56329	11[NET] <con1|23> received packet: from 46.*.*.*[500] to 202.*.*.*[500] (348 bytes)
Aug 5 23:07:00	charon	56329	11[ENC] <con1|23> parsed QUICK_MODE response 4141600609 [ HASH SA No KE ID ID ]
Aug 5 23:07:00	charon	56329	11[CFG] <con1|23> selecting proposal:
Aug 5 23:07:00	charon	56329	11[CFG] <con1|23> proposal matches
Aug 5 23:07:00	charon	56329	11[CFG] <con1|23> received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Aug 5 23:07:00	charon	56329	11[CFG] <con1|23> configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Aug 5 23:07:00	charon	56329	11[CFG] <con1|23> selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Aug 5 23:07:00	charon	56329	11[CHD] <con1|23> CHILD_SA con1_1{24} state change: CREATED => INSTALLING
Aug 5 23:07:00	charon	56329	11[CHD] <con1|23> using AES_CBC for encryption
Aug 5 23:07:00	charon	56329	11[CHD] <con1|23> using HMAC_SHA1_96 for integrity
Aug 5 23:07:00	charon	56329	11[CHD] <con1|23> adding inbound ESP SA
Aug 5 23:07:00	charon	56329	11[CHD] <con1|23> SPI 0xc36382c7, src 46.*.*.* dst 202.*.*.*
Aug 5 23:07:00	charon	56329	11[CHD] <con1|23> adding outbound ESP SA
Aug 5 23:07:00	charon	56329	11[CHD] <con1|23> SPI 0x17926337, src 202.*.*.* dst 46.*.*.*
Aug 5 23:07:00	charon	56329	11[IKE] <con1|23> CHILD_SA con1_1{24} established with SPIs c36382c7_i 17926337_o and TS 192.168.1.0/24|/0 === 192.168.20.0/24|/0
Aug 5 23:07:00	charon	56329	11[CHD] <con1|23> CHILD_SA con1_1{24} state change: INSTALLING => INSTALLED
Aug 5 23:07:00	charon	56329	11[IKE] <con1|23> reinitiating already active tasks
Aug 5 23:07:00	charon	56329	11[IKE] <con1|23> QUICK_MODE task
Aug 5 23:07:00	charon	56329	11[ENC] <con1|23> generating QUICK_MODE request 4141600609 [ HASH ]
Aug 5 23:07:00	charon	56329	11[NET] <con1|23> sending packet: from 202.*.*.*[500] to 46.*.*.*[500] (108 bytes)
Aug 5 23:07:00	charon	56329	11[IKE] <con1|23> activating new tasks
Aug 5 23:07:00	charon	56329	11[IKE] <con1|23> nothing to initiate
Aug 5 23:07:00	charon	56329	16[CFG] vici client 430 disconnected
Aug 5 23:07:03	charon	56329	16[CFG] vici client 431 connected
Aug 5 23:07:03	charon	56329	15[CFG] vici client 431 registered for: list-sa
Aug 5 23:07:03	charon	56329	16[CFG] vici client 431 requests: list-sas
Aug 5 23:07:03	charon	56329	15[CFG] vici client 431 disconnected

Ok, offensichtlich ist es kein Problem des Tunnels sondern ein Routing-Problem denn ein Ping von der PFSense auf irgendeine Adresse des Remote-Netzwerkes funktioniert

Hi,
Ich sehe den Wald vor Bäumen nicht mehr. Ein ping von der pfsense ins Remote Netzwerk funktioniert. Aber aus den Netzwerken der pfsense nicht 😭. Was mache ich falsch? Es gibt eine ipsec any rule.

Hast du auch auf dem virtuellen IPsec Tunnel Interface eine any any Rule eingerichtet?
Die ist erforderlich das Traffic durch den Tunnel geht.
Die inbound IPsec Regeln auf dem WAN Interface legt die pfSense per Default an. Achtung hier nur wenn die pfSense in einer Router Kaskade betrieben wird dann musst du zwingend die RFC 1918 Netze am WAN Port freigeben. Das ist der Haken bei „Allow RFC1918 IPs“.

Was du übrigens auch machen kannst, sofern die pfSense eine feste statische Provider IP hat, ist diese als reinen Responder laufen zu lassen.
Dazu gibst du als Peer Adresse die „0.0.0.0“ an und setzt unten den Haken Responder only, ChildSA_StartAction = None
Siehe: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p1.html (IKE Endpoint Configuration)
Dann nimmt die pfSense generell alle eingehenden IPsec Requests an und authorisieren kannst du dann mit deinem FQDN (Distinguished Name) oder einer Key ID (User distinguished Name). Local ID kann die IP bleiben.
Damit kann man dann auch via Fritzbox GUI das VPN aufsetzen.
Hier sollte man dann aber immer die Keepalive IP auf der Fritzbox auf das lokale LAN Interface der pfSense setzen damit diese immer den VPN Tunnel zur pfSense triggert. Die pfSense kanndas ja ihrerseits dann nicht mehr wenn sie für den Peer ein reiner Responder ist.
Es gibt halt viele (VPN) Wege nach Rom.

Ich habe unter ipsec eine Any to Any für Any eingerichtet und es funktioniert nicht. Der Ping der Pfsense auf die IP der Fritzbox ist aber da und funktioniert daher halte ich den Tunnel für funktionstüchtig.

Also ich bin auf Firewall ipsec gegangen und habe eine roule any to any mit dem interface ipsec gebaut

Das wäre dann auch soweit ok.
Ein Ping über das „Diagnostics“ Menü der pfSense mit Zieladresse = Fritzbox IP und Sourceadresse = LAN IP pfSense klappt also?!

Wenn du aber aus dem lokalen Fritzbox LAN Netz mit einem dortigen Endgerät die LAN IP der pfSense pingst klappt es nicht. Ist das so richtig?
Bedenke das z.B. bei Windows Clients generell ICMP (Ping) in der lokalen Firewall deaktiviert ist!
Pingst du also mit einem Windows Rechner musst du dies VORHER in den Firewall Settings („Firewall mit erweiterter Sicherheit...“) aktivieren!
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...

Besser ist dann oft zu versuchen mit dem Browser das FW GUI zu ereichen oder einen kleinen Webserver ohne Installation wie den HFS Webserver testweise laufen zu lassen auf einem Endgerät um nicht in die ICMP FW Falle bei Windows zu tappen...

Ich bin so dumm. So unglaublich dumm. Dumm, dumm, dumm. Ich hänge hier seit zwei Tagwn und gehe euch, insbesondre dir aqui auf den Sack weil ich einfach zu blöd bin.

Ok, ich gestehe.

Also PFSense, dahinter eine Windows Kiste, alles virtualisiert. Die pfsense war nicht immer da und die Windows Kiste hat temporär eine NIC mit öffentlicher IP und RDS aktiv bekommen um dies und das konfigurieren zu können. Ich weiß, das macht man nicht, temporär auch nicht, aber ging nicht anders. Die blöde nic war noch aktiv und damit klappte das Routing auf der Windows Kiste nicht.

Der sch... IPSec Tunnel stand von anfang an.