Dec 12, 2022

7593

Routingprobleme über OpenVPN auf Fritzbox

Hi Leute,

ich bin gerade dabei, eine funktionierende Point-to-Point Verbindung von OpenVPN nach IPSec zu migrieren.
Dabei bin ich auf ein recht mysteriöses Problem gestoßen und brauche einen kleinen Denkanstoß.

Der OpenVPN-Server Port 1194, läuft auf meiner pfSense, direkt am VDSL-Anschluß.
LAN der pfSense ist neben physischer DMZ, in 2 VLAN’s aufgeteilt.

VLAN10 10.100.10.0/24 static Netz für Admin-PC, Drucker etc.
VLAN20 10.200.20.0/24 DHCP Netz für Plaudertaschengeräte, TV, Handy, Handys, WLAN etc..

Im 20 er Netz befindet sich mit IP .254, eine Fritte 7490 als IP-Client, die WLAN macht.

Remote,
dient als OpenVPN-Client ein E4200-Router, der einst hinter einer Fritzbox 7412 im Routermodus lief. Besagte 7412 wurde nun gegen eine neue Fritzbox 7590 ausgetauscht, um IPSec zu machen.

Der E4200, LAN-IP 192.168.18.1 statisch, hängt mit dem WAN, statische IP 192.168.55.222 im LAN der 7590 Fritte, während diese DHCP macht. Lease 192.168.55.222 ist fest eingestellt.

Die Einstellungen der Rules beider VLAN’s sind identisch und das log sagt, es wird nichts relevantes geblockt.
Der Tunnel steht und „fast alles ist gut“.

Leider komme ich vom statischen VLAN10, (Gateway, DNS, eingetragen) nicht auf die remote 7590, sondern nur auf den E4200.
Anders im VLAN20. Der Laptop, der im WLAN der 7490 ist, kommt problemlos auf die remote 7590.
Selbiger Laptop im VLAN10 nicht.

An den OpenWRT-Einstellungen des E4200 wurde nichts geändert, bis auf die WAN IP und die Gateway-Einstellungen des LAN.

Es scheint das Routing zur 7590 braucht eine weitere Fritzbox um kommunizieren zu können.

Gruß orcape

Please also mark the comments that contributed to the solution of the article

Content-Key: 4941192029

Url: https://administrator.de/contentid/4941192029

Printed on: April 19, 2024 at 19:04 o'clock

22 Comments

Latest comment

Nur um jetzt nicht noch mehr Verwirrung zu stiften. Es geht um das IPsec Setup, richtig?
Oder redest du von der bestehenden OpenVPN Verbindung? Das ist leider nicht wirklich klar.
Auch welche Zielnetze denn nun via VPN beidseitig erreichbar sein müssen? VLAN 10 und 20 auf der einen Tunnelseite ist klar aber welche sind das auf der anderen Seite?
Muss auch das Koppelnetz .55.0 der Router Kaskade erreichbar sein oder nur das .18.0er Netz?

Versteht man dich richtig, wird oder soll die Kaskade ja verschwinden mit der IPsec Migration. Bleibt denn nur das .55.0er Netz über oder das .18.0er Netz oder beide?? Fragen über Fragen... 🤔
Ggf. ist doch eine kleine Skizze hilfreich und die Klarstellung um welches VPN Protokoll es wirklich geht.

Nur so viel:

Bei IPsec bestimmen die Phase 2 SAs welcher Traffic in den Tunnel geht. Die müssen auf deine Zielnetze passen und beidseitig gleich sein.
Bei OpenVPN machen das die Routing Kommandos in Server und Client
Bedenke auch ggf. ein NAT sofern das relevant ist. Das betrifft den WAN Port des E4200 und auch die IP Client Fritte an der pfSense. Bei letzterer ist nicht klar wie die angebunden ist (missbraucht als nur WLAN AP oder VoIP Anlage?!). Vermutlich sind aber diese Komponenten für die VPN Kopplung nicht relevant (geraten).

Hi aqui,

Es geht um das IPsec Setup, richtig?

Soll es später werden. Eventuell Wireguard, denn das kann die 7590 mit der aktuellen Firmware nun wohl auch.

Oder redest du von der bestehenden OpenVPN Verbindung?

Eine bereits existierende, funktionierende OpenVPN-Verbindung, 10.10.8.0/24, soll zum einrichten der remoten 7590 verwendet werden.
Auf meiner pfSense sind VLAN10 /VLAN20 eingerichtet und der OpenVPN-Server. Die Verbindung steht und ist stabil. Alle Einstellungen der Firewall/NAT sind betreffs der VLAN's identisch.
VLAN10 ist statisch...

Bei letzterer ist nicht klar wie die angebunden ist (missbraucht als nur WLAN AP oder VoIP Anlage?!). Vermutlich sind aber diese Komponenten für die VPN Kopplung nicht relevant (geraten).

"Richtig geraten"
....für VLAN20 ist auf der pfSense DHCP eingerichtet und dort ist mit IP 10.20.200.254 eine 7490 als WLAN-AP und Telefonanlage integriert.

Die Verbindung aus dem VLAN20 Netz, zur Remoten 7590 funktioniert.
Die Verbindung aus dem VLAN10 Netz, funktioniert nicht.
Testweise hatte ich VLAN10 DHCP aktiviert, aber auch da komme ich nicht in's remote .55.0/24 er LAN der 7590.

