orcape
Goto Top

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. face-wink

Gruß orcape

Content-Key: 4941192029

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

Printed on: March 23, 2023 at 03:03 o'clock

Member: aqui
Solution aqui Dec 13, 2022 updated at 10:04:12 (UTC)
Goto Top
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).

Member: orcape
orcape Dec 13, 2022 at 14:51:25 (UTC)
Goto Top
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
Member: aqui
Solution aqui Dec 13, 2022 updated at 17:21:18 (UTC)
Goto Top
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.
Member: orcape
orcape Dec 14, 2022 updated at 13:28:31 (UTC)
Goto Top
Hi aqui,
was lange währt, wirft manchmal auch noch mehr Fragen auf. face-wink
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.

diagramm1.

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. face-wink
Gruß orcape
Member: aqui
Solution aqui Dec 14, 2022 updated at 14:03:52 (UTC)
Goto Top
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. ๐Ÿ˜‰
Member: orcape
orcape Dec 14, 2022 at 15:03:57 (UTC)
Goto Top
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...
Da die Fritte weder ssh noch telnet mag....?
OVPN-Server.conf pfSense....
Du siehst also, push "route 10.0.0.0 255.0.0.0" ist doppelt gemoppelt, da oben schon vorhanden.

Routing Tabelle des E4200....
...sollte auch stimmen.

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

....und.....nichts geht.
Ist mir echt ein Rätsel.
Member: orcape
orcape Dec 14, 2022 at 15:42:03 (UTC)
Goto Top
...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.
Member: aqui
Solution aqui Dec 14, 2022 updated at 16:08:41 (UTC)
Goto Top
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?!
openwrt.
Member: orcape
Solution orcape Dec 14, 2022 at 16:56:37 (UTC)
Goto Top
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. face-wink
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
Member: aqui
Solution aqui Dec 14, 2022 at 18:17:24 (UTC)
Goto Top
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!! ๐Ÿ˜‰
Member: orcape
orcape Dec 14, 2022 at 19:43:03 (UTC)
Goto Top
Oh mein Gott, wieder 2 Kilo mehr. face-wink
Aber ansonsten ein gute Idee.
Danke, ich werde dran arbeiten. face-wink
Gruß orcape
Member: aqui
aqui Dec 15, 2022 at 09:59:57 (UTC)
Goto Top
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!
Member: orcape
orcape Dec 15, 2022 at 11:02:33 (UTC)
Goto Top
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. face-sad
Aber des Menschen Wille ist nun einmal sein Himmelreich. face-wink
Member: aqui
Solution aqui Dec 26, 2022, updated at Jan 05, 2023 at 10:24:49 (UTC)
Goto Top
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)


ACHTUNG: 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.

back-to-toppfSense Phase 1 Setup


pfsense-phase1


back-to-toppfSense Phase 2 Setup


pfsense-phase2


back-to-toppfSense Tunnel Status


pfsensestatus


back-to-topFritzBox VPN Konfig Datei



back-to-topFritzBox Status und Ping Check


ipsecfb1

Fazit: Works as designed!! ๐Ÿ˜‰
Member: orcape
orcape Dec 26, 2022 at 19:26:20 (UTC)
Goto Top
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. face-wink
Gruß Peter
Member: orcape
orcape Dec 30, 2022 at 16:22:04 (UTC)
Goto Top
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
screenshot_20221230_161044
Member: aqui
aqui Dec 30, 2022 at 18:08:15 (UTC)
Goto Top
"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.
Member: aqui
aqui Jan 04, 2023, updated at Jan 09, 2023 at 09:48:25 (UTC)
Goto Top
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:

back-to-topFritzBox VPN Konfig Datei

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

back-to-topFritzBox Status

fb1

back-to-toppfSense 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.
fb3

back-to-toppfSense IPsec Status

fb2

back-to-topPing Check aus dem FritzBox Netz

10.100.1.101 = Server im VLAN 2
192.168.1.2 = Switch im VLAN 1 (Management)
fbcheck
Member: aqui
aqui Jan 19, 2023, updated at Mar 02, 2023 at 09:41:17 (UTC)
Goto Top
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:

back-to-topFritzOS 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:
751fehler
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.

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:
751fehler2
SHA512 ist natürlich immer vorzuziehen bzw. wählt die FritzBox erwartungsgemäß auch automatisch wenn man beides anbietet.

back-to-topP2 mit SHA256 und SHA512

Auch die P2 scheitert wenn man einzig nur SHA256 erzwingt. Auch das verständlich, da nicht supportet.
Erst wenn SHA1 und 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!
751p2fehler

back-to-topStabile 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:

back-to-topPhase 1

p1settings

back-to-topPhase 2

p2settings
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!

back-to-topFritzBox 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.

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.
Member: orcape
orcape Jan 19, 2023 at 18:26:41 (UTC)
Goto Top
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...
auf...
Die Phase2 bleibt auf..
Die Config abspeichern und mit dem Editor wieder auf die Box hochladen und voala....

ipsec_status

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

ipsec_tunnels

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.
Member: aqui
aqui Jan 19, 2023 updated at 19:09:50 (UTC)
Goto Top
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++.
Member: aqui
aqui Jan 21, 2023, updated at Feb 16, 2023 at 16:39:54 (UTC)
Goto Top

back-to-topErgä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: ๐Ÿ‘

back-to-topHashing mit SHA512

fb512

Ein Quercheck mit aktivem DH14 auf einem FritzBox Dialin auf einem StrongSwan vServer sowie Cisco Router bestätigt auch dies:
Parallel dazu auch das FritzBox Log:
fblog

back-to-topDH Group 14 (modp2048) aktivieren

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

back-to-topPerformance

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

SHA1 Hashing in P1 und P2

SHA512 Hashing in P1 und P2

SHA512 Hashing in P1 und SHA1 in P2

SHA1 Hashing in P1 und SHA512 in P2

Ob DH2 oder DH14 macht keinen Unterschied.

back-to-topFazit

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 den IPsec VPN Durchsatz (zumindestens beim 7490er Modell). Wer also mehr Durchsatz möchte muss die Kröte SHA1 in der Phase 2 schlucken.
Die gemessenen Werte entsprechen damit exakt denen die auch die ct' in ihrem Test gemessen hat.