Alle Einstellungen, Firewall, NAT sind für beide VLAN's gleich und die entsprechenden Routen im OpenVPN-Server als Routen hinterlegt.
Remote war einst eine 7412 als Router am 1&1 Netz, diese wurde nun durch eine 7590 ersetzt.
Hinter diesem Router war ein E4200 OpenWRT in der Routerkaskade, der als OpenVPN-Client, WLAN und Homenetz bereit stellte.
Um diese OpenVPN-Verbindung zur Einstellung der vorgeschalteten Fritzbox zu nutzen, habe ich die Konfiguartion nur geringfügig geändert, um nicht zu viel im LAN verändern zu müssen.
Die 7412 hatte einst das Netz 192.168.2.0/24, die neue Fritte das einstige Homenetz des E4200, 192.168.55.0/24 DHCP, weil Sie als einziger Router verbleiben soll.
Der WAN des E4200 hängt nun "vorübergehend" im LAN der 7590, mit IP 192.168.55.222 außerhalb des DHCP-Range der Fritte und hat als LAN das Netz 192.168.18.0/24 statisch.
Alles wurde entsprechend angepasst und sollte auch stimmen, denn der Zugriff von VLAN20 sollte dem Recht geben.
Die Pings von VLAN20 gehen bis zum Netz 192.168.55.0/24 durch, vom VLAN10 nur bis zum LAN des E4200, 192.168.18.0/24.
Anscheinend wird auf dem E4200 etwas geblockt, was aus dem VLAN10 kommt, warum auch immer?
Gruß orcape

Eventuell Wireguard, denn das kann die 7590 mit der aktuellen Firmware nun wohl auch.

Denk dran das da AVM (mal wieder) sein eigenes Süppchen kocht und die Konfig deutlich von der WG dokumentierten Konfig abweicht. Siehe dazu hier.
IPsec ist da vermutlich die deutlich bessere Wahl.

Eine bereits existierende, funktionierende OpenVPN-Verbindung, 10.10.8.0/24

Das ist das interne OVPN IP Netz??

soll zum einrichten der remoten 7590 verwendet werden.

Diese hat dann eine entsprechende statische Route in das Netz und auch die anderen 10er IP Netze?? (Bzw. eine Summary Route in alle 10er Netze)

Die Verbindung aus dem VLAN10 Netz, funktioniert nicht.

Ggf. fehlende statische Route in der remoten 7590er?
OpenVPN - Erreiche Netzwerk hinter Client nicht

Der WAN des E4200 hängt nun "vorübergehend" im LAN der 7590, mit IP 192.168.55.222

Ist sichergestellt das du kein NAT im Tunnel selber machst. OK, bei der pfSense ist das ausgeschlossen aber der E4200? Entscheidend ist mit welcher Absender IP Pakete an der neuen FB ankommen.

Anscheinend wird auf dem E4200 etwas geblockt, was aus dem VLAN10 kommt

Möglich, aber warum klappt es denn mit dem VLAN 20 was ja auch eine 10er IP hat. Das würde dem widersprechen. Es sei denn natürlich du hast dich irgendwo mit der Subnetzmaske in den Routing Kommandos verhauen. 😉
Ggf. solltest du mal einen Wireshark PC ins .55er Netz klemmen und versuchen den über das VPN anzusprechen um erstmal genau zu sehen ob überhaupt Pakete aus dem VPN an Zielen im 55er Netz ankommen und welche Absender IPs die haben. Besonders für das nicht funktionierende 10er VLAN.

Hi aqui,
was lange währt, wirft manchmal auch noch mehr Fragen auf.

Nach langen, vergeblichen Versuchen und unendlichen Einstellungsversuchen, das VLAN-Zugriffsproblem zu lösen, bin ich zu dem Schluß gekommen, das ich wohl die Zeit eher in IPSec investieren werde und mich an mein Elitebook im VLAN 20 setze. Auch wenn der 27" er am PC gegenüber 14" wohl die bessere Wahl wäre.
Der Übersicht halber habe ich noch mal einen kleinen Netzwerkplan angefügt.

Der Stand der Dinge....
Ping von der pfSense....

VLAN 20 ins Netz 192.168.55.0/24 Ok
VLAN 10 ins Netz 192.168.55.0/24 keine Verbindung/ nur bis ins LAN 192.168.18.0/24

OVPN-Server ins Netz 192.168.55.0/24 Ok

Seltsam nicht wahr. Denn wenn das ein Problem des Routings auf dem E4200 wäre, würde ich auch vom OpenVPN-Server keinen Ping ins LAN 192.168.55.0/24 erfolgreich absetzen können.
Nun bin ich bei der von Dir verlinkten Seite....
Wireguard

auf etwas gestoßen, was eventuell die Ursache erklären könnte, denn sonst bin ich mit meinem Latein am Ende.

Probleme:
a) Die Assistenten der Fritze unterstützen keine verschiedenen vLANs der Gegenseite

Kommt die neue Plastekiste (Fritte7590) mit den remoten VLAN 's nicht klar?
Ist halt eine Fritzbox.

Gruß orcape

Kommt die neue Plastekiste (Fritte7590) mit den remoten VLAN 's nicht klar?

Doch das kann sie. Für die Fritze ist ja lediglich einzig nur die Route interessant. Sie partizipiert ja nicht im VPN Routing das obliegt ja ganz allein dem OpenVPN Server und Client.
Wichtig ist lediglich nur das die FB das jeweilige OpenVPN Gerät auf jeder Seite routingtechnisch erreichen kann und ihre statischen Routen dahin stimmen. Sprich bei der 7590 muss stehen:

Ziel: 10.100.0.0 Maske: 255.255.255.0, Gateway: 192.168.55.222
Ziel: 10.200.0.0 Maske: 255.255.255.0, Gateway: 192.168.55.222
Ziel: 10.10.8.0 Maske: 255.255.255.0, Gateway: 192.168.55.222
(Ziel: 192.168.18.0 Maske: 255.255.255.0, Gateway: 192.168.55.222)

Letztere kann vermutlich entfallen da der E4200 wohl fest NAT macht von seinem lokalen LAN. Die FB "sieht" also niemals Traffic aus dem .18.0er Netz.

Die OVPN Konfig Dateien wären noch hilfreich fürs Troubleshooting.
Ideal ein FritzBox Trace an deren LAN Port um mal zu sehen ob dort überhaupt Absenderpakete aus dem 10.100er Netz auftauchen.
Zu vermuten ist das der E4200 die 10.100er Route nicht in seine Routing Tabelle aufnimmt die er ja per Push Kommando vom OVPN Server bekommt!
Hilfreich wäre wenn du da mal die Routing Tabelle bei aktivem Tunnel ausgeben könntest. Fehlt das 10.100er Netz dort liegt da der Fehler.
Du könntest da auch testweise mal ein push "route 10.0.0.0 255.0.0.0" im Server setzen was dann alle 10er Netze vom E4200 in den Tunnel zur pfSense routet.

Letztlich ist das Leben in deinem Setup mit dem IPsec Tunnel und ohne E4200 Kaskade deutlich leichter. 😉

Hi aqui,
per ssh komme ich logischerweise, vom VLAN 10 ebenfalls nur auf das .18.0 LAN des E4200.
Von da aber per ssh ins WAN .55.222.
Traceroute zur Fritzbox...

root@winnie:~# traceroute 192.168.55.1
traceroute to 192.168.55.1 (192.168.55.1), 30 hops max, 38 byte packets
 1  wpad.fritz.box (192.168.55.1)  0.709 ms  0.717 ms  0.560 ms

Da die Fritte weder ssh noch telnet mag....?
OVPN-Server.conf pfSense....

dev ovpns1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 87.175.72.4
engine rdrand
tls-server
server 10.10.8.0 255.255.255.0
client-config-dir /var/etc/openvpn/server1/csc
ifconfig 10.10.8.1 10.10.8.2
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'dedalus' 1"  
lport 1194
management /var/etc/openvpn/server1/sock unix
max-clients 15
push "route 10.100.10.0 255.255.255.0"  
push "route 10.200.20.0 255.255.255.0"  
push "route 172.16.7.0 255.255.255.0"  
push "route 10.12.7.0 255.255.255.0"  
push "route 10.10.4.0 255.255.255.0"  
push "route  0.0.0.0"  
remote-cert-tls client
route 192.168.55.0 255.255.255.0
route 192.168.18.0 255.255.255.0
route  0.0.0.0
capath /var/etc/openvpn/server1/ca
cert /var/etc/openvpn/server1/cert
key /var/etc/openvpn/server1/key
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server1/tls-auth 0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-GCM
allow-compression no
topology subnet
explicit-exit-notify 1
push "route 172.16.7.0 255.255.255.0"  
push "route 10.0.0.0 255.0.0.0"  

Du siehst also, push "route 10.0.0.0 255.0.0.0" ist doppelt gemoppelt, da oben schon vorhanden.

Routing Tabelle des E4200....

root@winnie:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.10.8.1       255.255.255.255 UGH   0      0        0 tun0
default         wpad.fritz.box  0.0.0.0         UG    0      0        0 eth1
10.10.4.0       10.10.8.1       255.255.255.0   UG    0      0        0 tun0
10.10.8.0       *               255.255.255.0   U     0      0        0 tun0
10.12.7.0       10.10.8.1       255.255.255.0   UG    0      0        0 tun0
10.100.10.0     10.10.8.1       255.255.255.0   UG    0      0        0 tun0
10.200.20.0     10.10.8.1       255.255.255.0   UG    0      0        0 tun0
172.16.7.0      10.10.8.1       255.255.255.0   UG    0      0        0 tun0
192.168.18.0    *               255.255.255.0   U     0      0        0 eth0
192.168.55.0    *               255.255.255.0   U     0      0        0 eth1

...sollte auch stimmen.

Die Routen habe ich komplett so in die 7590 eingetragen...

    Ziel: 10.100.0.0 Maske: 255.255.255.0, Gateway: 192.168.55.222
    Ziel: 10.200.0.0 Maske: 255.255.255.0, Gateway: 192.168.55.222
    Ziel: 10.10.8.0 Maske: 255.255.255.0, Gateway: 192.168.55.222
    (Ziel: 192.168.18.0 Maske: 255.255.255.0, Gateway: 192.168.55.222)

und.....nichts geht.
Ist mir echt ein Rätsel.

...kleiner Nachtrag.
Die eingerichtete Portfreigabe auf der 7590, Port 1194 auf die IP 192.168.55.222, die normalerweise für den OpenVPN-Client gar nicht erforderlich ist, kann sich da nicht auswirken.
Die ist ja normalerweise nur für die Serverseite in solch einer Konstellation nötig.

Da die Fritte weder ssh noch telnet mag....?

Doch mag sie. Zumindestens Telnet auf den Port TCP 80 was dir dann HTML im Telnet Fenster zurückgibt. 😉

OVPN-Server.conf pfSense....

Da sind die Push Route Kommandos dann doppelt gemoppelt. Das ist nicht so dolle und ein Fehler weil dann die "engere" Maske gewinnt. (Prefix Length).
Auch das push route 0.0.0.0 ist da ziemlich irreführend. Dieses Kommando ist eigentlich Unsinn und auch kontraproduktiv wenn man mit Split Tunneling arbeitet. Deshalb hat der E4200 dann auch 2 default Routen was eigentlich falsch ist, denn du nutzt ja Split Tunneling im OpenVPN.
Ebenso das route 0.0.0.0 und auch die beiden route Kommandos für das .18er und .55er Netz. Die gehören nicht in die Kernel Routing Tabelle des Servers. Besonders route 0.0.0.0 nicht.
Das ist alles etwas wirr in der OVPN Konfig.

für den OpenVPN-Client gar nicht erforderlich ist, kann sich da nicht auswirken.

Das ist richtig, die ist obsolet. Hat aber keinerlei Einfluss, denn die IP Pakete sind ja in ein UDP 1194 OVPN Frame enkapsuliert. Die FB "sieht" also an dem Punkt gar nichts von den 10er Adressen. Die kommen ja erst am OpenVPN wieder "zum Vorschein".
Hast du den OpenVPN Traffic vom NAT in der OpenWRT Firewall ausgenommen?!

Hi,
das mit der Aktivierung von telnet habe ich gerade gelesen. Wird aber wohl nicht empfohlen, zumindest nicht dauerhaft.

Da sind die Push Route Kommandos dann doppelt gemoppelt. Das ist nicht so dolle und ein Fehler weil dann die "engere" Maske gewinnt.

Hatte ich nur testweise auf Deine Empfehlung in die "Advanced Configuration" eingefügt und weil es nix gebracht hat, wieder raus genommen.

Auch das push route 0.0.0.0 ist da ziemlich irreführend.

Gute Frage, die ist aber von mir im GUI definitiv nicht eingetragen und dort auch nirgends zu sehen. Das macht die pfSense wohl selbsttätig. Ebenso alle anderen 0.0.0.0 Kommandos.

Das ist richtig, die ist obsolet.

Alles gut. Ich wollte die nur erst einmal drin lassen, da ich derzeit nur remote durch die "Hintertür" an die Kiste komme und kein unnötiges Risiko eingehen wollte. Denn ich habe zwar ein Dyn-Account eingetragen, der funktioniert auch, aber ohne sich bei AVM zwecks Fernzugang zu registrieren, scheint man da direkt nicht drauf zu kommen. Da ist so ein DD-WRT-/ OpenWRT-Router schon flexibler.

Hast du den OpenVPN Traffic vom NAT in der OpenWRT Firewall ausgenommen?!

Genau so sieht das bei mir aus, nur das da keine Gastzone existiert, wozu auch.

Nun ist mir trotzdem völlig unklar, wieso ich vom OpenVPN-Server (10.10.8.1) auf das LAN der Fritte komme, nicht aber vom VLAN 10.100.10.1, welches ja aber Verbindung zum OpenVPN-Server hat und auch die Routen eingetragen sind.
Hat die Fritte Alzheimer, das die sich nicht alle Ip 's merken kann?

Nun ist mir aber immer noch nicht

das mit der Aktivierung von telnet habe ich gerade gelesen. Wird aber wohl nicht empfohlen

Du musst ja kein Telnet aktivieren! Es reicht wenn du einen Telnet Client hast. Wenn du einen HTTP Server irgendwo hast kannst du den über Port 80 Telnetten und siehst dann ob da was "lebt". Quasi der Ping mit TCP 80. 😉

Nun ist mir trotzdem völlig unklar, wieso ich vom OpenVPN-Server (10.10.8.1) auf das LAN der Fritte komme, nicht aber vom VLAN 10.100.10.1

Gut...IP technisch ist das leicht zu erklären.
Vom VPN Server nutzen deine Ping Pakete eine 10.10.8.1 Absender IP sprich für die Rückroute muss auch dieses Netz erreichbar sein.
Sendest du allerdings aus dem 10.200.10.0er oder 10.100.10.0er Netz hast du eine Absender IP aus diesem Netz. Aus irgendwelchen unerfindlichen Gründen verschluckt aber einer der beteiligten 10.100.10.0er Frames. Die Frage ist jetzt WO...???

Nun ist mir aber immer noch nicht

Was ist dir nicht???

Ich denke du lässt das Forschen mit OpenVPN, entsorgst den E4200 und setzt einen IPsec Tunnel auf. Das bringt dir mehr Zeit für vorweihnachtlichen Glühwein, Lebkuchen und Kekse!! 😉

Oh mein Gott, wieder 2 Kilo mehr.

Aber ansonsten ein gute Idee.
Danke, ich werde dran arbeiten.

Gruß orcape

Ich vermute das am WAN Port des E4200 noch irgendwas firewallmäßiges aktiv ist was ggf. den Reply Traffic blockiert. Das ist bei solchen "vorgefertigten" Appliances fast immer der Fall und deshalb ist es nie eine gute Idee die one armed anzubinden.
Möchte wetten das mit einem simplen OpenVPN Client wie z.B. einem RasPi o.ä. diese Problematik nicht auftaucht. But who cares? Go for IPsec!

But who cares? Go for IPsec!

Genau. Das Thema hat sich gestern Abend nun endgültig erledigt.
Nachdem ich von mir aus, die IPSec.conf auf dem Frittenkasten eingespielt habe, stand auch schon ein Teil des Tunnels. Ist also in Arbeit. Leider muß ich da immer telefonisch die Verwandtschaft "wecken", das die mir solche Änderungen am Fritzkasten bestätigt.
Ich hatte eigentlich vor etwas Ordentliches, in Form eines APU's nebst pfSense einzubauen, aber dann wären zusätzlich noch die 7412 als pppoE-Passthrough Modem nötig geworden und die 7590 hätte Telefondienst nebst WLAN gemacht.
Aber die Kosten und der Stromverbrauch sprachen dagegen.
Da rückt dann schon die Sicherheit mal etwas nach hinten, vor allem wenn die Leut's davon Null Plan haben.

Aber des Menschen Wille ist nun einmal sein Himmelreich.

Hier ein Bilderbuchsetup mit einer FritzBox und pfSense/OPNsense unter Nutzung von dynamischen DNS Adressen (DDNS) auf beiden Tunnelseiten.

Für den Funktionstest wurden hier nip.io Host- bzw. Domainnamen verwendet die die DDNS Adressen simulieren. Die müssten dann im Setup mit den verwendeten DDNS Hostadressen ersetzt werden.
pfSense Adressierung:
LAN/VLAN: 10.100.1.0 /24
WAN: 0a630163.nip.io (10.99.1.99)
FritzBox Adressierung:
LAN: 192.168.1188.0 /24
WAN: 0a630195.nip.io (10.99.1.149)

⚠️ Die FritzBox arbeitet hier mit dem sicheren IPsec Main Mode (mode = phase1_mode_idp;) statt dem im Default bei Fritzboxen sonst üblichen Agressive Mode (mode = phase1_mode_aggressive;)
Das VPN funktioniert fehlerlos mit beiden Modi.

Interessant und wichtig ist in dem Setup das die FritzBox 7390 kein SHA256 und DH14 in P1 und P2 supportet!!
Zumindestens bei diesem Modell muss man also bei den Krypto Credentials aufpassen!
Maximal geht, zumindestens bei der FritzBox 7390, für Phase1 und Phase2 nur SHA1 und DH2 bei AES256 Verschlüsselung.
Man sollte also, um auf Nummer sicher zu gehen, immer mit diesen Krypto Credentials beginnen damit der Tunnel sicher aufgebaut wird. Wenn alles klappt kann man später diese Werte bei Bedarf hochsetzen.

Table of contents

pfSense Phase 1 Setup

pfSense Phase 2 Setup

pfSense Tunnel Status

VPN Konfig Datei zum Import in die FritzBox

FritzBox Status und Ping Check

pfSense Phase 1 Setup

pfSense Phase 2 Setup

pfSense Tunnel Status

VPN Konfig Datei zum Import in die FritzBox

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 = "0a630195.nip.io";  
                }
		remotehostname = "0a630163.nip.io";  
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        fqdn = 0a630163.nip.io;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "test1234";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.188.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 10.100.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
                accesslist = "permit ip any 10.100.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";  
} 

FritzBox Status und Ping Check

Fazit: Works as designed!! 😉

Jepp,
bis auf die krypto keine Abweichung.
Sollte also eigentlich funktionieren. Testweise hatte ich auch Hash und DH-Group, Deinen Einstellungen angepasst, gleiches Ergebnis.
Ich werde morgen mal den MyFrirtz DNS-Zugang testen.
Wireguard scheint auch nur damit zu funktionieren.
Fritzbox7590, kryptisch wie ein Tunnel.

Gruß Peter

Hi Aqui,
nach langem Gefrickel bin ich zu dem Ergebnis gekommen, das AVM wohl mehr verspricht, wie mit dem Kasten möglich ist.
Ein Bild sagt mehr als tausend Worte.....

Die von AVM für die 7590 unterstützten Standards und Algorithmen, spielen wohl alle nicht wirklich so richtig mit, zumindest nicht unter meinen Bedingungen.
Gruß orcape

"Established" sieht ja erstmal gut aus! 👍
Bestätigt aber ein bischen den Verdacht das zumindestens SHA256 und DH14 nicht zusammen laufen. Zumindestens SHA256 scheint sie ja im Gegensatz zur 7390 zu akzeptieren. DH14 wohl immer noch nicht obwohl AVM was anderes sagt:
https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7590/3331_FRITZ-Bo ...
Die 7390 kann zumindestes SHA256 und DH14 im Main Mode keiner einzigen Kombination. Da scheitert der Tunnelaufbau sofort. Beim Agressive Mode dürfte das auch so sein.

Hier kommt in Kurzform noch einmal das IPsec FritzBox - pfSense/OPNsense VPN Setup Update für eine Konfig mit 2 Subnetzen (VLANs) auf der pfSense Seite.
VLAN 1 = 10.100.1.0 /24
VLAN 2 = 192.168.1.0 /24
Auch hier wieder getestet mit beiden IPsec Modi IPsec Main Mode (Fritz Konfig: "mode = phase1_mode_idp";) und Agressive Mode ((Fritz Konfig: "mode = phase1_mode_aggressive;")und klappt beides fehlerlos:

Table of contents

FritzBox VPN Konfig Datei mit 2 remoten VPN Netzen

FritzBox Status

pfSense Setup (Kurzform)

pfSense IPsec Status

Ping Check aus dem FritzBox Netz

FritzBox VPN Konfig Datei mit 2 remoten VPN Netzen

(Beschreibung mit zwei (oder mehr) IP Netzen HIER in der AVM VPN Wissensdatenbank)

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;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "0a630163.nip.io";  
                keepalive_ip = 0.0.0.0;
                localid {
                        fqdn = "0a6301c7.nip.io";  
                }
                remoteid {
                        fqdn = "0a630163.nip.io";  
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "test1234";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.188.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 10.100.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
                accesslist = "permit ip any 10.100.1.0 255.255.255.0",  
			     "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";  
} 

FritzBox Status

pfSense Setup (Kurzform)

Tunnel Peer Adressen:

pfSense, Source: 0a630163.nip.io = 10.99.1.99
FritzBox, Destination: 0a6301c7.nip.io = 10.99.1.199

Setup ist mit dem Copy Button lediglich um eine weitere P2 erweitert worden wie die obige.

pfSense IPsec Status

Ping Check aus dem FritzBox Netz

10.100.1.101 = Server im VLAN 2
192.168.1.2 = Switch im VLAN 1 (Management)

Table of contents

FritzOS 7.51 IPsec Proposal (Log der pfSense / OPNsense)

P2 mit SHA1 und/oder SHA512

Stabile P1 / P2 Settings für FritzOS 7.51 (FB 7490)

Phase 1

Phase 2

FritzBox 7490 VPN Konfig Datei (v. 7.51)

Hier die VPN "Forschungsergebnisse" mit einer FritzBox 7490 und der aktuellen Firmware Ver. 7.51 Beta:

Um es gleich vorweg zu nehmen. Die o.a Konfig funktioniert auch mit FritzOS 7.51 erwartungsgemäß ebenso fehlerlos mit einer pfSense und auch OPNsense.
Allerdings sind ein paar Dinge der Konfig Datei leicht kosmetisch unterschiedlich:

Der Parameter "ike_forward_rules" fehlt im cfg Output der Fritzbox. AVM hat diese FW Regeln wohl fest in die Firewall implementiert
Es taucht interessanterweise ein "use IKEv2" Kommando in der cfg Datei auf. Ein IKEv2 Versuch scheitert aber zumindestens bei ein Site-to-Site Verbindung. Vermutlich ist das wohl nur mit MOBIKE aktiv für VPN Client Dialin der aktuellen onboard IKEv2 Clients.
Die Wireguard VPN Konfig Kommandos sind im VPN Abschnitt mit integriert.

Bei den IPsec Krypto Profilen muss man das Fehlen von SHA256 beachten! Derzeit sind nur SHA512 und SHA1 supportet. Zumindest in der derzeitigen 7.51 auf dem 7490 Modell.

Hier die Auswertungen:

FritzOS 7.51 IPsec Proposal (Log der pfSense / OPNsense)

pfSense / OPNsense ist mit Main Mode und AES256, SHA256, DH14 in P1 und P2 eingestellt was scheitert:

Hier sieht man auch klar was der Grund des Scheiterns ist.
Es gibt mit den Defaults der Phase 1 (phase1ss = "all/all/all";) keinen DH14 (modp2048) Support in den angeboteten (received) Proposals der FritzOS Firmware 7.51. Das sicherere AES-GCM ist gar nicht supportet. Dafür dann aber so olle Kamellen wie das unsichere DES und 3DES aus der VPN Steinzeit.
Man erkennt hier auch das die Profile damit nur modp1024 (DH Group2) kennen. Für DH14 (modp2048) Support muss man die FritzBox VPN Konfig anpassen! ( phase1ss = "dh14/aes/sha"; )
Im Aggressive Mode werden die gleichen Proposal verwendet wie auch hier im Main Mode. Man hat also die Wahl:

phase1ss = "all/all/all"; = AES128/192/256, SHA1, SHA512, DH2
phase1ss = "LT8h/all/all/all"; = wie oben nur P1 Lifetime 8 Stunden
phase1ss = "dh14/aes/sha"; = AES128/192/256, SHA1, SHA512, DH14

Mit nur SHA256 Hashing scheitert ein Tunnelaufbau. Verständlich, denn laut o.a. Proposals kann die FritzBox nur SHA512 oder SHA-1!
Die Änderung des Hashings auf SHA512 oder SHA-1 bei Beibehaltung von DH2 bringt dann den gewünschten Erfolg:

SHA512 ist natürlich immer vorzuziehen bzw. wählt die FritzBox erwartungsgemäß auch automatisch wenn man beides anbietet.

P2 mit SHA1 und/oder SHA512

Auch die P2 scheitert wenn man einzig nur SHA256 erzwingt. Auch das verständlich, da nicht supportet.
Erst wenn SHA1 und/oder SHA512 angeboten wird in P1 und P2, entscheidet sich die FritzBox dann erwartungsgemäß für das bessere SHA512 und startet den Tunnel. Siehe auch HIER!

Stabile P1 / P2 Settings für FritzOS 7.51 (FB 7490)

Mit diesen pfSense / OPNsense Settings bekommt man bei der derzeitigen 7.51 Beta (Modell 7490) einen stabilen Tunnel aufgebaut:

Phase 1

Phase 2

Auch DH Group 14 (modp2048) Support ist mit einer Änderung des Parameters phase1ss umzusetzen! (Siehe unten!)
Ein Quercheck des FritzBox Verhaltens mit einem Cisco ISR Router und einem Linux Strongswan Host bestätigt das o.a. Verhalten.
Es ist also davon auszugehen das es auch für alle anderen IPsec Endgeräte gilt.
DPD ist im im pfSense/OPNsense Setup wie auch bei Cisco und Strongswan aktiv!

FritzBox 7490 VPN Konfig Datei (v. 7.51)

Hier die zum Testen verwendete Konfig.
Der Test mit 2 Phase 2 Einträgen für zwei oder mehr IP Netze auf der Firewall Seite, wie oben schon gepostet, verlief ebenso fehlerfrei und stabil.

vpncfg {
        connections {
                enabled = yes;
                editable = yes;
                use_ikev2 = no;
                conn_type = conntype_lan;
                name = "pfSense";  
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = no;
                localip = ::;
                remoteip = ::;
                local_virtualip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "0a630163.nip.io";  
                keepalive_ip = 0.0.0.0;
                localid {
                        fqdn = "0a0b01c7.nip.io";  
                }
                remoteid {
                        fqdn = "0a630163.nip.io";  
                }
                mode = phase1_mode_idp;
                phase1ss = "dh14/aes/sha";  
                keytype = connkeytype_pre_shared;
                key = "test1234";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.188.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";  
        }
} 

Das Fazit was man ziehen kann ist zumindestens akribisch auf die IPsec Krypto Profile zu achten bei Verbindungen auf andere Hersteller.
Bei IPsec Setups mit FritzOS 7.51 derzeit nur die Einstellungen SHA-512 bzw. SHA-1 und DH14 bzw. DH2 zu wählen!
Die sichere Kombination ist SHA-512, DH14 in beiden Phases. Man riskiert damit aber das ältere FB Modelle die nur SHA-1 supporten nicht verbinden können. Es ist also sehr sinnvoll in VPN Umgebunden mit FritzBoxen immer beide Proposals in der OPNsense/pfSense oder anderen herstellerfremden IPsec Endgeräten anzubieten.

Alles in allem bestätigt die aktuelle 7.51 aber das positive Fazit vom Heise Ticker.

Hi,
zum Thema 7590 mit v. 7.50 und IPSec annähernd das gleiche Spiel, wie bei @aqui, nur das AVM das in Sachen Zugriff auf das Innenleben der Box, noch etwas erschwert hat.
Ein Aufbau eines IPSec-Tunnels durch das einspielen der VPN.cfg-Datei über den GUI, ist, wie zuvor von mir beschrieben, nicht wirklich von Erfolg gekrönt und hat mir nur einen Tunnel im Aggessive-Modus mit SHA1, DH2 ermöglicht. Dieser war auch noch instabil.
Erst der Download der Config-Datei mit dem Fritzbox-Editor und dessen Bearbeitung, brachte die Möglichkeiten der Fritzbox zum Vorschein.
Leider ist es in Version 7.50 nicht mehr möglich den Editor zu nutzen, da einem AVM 's 2FA in die Suppe spuckt. Bei eingeschalteter 2FA, das heißt bei der 7590 v. 7.50, unter System-Fritzbox-Benutzer-Zusätzliche Bestätigung, lässt sich diese Funktion nicht mehr komplett abschalten und genau da spielt der fritzbox-Editor nicht mit. Eine Bestätigung reicht da nicht, 2FA muss abgeschaltet sein.
Letzlich hilft, nach eingespielter Aggressive.cfg, ein zurücksetzen der Box auf v. 7.29 und das komplette Abschalten von 2FA. Es erscheint eine Warnung im GUI, aber die Abschaltung von 2FA wird dann auch beim erneuten Upgrade auf 7.50 toleriert und im GUI angezeigt.
Ein Download der Config durch den Editor und deren Bearbeitung von...

mode = phase1_mode_idp;
                phase1ss = "all/all/all";  

auf...

mode = phase1_mode_idp;
                phase1ss = "dh14/aes/aha";  

Die Phase2 bleibt auf..

phase2ss = "esp-all-all/ah-none/comp-all/pfs";

Die Config abspeichern und mit dem Editor wieder auf die Box hochladen und voala....

Hier die Config auf der pfSense2.6.0.....

Wichtig ist, die beiden Einträge in der Phase 1 einzutragen.
Die Phase 2 funktioniert ebenfalls mit DH14.

DPD musste ich abschalten und einen Ping auf einen Remoten-Host (Drucker) setzen. Seitdem läuft das völlig stabil.

Vielleicht schafft es ja AVM auch irgendwann, das man die versprochenen Proposals auch über den GUI verfügbar macht und man sich das ganze Gefrickelt ersparen kann.
Mein Dank gilt hier neben @aqui, auch den Kollegen vom Netgate-Forum, die mich hier mit Ihrem Wissen, das Thema betreffend, unterstützt haben.

Immer gerne! 😊
Interessant ist in dem Zusammenhang vielleicht noch das die 7.51 der 7490 obwohl auch ein 7.5er Release kein 2FA kennt und man somit das o.a. Problem dort nicht hat.
Die 7490 mit 7.51 Beta reagiert aber (verständlicherweise) auf schwache Passwörter und das sowohl beim Einspielen der VPN cfg Datei als auch z.B. beim Export der Sicherungsdatei.
Bei schwachen Passwörtern wird eine Bestätigung entweder durch Knopfdruck oder Telefoncode erzwungen.
Das kann man aber auf der 7490 einfach umgehen wenn die Passwörter in der Online Prüfung ein "Gut" erhalten indem man Groß- Klein, Ziffern und Sonderzeichen verwendet. Dann entfällt diese Bestätigungsabfrage zumindestens auf der 7490. 😉

Für die obige 7.51 VPN Konfig Datei wurde auch kein Fritzbox-Editor o.ä verwendet. Das ist auch nicht unbedingt nötig, da das eine einfache Text Datei ist.
Zur Erstellung und Anpassung reicht ein einfacher, klassischer Text Editor wie z.B. Notepad++.

Table of contents

Ergänzung zu den FritzBox 7.51 Krypto Profilen!

Hashing mit SHA512

DH Group 14 (modp2048) aktivieren

Fritzbox VPN Lifetimes

Performance

Fazit

Ergänzung zu den FritzBox 7.51 Krypto Profilen!

Die anscheinende Begrenzung des Hashings auf SHA1 und das Fehlen des SHA256 Hashes verleitet zu glauben das generell keine höheren Hashing Standards mehr supportet sind. Der Proposal oben zeigt aber das die FB zumindestens SHA512 anbietet.
Und tatsächlich führt auch ein Test damit zum gewünschten Erfolg: 👍

Hashing mit SHA512

Ein Quercheck mit aktivem DH14 auf einem FritzBox Dialin VPN auf einem StrongSwan vServer sowie Cisco Router bestätigt auch dies:

admin@vserver:~$ swanctl -l
  fritzbox: #2, ESTABLISHED, IKEv1, f0bafbb1fb746b87_i 7b33403a8ad9283b_r*
  local  '212.1.2.3' @ 212.1.2.3[4500]  
  remote '73:74:73:6f:6e:62:73:77:61:6c:40:66:72:69:73:7a:3e:62:6f:78' @ 80.1.2.3[7840]  
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
  established 137s ago, rekeying in 3345s
  net: #1, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_512_256/MODP_2048
    installed 132s ago, rekeying in 3137s, expires in 3833s
    in  cd84d7f9,    512 bytes,     4 packets,   127s ago
    out 9825c00f,    512 bytes,     4 packets,   127s ago
    local  172.25.25.0/24
    remote 192.168.178.0/24 

Parallel dazu auch das FritzBox Log:

DH Group 14 (modp2048) aktivieren

Ändert man in der FritzBox VPN Konfig Datei den Parameter phase1ss auf phase1ss = "dh14/aes/sha"; lässt sich dann auch final DH14 aktivieren.

Fritzbox VPN Lifetimes

Die Fritzbox nutzt unübliche Lifetimes von 3600 Sek. in der P1. In der Regel nutzen Firewalls wie OPNsense, pfSense oder auch VPN Router hier üblicherweise 8 Stunden.
Hier kann es mit dem Gegenpart zu einem Lifetime Mismatch kommen, was sich oftmals in zyklisch abbrechenden VPN Tunneln äußert.
Um das sicher zu vermeiden und bei der Fritzbox auch auf die üblichen 8 Stunden zu kommen kann man in der VPN Konfig Datei das Kommando phase1ss = "LT8h/all/all/all"; anpassen was die P1 Lifetime entsprechend anpasst und Abbrüche verhindert. (Siehe z.B. hier)
Da die Fritzbox leider nicht flexibel konfigurierbar ist wie andere Hardware fällt man hier wieder auf DH2 zurück. Man muss sich also als Netzwerk Admin entscheiden.

Performance

Interessant sind ein paar iPerf3 Performance Tests mit der FritzBox (Modell 7490, Ver. 7.51):

SHA1 Hashing in P1 und P2

[ ID] Interval         Transfer     Bandwidth
[  5] 0.00-10.04  sec  23.4 MBytes  19.6 Mbits/sec  

SHA512 Hashing in P1 und P2

[ ID] Interval         Transfer     Bandwidth
[  5] 0.00-10.04  sec  12.7 MBytes  10.6 Mbits/sec 

SHA512 Hashing in P1 und SHA1 in P2

[ ID] Interval         Transfer     Bandwidth
[  5] 0.00-10.04  sec  23.6 MBytes  19.7 Mbits/sec 

SHA1 Hashing in P1 und SHA512 in P2

[ ID] Interval         Transfer     Bandwidth
[  5] 0.00-10.04  sec  12.6 MBytes  10.5 Mbits/sec 

Ob DH2 oder DH14 macht keinen Unterschied.

Fazit

Das Hashing und auch die DH Group lässt sich mit den o.a. Einstellungen auf SHA512 und DH14 erhöhen mit der 7.51.
Damit lässt sich ein gutes und ausreichend sicheres Krypto Profil mit IPsec mit der 7.5.1 auf der 7490 setzen.
Performanceseitig halbiert das SHA512 Hashing in der Phase 2 aber den IPsec VPN Durchsatz (zumindestens beim 7490er Modell). Wer also mehr VPN Durchsatz möchte muss die Kröte SHA1 in der Phase 2 schlucken.
Die gemessenen Werte entsprechen damit exakt denen die auch die c't in ihrem Test gemessen hat.

German solved Question Linux Network Networks Routers, Routing

Hotly discussed

Check of ZFW Firewallgleixnerd - 3 Comments

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

WIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 3 Comments

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment