28
S2S-Wireguard: AVM zu Mikrotik
Ein gesegnetes Hallo in die ehrenwerte Runde am Tag der "Männer" 
S2S-Wireguard: AVM/Fritze - Mikrotik
hat das jemand - funktionierend - am fliegen?! Bisher lief das ganze nicht direkt auf der Fritze sondern einem hintergeschalteten MT-AP. Mit entsprechendem Routing. Jetzt wollte ich dieses Gerät anders nutzen und das Setup gleichzeitig glattziehen.
Vorgehen:
1. Schlüssel von https://www.wireguardconfig.com erstellen lassen (für beides Seiten)
2. MT-Interface und -Peer angelegt
3. Config-Datei für FB manuell vorbereitet und dann dort unter
4. "Benutzerdefinierte Einrichtung" > ... auf Gegenstelle erstellt JA > NetBIOS JA importiert
5. Manuelles routing und bisherige FW-Port vom alten WG-Setup auf der Fritze gelöscht
Probleme:
a) Die Assistenten der Fritze unterstützen keine verschiedenen vLANs der Gegenseite
b) importiert man das obere config-File über ne bestehende IPSec-Verbindung aus der Ferne werden die Daten nicht richtig importiert
c) zwei DNS-Einträge werden automatisch vorgenommen (fritz.box & lokale IP der Fritze) auf die man keinen Einfluss hat
d) der im conf-File vordefinierte FW-Port wird abgeändert
e) ich komme zwar vom lokalen Fritzbox-Netzwerk in die vLANs des MT ... anders herum endet der Zugriff aber auf der Fritze ... und hier konkret auf der WG-internen NAT-Adresse der Fritze (10.98.200.2). Wie kann ich den Knoten lösen?
f) Beim Wechsel der WAN-IP an der Fritzbox bricht die WG-Verbindung zusammen und baut sich auch nicht mehr auf. Ok, auf MT-Seite hatte ich vergessen ein entsprechendes Skript zu modifizieren aber warum macht das die Fritze nicht von ihrer Seite aus?!
WG-NAT:
Wenn ich das richtig gesehen habe, legt der AVM Wireguard-Assistent kein NAT für Wireguard an, sondern die Fritze behält innerhalb eines von ihr kreierten Tunnel-Setups in meinem Fall 192.168.66.1, etwaige Gegenstellen bekommen offenbar eine IP außerhalb des lokalen DHCP-Bereichs.
Bei meinem manuellen Setup, das ich oben beschrieben habe, nutze ich aber die 10.98.200.1 & 2 /29. Ist das ggfs. ein Problem für die Fritzbox?! Sie ergänzt das Setup eigenständig zu:
Address = 192.168.66.1/26,10.98.200.2/29
Müsste ich in dem Fall dem MT-WG-Interface eine IP aus 192.168.66.0/26 vergeben?!
Fritzbox:
Mikrotik:
(Anmerkung: Keys alle mittig gekürzt, ebenso Endpoints anonymisiert)
PS: Bestimmt ne doofe Frage:
Bisher hatte ich nur ne FW-Input-rule (Src 192.168.66.0/26, udp, 51888) konfiguriert. Genügt das?
S2S-Wireguard: AVM/Fritze - Mikrotik
hat das jemand - funktionierend - am fliegen?! Bisher lief das ganze nicht direkt auf der Fritze sondern einem hintergeschalteten MT-AP. Mit entsprechendem Routing. Jetzt wollte ich dieses Gerät anders nutzen und das Setup gleichzeitig glattziehen.
Vorgehen:
1. Schlüssel von https://www.wireguardconfig.com erstellen lassen (für beides Seiten)
2. MT-Interface und -Peer angelegt
3. Config-Datei für FB manuell vorbereitet und dann dort unter
4. "Benutzerdefinierte Einrichtung" > ... auf Gegenstelle erstellt JA > NetBIOS JA importiert
5. Manuelles routing und bisherige FW-Port vom alten WG-Setup auf der Fritze gelöscht
Probleme:
a) Die Assistenten der Fritze unterstützen keine verschiedenen vLANs der Gegenseite
b) importiert man das obere config-File über ne bestehende IPSec-Verbindung aus der Ferne werden die Daten nicht richtig importiert
c) zwei DNS-Einträge werden automatisch vorgenommen (fritz.box & lokale IP der Fritze) auf die man keinen Einfluss hat
d) der im conf-File vordefinierte FW-Port wird abgeändert
e) ich komme zwar vom lokalen Fritzbox-Netzwerk in die vLANs des MT ... anders herum endet der Zugriff aber auf der Fritze ... und hier konkret auf der WG-internen NAT-Adresse der Fritze (10.98.200.2). Wie kann ich den Knoten lösen?
f) Beim Wechsel der WAN-IP an der Fritzbox bricht die WG-Verbindung zusammen und baut sich auch nicht mehr auf. Ok, auf MT-Seite hatte ich vergessen ein entsprechendes Skript zu modifizieren aber warum macht das die Fritze nicht von ihrer Seite aus?!
WG-NAT:
Wenn ich das richtig gesehen habe, legt der AVM Wireguard-Assistent kein NAT für Wireguard an, sondern die Fritze behält innerhalb eines von ihr kreierten Tunnel-Setups in meinem Fall 192.168.66.1, etwaige Gegenstellen bekommen offenbar eine IP außerhalb des lokalen DHCP-Bereichs.
Bei meinem manuellen Setup, das ich oben beschrieben habe, nutze ich aber die 10.98.200.1 & 2 /29. Ist das ggfs. ein Problem für die Fritzbox?! Sie ergänzt das Setup eigenständig zu:
Address = 192.168.66.1/26,10.98.200.2/29
Müsste ich in dem Fall dem MT-WG-Interface eine IP aus 192.168.66.0/26 vergeben?!
Fritzbox:
[Interface]
PrivateKey = QNqzq9HQng=
ListenPort = 54267
Address = 192.168.66.1/26,10.98.200.2/29
DNS = 192.168.66.1
DNS = fritz.box
[Peer]
PublicKey = PIfv3MkNhxiCc=
PresharedKey = GmIhEy0UA=
AllowedIPs = 10.98.200.1/32,10.98.33.0/26,10.98.99.0/26,10.98.1.0/26
Endpoint = xxxxxxc8e.sn.mynetname.net:51888
PersistentKeepalive = 25Mikrotik:
[Interface]
PrivateKey = 0P0szFnvZHk=
ListenPort = 51888
Address = 10.98.200.1/29
[Peer]
PublicKey = OxaCpGi5zE=
PresharedKey = GmIhvRqEy0UA=
AllowedIPs = 10.98.200.2/32,192.168.66.0/26
Endpoint = test.goip.de:54640
PersistentKeepalive = 25
IP > Routes > 192.168.66.0/26 auf wg-Interface (AS)
IP > Routes > 10.98.200.0/29 auf wg-Interface (DAC)(Anmerkung: Keys alle mittig gekürzt, ebenso Endpoints anonymisiert)
PS: Bestimmt ne doofe Frage:
Bisher hatte ich nur ne FW-Input-rule (Src 192.168.66.0/26, udp, 51888) konfiguriert. Genügt das?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 4495761391
Url: https://administrator.de/contentid/4495761391
Ausgedruckt am: 25.04.2024 um 07:04 Uhr
28 Kommentare
Neuester Kommentar
Deine vollständige Lösung zu deinem Setup und auch einem Setup die Die Fritzbox generell mit anderen, nicht AVM Wireguard Servern koppelt, findest du hier im Thread weiter unten! 😉
Wenn du die aktuelle ct' im Zugriff hast wird dort genau erklärt wie die etwas "spezielle," WG Konfig auf der AVM Fritzbox auszusehen hat. Sie entspricht leider nicht einer WG Standard Konfig, da kein dediziertes internes IP Netz genutzt wird.
https://www.heise.de/select/ct/2022/23/2225809105962410605
Wenn du die aktuelle ct' im Zugriff hast wird dort genau erklärt wie die etwas "spezielle," WG Konfig auf der AVM Fritzbox auszusehen hat. Sie entspricht leider nicht einer WG Standard Konfig, da kein dediziertes internes IP Netz genutzt wird.
https://www.heise.de/select/ct/2022/23/2225809105962410605
Die Assistenten der Fritze unterstützen keine verschiedenen VLANs der Gegenseite
Das klappt aber auch problemlos. Es kommt auf die Subnetzmaske an im Assistenten. 
Nee, kennst mich ja. Habe ich natürlich nicht
Aber wenn es die aktuelle Ausgabe ist, dann hole ich mir die nachher kurz im Bahnhofsshop. Daran soll es nicht scheitern. Ist ja wieder beeindruckend, dass AVM auch bei diesem VPN wieder was "spezielles" einbaut.
Ich hatte mich vor Monaten schon im Support beschwert, dass man die config nicht im Interface nachträglich verändern kann (vom VPN-Namen abgesehen).
Naja, Hauptsache am Ende läuft es.
PS: Ich guck mal, dass ich das dann hier auch entsprechend ergänze. Für spätere Suchen.
Aber wenn es die aktuelle Ausgabe ist, dann hole ich mir die nachher kurz im Bahnhofsshop. Daran soll es nicht scheitern. Ist ja wieder beeindruckend, dass AVM auch bei diesem VPN wieder was "spezielles" einbaut.
Ich hatte mich vor Monaten schon im Support beschwert, dass man die config nicht im Interface nachträglich verändern kann (vom VPN-Namen abgesehen).
Naja, Hauptsache am Ende läuft es.
PS: Ich guck mal, dass ich das dann hier auch entsprechend ergänze. Für spätere Suchen.
Wie bereits oben gesagt findest du hier unten im weiteren Verluf des Threads die Lösung.
Der Artikel ist ganz gut gemacht hilft aber im Mikrotik Umfeld nicht unbedingt weiter weil das Routing im Gegensatz zum dynamischen Crypto Routing statisch gemacht werden muss.
Es gibt also diverse Fussfallen. Allein schon die Tatsache das die WG Verbindung auf der FB nicht editierbar ist birgt schon genug Potenzial für Fehler.
Die Tatsache das die FB keine Tunnel IPs aus einem separaten Netz verwendet sondern immer eine aus dem remoten LAN macht die Sache nicht einfacher im Setup bekommt man aber dennoch in den Griff wie du weiter unten ja sehen kannst. 😉
Der Artikel ist ganz gut gemacht hilft aber im Mikrotik Umfeld nicht unbedingt weiter weil das Routing im Gegensatz zum dynamischen Crypto Routing statisch gemacht werden muss.
Es gibt also diverse Fussfallen. Allein schon die Tatsache das die WG Verbindung auf der FB nicht editierbar ist birgt schon genug Potenzial für Fehler.
Die Tatsache das die FB keine Tunnel IPs aus einem separaten Netz verwendet sondern immer eine aus dem remoten LAN macht die Sache nicht einfacher im Setup bekommt man aber dennoch in den Griff wie du weiter unten ja sehen kannst. 😉
Hm, 5,90 EUR für eine Zeitschriften-Seite und einige Versuche später stehe ich offenbar immer noch auf dem Schlauch. Jetzt weiß ich zwar, dass die Fritze im VPN-Tunnel keine eigenes IP-Netz aufspannt sondern "ihre" IP beibehält (siehe @aqui):
Heimnetz.1/24 bzw.
192.168.178.1/24 (im Standard) bzw.
192.168.66.1/26 (im obigen Setup)
Nur erwartet sie das von der anderen Seite ebenso. D.h. gebe ich z.B. in meinem Fall den Netzwerk-Bereich "10.98.33.0/26" für das Firmennetz ein, kommt als config-File für die Gegenstelle die Interface-Adresse 10.98.33.1/26 raus.
Übernehme ich das im Mikrotik, müsste ich unter IP > Adresse > wg-Interface ... die 10.98.33.1/26 hinterlegen. Damit verlieren die lokalen Clients aber offenbar den DNS-Kontakt. Vermutlich kommt das routing ins Schleudern, wenn mehrere Interfaces die selbe IP belegen
Ich habe dem Interface auf dem MT ebenso schon testweise die 192.168.66.1 gegeben. Dann wäre die Adresse aber gleichzeitig auf beiden Seiten des Tunnels aktiv. Das scheint aber kurzfristig einseitig zu klappen (von Fritzbox zu Mikrotik). Ebenso ne 192.168.66.55 auf dem MT-Interface (außerhalb DHCP der Fritze aber innerhalb des hom./26)
Ich benötige ja offenbar ein Setup, welches zwischen der eigenwilligen AVM-Interpretation und dem "üblichen" VPN-Aufbau vermittelt. Hat da jemand ne Idee?!
Ich habe das hier mal versucht etwas allgemeiner darzustellen:
PS: Der Artikel verweist darauf, dass die Fritzbox die Interface-IPs mit der Gegenstelle "austauscht". D.h. Die Fritze zu Haus bekommt z.B. 10.98.33.55 innerhalb des Tunnels und der MT am wg-Interface 192.168.66.55 ...
Mit den Assistenten wird dieses Setup NICHT erstellt, sondern das Interaface der Frizte erhält - wie oben beschrieben - die lokale IP. Lege ich so ein File manuell an und möchte es importieren erhalte ich Fehelrmeldungen.
PPS: System-Version 7.39-101156 BETA
Heimnetz.1/24 bzw.
192.168.178.1/24 (im Standard) bzw.
192.168.66.1/26 (im obigen Setup)
Nur erwartet sie das von der anderen Seite ebenso. D.h. gebe ich z.B. in meinem Fall den Netzwerk-Bereich "10.98.33.0/26" für das Firmennetz ein, kommt als config-File für die Gegenstelle die Interface-Adresse 10.98.33.1/26 raus.
Übernehme ich das im Mikrotik, müsste ich unter IP > Adresse > wg-Interface ... die 10.98.33.1/26 hinterlegen. Damit verlieren die lokalen Clients aber offenbar den DNS-Kontakt. Vermutlich kommt das routing ins Schleudern, wenn mehrere Interfaces die selbe IP belegen
Ich habe dem Interface auf dem MT ebenso schon testweise die 192.168.66.1 gegeben. Dann wäre die Adresse aber gleichzeitig auf beiden Seiten des Tunnels aktiv. Das scheint aber kurzfristig einseitig zu klappen (von Fritzbox zu Mikrotik). Ebenso ne 192.168.66.55 auf dem MT-Interface (außerhalb DHCP der Fritze aber innerhalb des hom./26)
Ich benötige ja offenbar ein Setup, welches zwischen der eigenwilligen AVM-Interpretation und dem "üblichen" VPN-Aufbau vermittelt. Hat da jemand ne Idee?!
Ich habe das hier mal versucht etwas allgemeiner darzustellen:
PS: Der Artikel verweist darauf, dass die Fritzbox die Interface-IPs mit der Gegenstelle "austauscht". D.h. Die Fritze zu Haus bekommt z.B. 10.98.33.55 innerhalb des Tunnels und der MT am wg-Interface 192.168.66.55 ...
Mit den Assistenten wird dieses Setup NICHT erstellt, sondern das Interaface der Frizte erhält - wie oben beschrieben - die lokale IP. Lege ich so ein File manuell an und möchte es importieren erhalte ich Fehelrmeldungen.
PPS: System-Version 7.39-101156 BETA
zwar, dass die Fritze im VPN-Tunnel keine eigenes IP-Netz aufspannt sondern "ihre" IP beibehält.
Das ist nicht ganz richtig. Die Tunnel IP ist immer eine aus dem lokalen Netz des remoten Routers. Sieht man auch wenn man sich die von der FB generierte Konfig ansieht.Die Tunnel IP ist immer eine aus dem lokalen Netz des remoten Routers.
Nutze ich den Assistenten der Fritze kommt das raus:
Fritzbox:
[Interface]
PrivateKey = GCQH6IiV0......UIU4Gk=
ListenPort = 53762
Address = 192.168.66.1/26
DNS = 192.168.66.1,10.98.33.1
DNS = fritz.box
[Peer]
PublicKey = jfDNuPW0YBk.......VFNK069404=
PresharedKey = 19OXG......oIQF1kwvw=
AllowedIPs = 10.98.33.0/26
PersistentKeepalive = 25Export-Datei für Gegenstelle (Mikrotik):
[Interface]
PrivateKey = qBESc....VAktuDH4=
Address = 10.98.33.1/26
DNS = 9.9.9.9,192.168.66.1
DNS = fritz.box
[Peer]
PublicKey = GGFt+gu....lcnUqNJ5MkM=
PresharedKey = 19OXG4+.....oIQF1kwvw=
AllowedIPs = 192.168.66.0/26
Endpoint = …goip.de:53762
PersistentKeepalive = 25Anmerkung: Ich habe mich - weil ja nur ein Netzwerk abgefragt wird - fürs vlan 10.98.33.0/26 entschieden. Der Wunsch wäre aber schon, dass mehrere vLANs erreichbar wären.
Das entspricht mMn. nicht der Grafik oben rechts in der Heise auf Seite 73!
Grüß dich Visucius,
es tut mir Leid, den alten Thread wieder so hochzuholen, aber ich stehe im Moment exakt vor dem gleichen Problem. Ich habe auf der FB eine Configdatei erstellt und die Einstellungen daraus in den MT übernommen, und der Tunnel scheint erfolgreich aufgebaut werden zu können. Allerdings funktioniert das Routing über den Tunnel nicht. Wie bist du denn am Ende verblieben? Insbesondere würde mich interessieren, welche IP-Adresse du dem WG interface auf dem MT zugewiesen hast? Vielen Dank!
es tut mir Leid, den alten Thread wieder so hochzuholen, aber ich stehe im Moment exakt vor dem gleichen Problem. Ich habe auf der FB eine Configdatei erstellt und die Einstellungen daraus in den MT übernommen, und der Tunnel scheint erfolgreich aufgebaut werden zu können. Allerdings funktioniert das Routing über den Tunnel nicht. Wie bist du denn am Ende verblieben? Insbesondere würde mich interessieren, welche IP-Adresse du dem WG interface auf dem MT zugewiesen hast? Vielen Dank!
Hast du beachtet das der Mikrotik keine automatische Route für das Zielnetz einträgt?!
Das musst du immer manuell im Mikrotik Setup unter IP -> Route anlegen ansonsten scheitert das Routing.
Siehe hier an einem analogen Beispiel wo der Mikrotik einen Wireguard Tunnel auf eine Firewall aufbaut.
Aktiviere Wireguard unter System - Logging dann kannst du es direkt im MT Log sehen ob der Tunnel aufgebaut wurde. Oder im Peer Setup ganz unten unter Last Handshake.
Das musst du immer manuell im Mikrotik Setup unter IP -> Route anlegen ansonsten scheitert das Routing.
Siehe hier an einem analogen Beispiel wo der Mikrotik einen Wireguard Tunnel auf eine Firewall aufbaut.
der Tunnel scheint erfolgreich aufgebaut werden zu können
Scheint...?! Raten ist immer schlecht. Aktiviere Wireguard unter System - Logging dann kannst du es direkt im MT Log sehen ob der Tunnel aufgebaut wurde. Oder im Peer Setup ganz unten unter Last Handshake.
Hi aqui,
danke für die Tipps. Bitte entschuldige meine unpräzise Formulierung. Der Tunnel wird erfolgreich aufgebaut, das bestätigen sowohl die MT logs als auch die FritzBox UI.
Die Route hatte ich angelegt, funktionieren tut der Ping leider immer noch nicht (kann die FB nicht erreichen, und erst recht keinen Rechner dahinter). Ich vermute nach wie vor dass das an der Eigenheit der AVM Implementierung von WG liegt. Welche Adresse müsste ich denn dem Mikrotik am Wireguard-Interface zuweisen? Das VLAN mit dem ich die FB verknüpfen möchte, ist in 192.168.4.0/24. Mit der Adresse 192.168.4.1/24 zerschießt es mir das Routing im gesamten VLAN, mit 192.168.4.1/32 passiert das nicht aber der Ping funktioniert trotzdem nicht.
Das Beispiel mit der Firewall ist zwar nett, aber hilft mir nicht weiter, weil es ja kein internes Transfernetz im Tunnel zu geben scheint. Vielleicht kannst du mir da ja einen Tipp geben? Danke!
danke für die Tipps. Bitte entschuldige meine unpräzise Formulierung. Der Tunnel wird erfolgreich aufgebaut, das bestätigen sowohl die MT logs als auch die FritzBox UI.
Die Route hatte ich angelegt, funktionieren tut der Ping leider immer noch nicht (kann die FB nicht erreichen, und erst recht keinen Rechner dahinter). Ich vermute nach wie vor dass das an der Eigenheit der AVM Implementierung von WG liegt. Welche Adresse müsste ich denn dem Mikrotik am Wireguard-Interface zuweisen? Das VLAN mit dem ich die FB verknüpfen möchte, ist in 192.168.4.0/24. Mit der Adresse 192.168.4.1/24 zerschießt es mir das Routing im gesamten VLAN, mit 192.168.4.1/32 passiert das nicht aber der Ping funktioniert trotzdem nicht.
Das Beispiel mit der Firewall ist zwar nett, aber hilft mir nicht weiter, weil es ja kein internes Transfernetz im Tunnel zu geben scheint. Vielleicht kannst du mir da ja einen Tipp geben? Danke!
weil es ja kein internes Transfernetz im Tunnel zu geben scheint.
Das gibt es schon aber bei der proprietären AVM /Fritzbox Implementation von Wireguard ist das ihre IP Adresse aus dem LAN. Das liegt an dem kranken AVM WG Setup. Auch ein hiesiger Thread beschreibt dieses Setup:
Wireguard Lan to Lan Fritzbox Raspberry Pi
Vielen Dank für die Links. Durch den von dir erwähnten Thread bin ich auf den hiesigen gestoßen, aber ich habe trotzdem beide nochmal umfassend durchgearbeitet. Die dort beschriebene Situation überschneidet sich aber mit meiner in der Hinsicht nicht, als dass ich direkt den Gateway-Router als WG-endpoint nutzen möchte, und nicht ein Gerät dahinter.
Weiterhin - und hier liegt die Crux - habe ich ähnlich wie @Visucius in der Interface-Konfiguration der FB auch nur die lokale IP des eigenen Subnetzes finden können, und keine IP des counterpart-Subnetzes. Somit stehen unsere Erfahrungen im Widerspruch zu der Heise-Dokumentation. Hast du denn ein entsprechendes Setup bei dir laufen? Es wäre interessant zu wissen, was in deiner Fritzbox-wg.conf steht.
Final bin ich dann mit Packet-Captures auf die Suche nach dem Problem gegangen. Ping-Packets aus dem Mikrotik-Subnetz werden erfolgreich in den Tunnel geroutet und kommen auf der Fritzbox am entsprechenden Interface an. Leider bleiben diese aber unbeantwortet. Wenn ich dem Mikrotik-Wireguard-Interface eine ungenutzte IP-Adresse aus dem Fritzbox-Subnetz zuweise, werden von dieser ausgehende Packets zwar in dem Tunnel auf die Leitung gelegt, kommen aber am Fritzbox-Interface nicht an (was ja auch klar ist, weil das Fritzbox-Subnetz nicht zu den AllowedIPs des Peers - AKA des Mikrotik-Routers gehört). Auch diese Erkenntnis steht meiner Meinung nach im Widerspruch zu der Heise-Doku, denn die Wireguard-Config, an der ich mich orientiere, kommt ja direkt aus dem Fritzbox-Setup-Assistenten.
Hast du noch weitere Ideen? Ich würde sagen, ich hänge exakt am gleichen Punkt fest wie @Visucius damals. Weißt du, wie er es gelöst hat? Tausend Dank für deine Zeit!
Weiterhin - und hier liegt die Crux - habe ich ähnlich wie @Visucius in der Interface-Konfiguration der FB auch nur die lokale IP des eigenen Subnetzes finden können, und keine IP des counterpart-Subnetzes. Somit stehen unsere Erfahrungen im Widerspruch zu der Heise-Dokumentation. Hast du denn ein entsprechendes Setup bei dir laufen? Es wäre interessant zu wissen, was in deiner Fritzbox-wg.conf steht.
Final bin ich dann mit Packet-Captures auf die Suche nach dem Problem gegangen. Ping-Packets aus dem Mikrotik-Subnetz werden erfolgreich in den Tunnel geroutet und kommen auf der Fritzbox am entsprechenden Interface an. Leider bleiben diese aber unbeantwortet. Wenn ich dem Mikrotik-Wireguard-Interface eine ungenutzte IP-Adresse aus dem Fritzbox-Subnetz zuweise, werden von dieser ausgehende Packets zwar in dem Tunnel auf die Leitung gelegt, kommen aber am Fritzbox-Interface nicht an (was ja auch klar ist, weil das Fritzbox-Subnetz nicht zu den AllowedIPs des Peers - AKA des Mikrotik-Routers gehört). Auch diese Erkenntnis steht meiner Meinung nach im Widerspruch zu der Heise-Doku, denn die Wireguard-Config, an der ich mich orientiere, kommt ja direkt aus dem Fritzbox-Setup-Assistenten.
Hast du noch weitere Ideen? Ich würde sagen, ich hänge exakt am gleichen Punkt fest wie @Visucius damals. Weißt du, wie er es gelöst hat? Tausend Dank für deine Zeit!
Hast du denn ein entsprechendes Setup bei dir laufen?
Noch nicht, kann ich aber auf Basis der Heise Doku gerne mal testen übers Wochenende.Z.B. die Kombination FritzBox als WG Client (Initiator) auf einen bestehenden klassischen WG Server (Responder) geht m.E. gar nicht obwohl ein Youtube Video das Gegenteil behauptet. Das dort gezeigt Setup funktioniert de facto nicht!
Die AVM Büchse muss m. E. immer Responder (Server) sein sonst geht mit nicht AVM WG Endgeräten nichts und auch das nur mit Klimmzügen.
Im Endeffekt ist es deutlich leichter und erspart eine Menge graue Haare das IPsec VPN der FritzBox zu nutzen. Das klappt mit dem Mikrotik und auch allen anderen IPsec fähigen Firewalls und Routern fehlerlos und ohne jegliche Probleme sofort auf Anhieb. Egal in welcher Konstellation.
Wäre sehr nett, wenn du das mal testen könntest. Der Tunnel wird ja established und die Packets kommen durch, deswegen muss es meiner Meinung nach an irgendeinem kleinen Routing-Problem liegen. Da die Fritzbox aber fast keine Änderungen an den Einstellungen zulässt, bin ich auf den Mikrotik angewiesen (der aber mMn alles richtig macht).
Bzgl. Initiator und Responder: Das ist in meinem Setup zufällig kein Problem, da der Mikrotik hinter einem CGNAT hängt und somit immer der Initiator sein muss.
Aufgrund der Eleganz und der höheren Geschwindigkeit würde ich Wireguard schon stark präferieren. Wenn es gar nicht geht switche ich natürlich auch zu IPSec, aber würde das gerne wenn möglich vermeiden.
Ich freue mich auf deine Ergebnisse!
Bzgl. Initiator und Responder: Das ist in meinem Setup zufällig kein Problem, da der Mikrotik hinter einem CGNAT hängt und somit immer der Initiator sein muss.
Aufgrund der Eleganz und der höheren Geschwindigkeit würde ich Wireguard schon stark präferieren. Wenn es gar nicht geht switche ich natürlich auch zu IPSec, aber würde das gerne wenn möglich vermeiden.
Ich freue mich auf deine Ergebnisse!
Die FritzBox Konfig eines hierzu korrespondierenden Threads in der man die FritzBox LAN IP auch als ihre Tunnel IP angibt brachte in der Tat den Durchbruch!! 👍
Die folgenden Fritzbox VPN Konfigurationskniffe gelten nicht nur für Mikrotik sondern generell für ALLE Standard Wireguard Endgeräte in mit der Fritzbox gemischten Wireguard VPN Umgebungen! Dies betrifft auch die Firewalls wie OPNsense und pfSense.
Die Fritzbox arbeitet im folgenden Konfigurationsbeispiel als VPN Initiator (WG Client).
Ein folgender Thread im Anschluss beschreibt das Wireguard Setup wenn die Fritzbox als Wireguard Server (VPN Responder) arbeitet.
(⚠️ Ein Setup der Fritzbox als Wireguard VPN Server (Responder) ist weiter unten beschrieben!)
Grundlage für den Test ist ein klassisches, einfaches Wireguard Standardsetup.
Im ersten Anlauf spielte statt des Mikrotik Routers ein Linux (Raspberry Pi) als klassischer Wireguard Server den Responder (WG Server) um das Fritzbox Setup (WG Client) sicher zu verifizieren.
Der Wireguard Server verwendet als WAN Port IP 10.99.1.150 bzw. damit dann den DynDNS Hostnamen 0a630196.nip.io. (nip.io DNS Info siehe hier) Wireguard UDP Port ist: 51820
Wie oben schon geschrieben lief dieses Setup sofort auf Anhieb. Ping Checks erwartungsgemäß beidseitig fehlerlos...
(Fritzbox lokales LAN Netzwerk = 192.168.188.0 /24)
Der u.a. Screenshot zeigt die Ping Checks aus den jeweiligen per VPN verbundenen lokalen LANs sowie die in die FritzBox zu importierende Wireguard Konfigdatei.
⚠️ Wichtig für den Erfolg ist, das die in der auf die Fritzbox zu importierenden Wireguard Konfigurations Datei, unter "Address = 192.168.188.1/24" eingestellte IP Adresse identisch zur LAN IP Adresse der FritzBox ist!
Da die Fritzbox hier als VPN Client (Initiator) arbeitet, sich also auf einen bestehenden VPN Server (Mikrotik, pfSense, Linux etc.) mit bestehender Konfig verbindet, muss sie folglich auch die durch den VPN Server vorgegebene Konfig Datei in ihr Setup importieren!!
Das passiert im "VPN (Wireguard)" Karteireiter des Fritzbox Menüs indem man dort "Verbindung hinzufügen" klickt und diese o.a. Konfigurations (Text) Datei importiert.
Hier nochmals die dazu korrespondierende Wireguard Konfig Datei zum Import in die Fritzbox als Wireguard Client.
⚠️ Wichtig ist das in der Konfig Datei die unter "Address = 192.168.188.1/24" eingestellte IP Adresse immer identisch zur LAN IP Adresse der FritzBox ist!
Damit funktioniert dann auch die Kopplung der FritzBox als WG Client auf den Mikrotik und übrigens auch auf pfSense und OPNsense Firewalls fehlerlos!
Der erfolgreiche Test mit dem Linux Host liess hoffen das es mit dem Mikrotik auch klappt was der Test dann letztlich auch verifizierte!
Der Mikrotik als VPN Server (Responder) bekam exakt die gleiche Konfig und Keys wie oben der testweise als VPN Server laufende Linux Host.
Verwendet wurde ein klassisches Mikrotik Default Setup mit NAT an ether1. Hier muss eine entsprechende Firewall Regel hinzugefügt werden damit eingehend Wireguard UDP 51820 Pakete passieren dürfen.
Hier wurden exakt die o.a. Linux Parameter verwendet
Der Linux Host übernimmt automatisch das Routing in den Peer (Cryptokey Routing) so das kein statisches Routing erforderlich ist.
⚠️ Beim Mikrotik ist das nicht der Fall! Hier ist im Setup immer eine statische Route unter (IP -> Routes) erforderlich um die remoten IP Netze (FritzBox LAN) erreichen zu können!
Es existiert zwar keine 10.10.10er Tunnel IP Adresse auf der FritzBox, weil die FB, wie oben beschrieben, ihre eigene LAN IP als Tunneladresse verwendet. Es reicht aber eine "imaginäre" IP Adresse wie 10.10.10.2 aus dem internen Wireguard IP Netz als Gateway einzugeben.
Für die pfSense gilt dann analog zu oben das folgende Setup, welches die Fritzbox als Wireguard Client (Initiator) an die Firewall anbindet.
Die Schritte sind bei der OPNsense in deren Konfig GUI identisch.
⚠️ Wichtig ist das in der pfSense wie auch in der OPNsense was Wireguard Tunnel Interface über das Interface Assignment fest zugewiesen wird! Siehe dazu HIER!
Lokales LAN pfSense: 192.168.211.0 /24
Lokales LAN Fritzbox: 192.168.188.0 /24
Internes Wireguard Netz: 100.64.64.0 /28, pfSense Wireguard Tunnel IP: 100.64.64.14
(.14 höchste IP im internen /28er Wireguard Netz so das man die Clients kosmetisch von .1 bis .13 durchnummerieren kann)
⚠️ Die pfSense übernimmt im Gegensatz zu anderen Endgeräten das Wireguard Gateway und die Route ins entfernte IP Netz nicht automatisch. Dies muss statisch im Menü System - Routing für alle Tunnelverbindungen konfiguriert werden!
WAN Port:
Wireguard Interface:
(Das ist eine "Scheunentor" Regel die im WG Tunnel alles erlaubt. Wer hier striktere Regeln will muss das entsprechend anpassen!)
Fazit: Works as designed! 👍
P.S.: Wer doch lieber die IPsec VPN Variante der Fritzbox verwenden möchte findet diese HIER 😉
Die folgenden Fritzbox VPN Konfigurationskniffe gelten nicht nur für Mikrotik sondern generell für ALLE Standard Wireguard Endgeräte in mit der Fritzbox gemischten Wireguard VPN Umgebungen! Dies betrifft auch die Firewalls wie OPNsense und pfSense.
Die Fritzbox arbeitet im folgenden Konfigurationsbeispiel als VPN Initiator (WG Client).
Ein folgender Thread im Anschluss beschreibt das Wireguard Setup wenn die Fritzbox als Wireguard Server (VPN Responder) arbeitet.
Inhaltsverzeichnis
Setup Fritzbox als Wireguard VPN Client (Initiator)
(⚠️ Ein Setup der Fritzbox als Wireguard VPN Server (Responder) ist weiter unten beschrieben!)
Grundlage für den Test ist ein klassisches, einfaches Wireguard Standardsetup.
Im ersten Anlauf spielte statt des Mikrotik Routers ein Linux (Raspberry Pi) als klassischer Wireguard Server den Responder (WG Server) um das Fritzbox Setup (WG Client) sicher zu verifizieren.
Der Wireguard Server verwendet als WAN Port IP 10.99.1.150 bzw. damit dann den DynDNS Hostnamen 0a630196.nip.io. (nip.io DNS Info siehe hier) Wireguard UDP Port ist: 51820
Wireguard Konfig Datei des Linux Servers (Responder)
[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = 123Oug5cEdTJSG9OY7nTLrvE1SCbPti5siKDJ2NFBX0=
[Peer]
PublicKey = tlPY1jswXwHU/OfS+KPThhP0I+dAtyE/w3OpMC9Y9x8=
AllowedIPs = 10.10.10.2/32,192.168.188.0/24 FritzBox Setup und PingCheck
Der u.a. Screenshot zeigt die Ping Checks aus den jeweiligen per VPN verbundenen lokalen LANs sowie die in die FritzBox zu importierende Wireguard Konfigdatei.⚠️ Wichtig für den Erfolg ist, das die in der auf die Fritzbox zu importierenden Wireguard Konfigurations Datei, unter "Address = 192.168.188.1/24" eingestellte IP Adresse identisch zur LAN IP Adresse der FritzBox ist!
Fritzbox Client Konfigurations Import
Da die Fritzbox hier als VPN Client (Initiator) arbeitet, sich also auf einen bestehenden VPN Server (Mikrotik, pfSense, Linux etc.) mit bestehender Konfig verbindet, muss sie folglich auch die durch den VPN Server vorgegebene Konfig Datei in ihr Setup importieren!!Das passiert im "VPN (Wireguard)" Karteireiter des Fritzbox Menüs indem man dort "Verbindung hinzufügen" klickt und diese o.a. Konfigurations (Text) Datei importiert.
Fritzbox Wireguard Konfig Import Datei
Hier nochmals die dazu korrespondierende Wireguard Konfig Datei zum Import in die Fritzbox als Wireguard Client.⚠️ Wichtig ist das in der Konfig Datei die unter "Address = 192.168.188.1/24" eingestellte IP Adresse immer identisch zur LAN IP Adresse der FritzBox ist!
[Interface]
PrivateKey = <Private_Key_Fritzbox>
Address = 192.168.188.1/24
[Peer]
PublicKey = <Public_Key_Server>
AllowedIPs = 10.10.10.0/24,172.25.26.0/28
Endpoint = 0a630196.nip.io:51820
PersistentKeepalive = 25 FritzBox Peer Check
Mikrotik als Wireguard Server (Responder)
Der erfolgreiche Test mit dem Linux Host liess hoffen das es mit dem Mikrotik auch klappt was der Test dann letztlich auch verifizierte!Der Mikrotik als VPN Server (Responder) bekam exakt die gleiche Konfig und Keys wie oben der testweise als VPN Server laufende Linux Host.
Firewall Setup
Verwendet wurde ein klassisches Mikrotik Default Setup mit NAT an ether1. Hier muss eine entsprechende Firewall Regel hinzugefügt werden damit eingehend Wireguard UDP 51820 Pakete passieren dürfen.Wireguard Peer Setup
Hier wurden exakt die o.a. Linux Parameter verwendetIP Routing Setup
Der Linux Host übernimmt automatisch das Routing in den Peer (Cryptokey Routing) so das kein statisches Routing erforderlich ist.⚠️ Beim Mikrotik ist das nicht der Fall! Hier ist im Setup immer eine statische Route unter (IP -> Routes) erforderlich um die remoten IP Netze (FritzBox LAN) erreichen zu können!
Es existiert zwar keine 10.10.10er Tunnel IP Adresse auf der FritzBox, weil die FB, wie oben beschrieben, ihre eigene LAN IP als Tunneladresse verwendet. Es reicht aber eine "imaginäre" IP Adresse wie 10.10.10.2 aus dem internen Wireguard IP Netz als Gateway einzugeben.
Für die pfSense gilt dann analog zu oben das folgende Setup, welches die Fritzbox als Wireguard Client (Initiator) an die Firewall anbindet.
Die Schritte sind bei der OPNsense in deren Konfig GUI identisch.
pfSense Firewall als Wireguard Server (Responder)
⚠️ Wichtig ist das in der pfSense wie auch in der OPNsense was Wireguard Tunnel Interface über das Interface Assignment fest zugewiesen wird! Siehe dazu HIER!
Lokales LAN pfSense: 192.168.211.0 /24
Lokales LAN Fritzbox: 192.168.188.0 /24
Internes Wireguard Netz: 100.64.64.0 /28, pfSense Wireguard Tunnel IP: 100.64.64.14
(.14 höchste IP im internen /28er Wireguard Netz so das man die Clients kosmetisch von .1 bis .13 durchnummerieren kann)
pfSense Wireguard Tunnel
pfSense Peer zur Fritzbox
pfsense Interface Assignment
pfSense Wireguard Gateway und Route
⚠️ Die pfSense übernimmt im Gegensatz zu anderen Endgeräten das Wireguard Gateway und die Route ins entfernte IP Netz nicht automatisch. Dies muss statisch im Menü System - Routing für alle Tunnelverbindungen konfiguriert werden!
Wireguard Gateway
Wireguard Route
pfSense Firewall Regeln
WAN Port:
Wireguard Interface:
pfSense Pingcheck zur Fritzbox
Fritzbox Konfigurationsdatei pfSense VPN
[Interface]
PrivateKey = 8C1234567mNOvASetoqRXm2+07tM2xuqV5s9AC0rIVs=
Address = 192.168.188.1/24
[Peer]
PublicKey = 758fxIPLzQCVjzdtQ/+Q1Nbg1CmXl0s44vlvrW5UzQY=
AllowedIPs = 100.64.64.0/28,192.168.211.0/24
Endpoint = <WAN_ip/hostname_pfSense>:57820
PersistentKeepalive = 25 Fritzbox Wireguard Status
Fazit: Works as designed! 👍
P.S.: Wer doch lieber die IPsec VPN Variante der Fritzbox verwenden möchte findet diese HIER 😉
Vielen Dank für deine Mühen! Ich glaube, wir kommen der ganzen Sache schon ein ganzes Stück näher! Der einzige Unterschied, den ich noch zwischen deinem und meinem Setup sehe, ist, dass aufgrund des CGNAT in meinem Fall der Mikrotik der Initiator und die FritzBox der Responder sein muss.
Bis auf diesen Unterschied bin ich deiner Konfiguration 1:1 gefolgt, aber kriege leider immer noch keine Ping responses von der Fritzbox durchgeroutet. Deswegen hänge ich jetzt mal diverse Screenshots an, vielleicht erkennst du da den entscheidenden Fehler?
Zur Erklärung, Mikrotik Subnet ist 192.168.4.0/24 und Fritzbox Subnet ist 192.168.24.0/24.
Mikrotik Wireguard Interface
Mikrotik Wireguard Peer
Mikrotik Interface IP Address
Mikrotik Routes
Mikrotik Firewall (brauche nur stateful firewall weil Mikrotik ja der Initiator ist)
Fritzbox Wireguard State
Packet Capture am Fritzbox Wireguard Interface
Fritzbox Wireguard Config File
Wo siehst du hier den Fehler? Freue mich sehr auf deine Rückmeldung, meiner Meinung nach spielt die Fritzbox verrückt!
Bis auf diesen Unterschied bin ich deiner Konfiguration 1:1 gefolgt, aber kriege leider immer noch keine Ping responses von der Fritzbox durchgeroutet. Deswegen hänge ich jetzt mal diverse Screenshots an, vielleicht erkennst du da den entscheidenden Fehler?
Zur Erklärung, Mikrotik Subnet ist 192.168.4.0/24 und Fritzbox Subnet ist 192.168.24.0/24.
Mikrotik Wireguard Interface
Mikrotik Wireguard Peer
Mikrotik Interface IP Address
Mikrotik Routes
Mikrotik Firewall (brauche nur stateful firewall weil Mikrotik ja der Initiator ist)
Fritzbox Wireguard State
Packet Capture am Fritzbox Wireguard Interface
Fritzbox Wireguard Config File
[Interface]
PrivateKey = <redacted>
ListenPort = 50120
Address = 192.168.24.1/24
DNS = 192.168.24.1
DNS = fritz.box
[Peer]
PublicKey = <redacted>
PresharedKey = <redacted>
AllowedIPs = 10.10.10.0/24,192.168.4.0/24
PersistentKeepalive = 25Wo siehst du hier den Fehler? Freue mich sehr auf deine Rückmeldung, meiner Meinung nach spielt die Fritzbox verrückt!
Noch ein interessanter Nachtrag, der vielleicht hilft, das Problem etwas einzuschränken: Durch einen Packet-Capture auf der LAN-Seite der Fritzbox sehe ich, dass die ICMP Echo Requests erfolgreich ins LAN geroutet werden, und ein Reply generiert wird (Screenshot anbei). Allerdings wird dieser Reply dann wohl nicht mehr von der Fritzbox auf die Wireguard-Leitung gelegt. Hast du soetwas schon mal gesehen?
Und noch ein letzter Nachtrag: Ein Ping direkt vom Mikrotik-Router aus, der ja die 10.10.10.1/24 besitzt, funktioniert tadellos! Es scheint also wirklich nur am FritzBox-Routing in das 192.168.4.0/24 Subnetz zu liegen.
aufgrund des CGNAT in meinem Fall der Mikrotik der Initiator und die FritzBox der Responder sein muss.
OK, das ist dann sogar noch etwas einfacher, denn dann gibt die Fritzbox als VPN Server (Responder) ja die Wireguard Konfig vor die man von ihr dann runterlädt beim Wireguard Client Setup.Die Herausforderung ist hier wieder das Routing auf der Mikrotik bzw. pfSense/OPNsense Seite, weil die FritzBox so tut als ob das Tunnelnetz schon das remote Netz ist. Der Mikrotik aber Wireguard konform ein internes IP Netz erwartet das zusätzlich ein statisches Routing erfordert!
Der Mikrotik macht wie auch die pfSense kein dynamisches Wireguard Cryptokey Routing wie es „klassische“ Wireguard Endgeräte und z.B. auch die OPNsense macht.
Die Fritzbox spielt nicht wirklich verrückt sondern verhält sich leider aufgrund der nicht üblichen Wireguard Konfig so, was auch das inkonsitente ICMP Paket Routing von oben erklärt.
Mit einem kleinen "Routing Kniff" ist das aber schnell und problemlos zu lösen indem man die Fritzbox und ihre nicht Standard konforme Wireguard Konfig routingtechnisch etwas "überlistet"! 😉
Inhaltsverzeichnis
Fritzbox als Wireguard VPN Server (Responder)
Der "Kniff" ist das man der FritzBox mit der Angabe der remoten Netzwerkmaske in ihrem Setup Dialog ein größeres, Client seitiges LAN IP Netzwerk vorgaukelt.
Bei einem remoten /24er Prefix (255.255.255.0) wird dann z.B. stattdessen einfach ein /23er Netz (Maske = 255.255.254.0) im Fritzbox Setup angegeben.
Hier im Beispiel wurde die bestehende Mikrotik Konfig aus dem obigen Client Setup belassen mit der lokalen LAN Netzwerk Adresse: 172.25.26.0 /28 (Endgeräte IP Adressen von .1 bis .14)
Der Fritzbox wurde in ihrem Wireguard Setup aber gesagt das dort ein vermeintlich größeres 172.25.26.0 /27 Netzwerk ist.
(Adressbereich .1 bis .30)Das stimmt zwar nicht aber die Fritzbox "merkt" das nicht weil sie nicht wirklich weiss wie groß das remote Netz ist.
Damit hat man das durch diesen "Kniff" gewonnene 2te /28er Teilnetz 172.25.26.16/28 (.17 bis .30) dann quasi als "Dummy Routing" Netzwerk im Mikrotik für den Tunnel gewonnen und kann dorthin problemlos die erforderliche statische Route setzen.
⚠️ Nutzer mit einem /24er Prefix (255.255.255.0) im lokalen Mikrotik LAN (oder dem eines nicht AVM Routers) nehmen hier, wie bereits gesagt, entsprechend eine größere /23 Maske (255.255.254.0).
Bezogen auf deine Adressierung mit dem 192.168.4.0 /24 LAN Netzwerk am Mikrotik konfigurierst du der Fritzbox in ihrem Wireguard Setup dann ein remotes 192.168.4.0 /23 (255.255.254.0) IP Netz.
Das dort dann durch die Maske inkludierte .5.0 /24er Netz nutzt du dann als imaginäres Wireguard Tunnelnetz am Mikrotik für dessen statische Route zur FB.
(192.168.4.0 /23 beinhaltet den Bereich 192.168.4.1 bis 192.168.5.254 !)
[Interface]
PrivateKey = SHmfBISHETHvgp1NZ3OB4DHO+2ETO8A7NT2WHJkZQ1M=
Address = 172.25.26.1/27
DNS = 192.168.188.1
[Peer]
PublicKey = QkuU7B316836EOKyxW7L3RB0vgMazj6/rk3/xnN+alg=
PresharedKey = H1/LuRk1pUMSlfF0NacvcOiHB3qoQMZkZQlKGXVjaUE=
AllowedIPs = 192.168.188.0/24
Endpoint = 0a0b01c7.nip.io:54733
PersistentKeepalive = 25 Die Mikrotik Wireguard IP Adresse setzt man dann später auf das 2te "Dummy" Netz 172.25.26.16 /28 also die IP Adresse 172.25.26.17/28 (1. IP im Netz) und die statische Route im Mikrotik dann auf die imaginäre 172.25.26.18 als Gateway IP (2. IP im Netz).
Korrekt angepasst muss dann oben
Address = 172.25.26.17/28Die FritzBox akzeptiert das alles, weil sie durch ihre vergrößerte Maske "denkt" alles ist in einem gemeinsamen IP Netz.
⚠️ Aufpassen muss man natürlich das dieses "Dummy" Tunnelnetz was man der Fritzbox vorgaukelt nirgendwo sonst im gesamten Netzwerk auftaucht damit die Wegefindung (Routing) immer eindeutig bleibt!! Bekanntlich der goldene Grundsatz beim IP Adressdesign. 😉
Mikrotik Setup als Wireguard VPN Client (Initiator)
Die von der FritzBox aus ihrem Wireguard Setup zum Download vorgegebene Client Konfig Datei (s.o.) setzt man dann entsprechend IP Adress- und Routing technisch angepasst dort um.
Die hier verwendete nip.io Adresse ist ggf. durch eine eigene MyFritz! oder DDNS Adresse zu ändern!
Hier sieht man dann auch die oben geänderte, interne Wireguard Client IP Adresse mit einer /28er Maske. 172.25.26.17 /28!
Mikrotik Routing Setup
Wie oben schon beschrieben, nutzt man das 2te interne IP Netz der größeren Maske als "Transfer" Netz für das imaginäre Gateway zur FritzBox!
Firewall Einstellung entfällt hier im Initiator (Client) Mode wie du auch oben schon richtig gesagt hast, da der Client ja von sich aus den Tunnel aktiv aufbaut!
Damit lassen sich dann beidseitig alle lokalen Komponenten per VPN erreichen. 😉
Dieser Routing "Kniff" lässt sich ebenso mit einer pfSense, OPNsense bzw. allen "klassischen" Wireguard Endgeräten als Client (Initiator) umsetzen und führt auch da zum Erfolg bei der Wireguard Kopplung einer AVM Fritzbox im VPN Server Mode mit klassischen Wireguard Endgeräten in einem VPN LAN zu LAN Design!
Beispielsetup mit GL.inet Mobilrouter
Ein GL.inet Mobilrouter benötigt keine der o.a. "Tricksereien" die für den Mikrotik oder OPNsense/pfSense erforderlich sind, weil er kein separates IP Netz nutzt. Hier kann man also mit dem klassischen Setup Prozedere arbeiten.Wireguard Setup mit GL.inet Router Client
OPNsense Setup als Wireguard VPN Client (Initiator)
Der o.a. "Kniff" lässt sich ebenso auf ein OPNsense / pfSense Setup anwenden. Hier am Beispiel der OPNsense. Das Testdesign entspricht der folgenden Abbildung:
Fritzbox Setup
Es wird ein normales Fritzbox Server (Responder) Setup über das GUI konfiguriert an dessen Ende die Fritzbox die Konfig Datein für den Client (Initiator) zum Download ausgibt.
Die von der Fritzbox als Download ausgebene Wireguard Client Konfig Datei zum o.a. Setup lautet:
[Interface]
PrivateKey = +Eok66MuFP18EuOaHuJlp+rtgDGSLuBpX9P2OMI1V2w=
Address = 192.168.110.1/24
DNS = 192.168.188.1
[Peer]
PublicKey = X7ucKu1lhjHKFaVBhD/+XH7xuIGxbHELmCGCHYkn1ms=
PresharedKey = /8M84aTN4tAjs0skKX9MjCd3h9WwtGTQszC9jQwPcCQ=
AllowedIPs = 192.168.188.0/24
Endpoint = 10.1.10.199:53368
PersistentKeepalive = 25 Idealerweise entfernt man die DNS Angabe komplett, denn die ist nur erforderlich sollen interne DNS Namen aufgelöst werden. Behält man sie bei, laufen alle DNS Anfragen der OPNsense bei aktivem Wireguard Tunnel immer auf die Fritzbox und belasten den Tunnel unnötigerweise!
OPNsense Setup (Client)
⚠️ Beim Setup der Wireguard Instance auf der OPNsense ist der Eintrag des Public Keys erforderlich. Diesen behält die Fritzbox allerdings für sich und gibt sie in der Konfig Download Datei nicht an, was aber kein Hindernis ist.Man kann den Public Key ganz einfach aus dem von der Fritzbox vorgegebenen Private Key mit:
echo +Eok66MuFP18EuOaHuJlp+rtgDGSLuBpX9P2OMI1V2w= | wg pubkey Die "Tunnel Address" liegt dann im "Fake Netz" der größeren Maske. Danach legt man den Peer mit den Credentials aus der Fritzbox Datei an und aktiviert den Wireguard Prozess was den Tunnel Status dann auf "UP" bringt.
Abschliessend ist die Firewall Regel auf dem Tunnel Interface nicht zu vergessen! Hier im Beispiel, der Einfachheit halber, eine "Scheuentor" Regel die im Tunnel alles erlaubt.
Eine Firewall Regel auf dem WAN / Internet Interface der Firewall ist hier im Client Mode nicht erforderlich, weil es als Client ja nur ausgehenden Wireguard Traffic gibt"
Ping Check
Ein abschliessender Ping Check verifiziert dann die IP Verbindung der beiden Netze über den VPN Tunnel.
1
Optimal, vielen Dank nochmal für deine Zeit! Die Idee mit der Zusammenfassung der Subnetze ist hammer, meine Lösung wäre jetzt einfach ein NAT gewesen. Mit dieser Config funktioniert es inzwischen bei mir einwandfrei! Es gab noch eine alte (inaktive) IPsec Verbindung, weshalb das 4er-Subnetz auf der Fritzbox nicht richtig geroutet wurde. Nachdem ich die entfernt habe und mit dem /23-er wie oben beschrieben das Ganze konfiguriert habe, klappte alles auf Anhieb!
meine Lösung wäre jetzt einfach ein NAT gewesen.
Hätte auch nicht geklappt, weil du damit die Problematik der statischen Route nicht hättest lösen können.Klasse das es nun rennt wie es soll. 👍👏
Wird sicher auch dem Kollegen @Visucius helfen dessen Thread wir hier etwas "gekapert" haben aber wenn es der Lösung dient ist das ja für einen guten Zweck...?!
Mit den IP Netzwerken muss man natürlich aufpassen das man keine doppelten Netze hat. Das ist aber eine Binsenweisheit die ja allgemein immer gilt beim IP Adressdesign. 😉
Case closed...
@aqui: Was für eine tolle Beachreibung! Danke!
Eine Frage: Ich habe eine FB A, die als Wireguard-Server einer anderen FB B arbeitet. Alles ok.
FB A soll nun gleichzeitig Initiator eine zweiten Site-to-Site-Wireguard-Verbindung mit einem anderen Wireguard-Server sein (Debian, wie von Dir ganz oben beschrieben).
Geht das überhaupt? Und wie kriegt man denn die Config-Datei auf die FB A? Einfach „as is“ importieren? Was passiert dann mit den vorhandenen Konfigurationen?
Eine Frage: Ich habe eine FB A, die als Wireguard-Server einer anderen FB B arbeitet. Alles ok.
FB A soll nun gleichzeitig Initiator eine zweiten Site-to-Site-Wireguard-Verbindung mit einem anderen Wireguard-Server sein (Debian, wie von Dir ganz oben beschrieben).
Geht das überhaupt? Und wie kriegt man denn die Config-Datei auf die FB A? Einfach „as is“ importieren? Was passiert dann mit den vorhandenen Konfigurationen?
Danke für die 💐 ! 😊
Das Problem ist das Importieren der notwendigen Keys was normal kein Thema ist aber leider sieht AVM das so in seiner Implementation nicht vor. Keys gehen beim Neuupload der Konfig verloren und damit auch die Konfig an sich. Ist sicher nicht so einfach...
Eine manuelle Anpassung über den Abschnitt der VPN Konfiguration in der Sicherungsdatei (ab Abschnitt vpncfg {....} hilft da leider auch nicht.
Ein wasserdichter und ggf. besserer Workaround ist für die Anbindung an den Debian Server stattdessen IPsec zu verwenden.
Beide VPN Installationen koexistieren auf der Fritzbox ohne Probleme und Strongswan ist im Handumdrehen auf dem Debian installiert. Eine detailierte Lösung findest du hier:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Du benötigst natürlich lediglich den Connection Part der FritzBox in der Konfig. 😉
FB A soll nun gleichzeitig Initiator eine zweiten...
Das ist ein Interessanter Aspekt. Leider kann man bei der FB nicht wie im Gegensatz bei klassischen Wireguard Konfigs oder IPsec einfach einen zusätzlichen Peer dazukonfigurieren, denn das lässt die "spezielle" AVM Konfiguration so nicht zu. Bei Wireguard muss in der FB die komplette Konfig neu gemacht werden.Das Problem ist das Importieren der notwendigen Keys was normal kein Thema ist aber leider sieht AVM das so in seiner Implementation nicht vor. Keys gehen beim Neuupload der Konfig verloren und damit auch die Konfig an sich. Ist sicher nicht so einfach...
Eine manuelle Anpassung über den Abschnitt der VPN Konfiguration in der Sicherungsdatei (ab Abschnitt vpncfg {....} hilft da leider auch nicht.
Ein wasserdichter und ggf. besserer Workaround ist für die Anbindung an den Debian Server stattdessen IPsec zu verwenden.
Beide VPN Installationen koexistieren auf der Fritzbox ohne Probleme und Strongswan ist im Handumdrehen auf dem Debian installiert. Eine detailierte Lösung findest du hier:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Du benötigst natürlich lediglich den Connection Part der FritzBox in der Konfig. 😉
1
Hm, das hatte ich geahnt…
IPSec/StrongSwan auf Debian habe ich aktuell am laufen. Da der Tunnel für eine Backup-Lösung dient, hätte ich gerne den angeblich „sagenhaft“ bessere Durchsatz von Wireguard genutzt (wobei ich nicht einmal weiß, ob nicht das Synology Hyper Backup der eigentliche Flaschenhals ist).
Alternativ könnte man wohl auch das Debian als Initiator konfigurieren und die FB A ausschließlich als Wireguard-Server nutzen. Oder FB B zum Server machen und Fritzbox A als Initiator für Debian und FB B, oder?
Danke
Graefe
IPSec/StrongSwan auf Debian habe ich aktuell am laufen. Da der Tunnel für eine Backup-Lösung dient, hätte ich gerne den angeblich „sagenhaft“ bessere Durchsatz von Wireguard genutzt (wobei ich nicht einmal weiß, ob nicht das Synology Hyper Backup der eigentliche Flaschenhals ist).
Alternativ könnte man wohl auch das Debian als Initiator konfigurieren und die FB A ausschließlich als Wireguard-Server nutzen. Oder FB B zum Server machen und Fritzbox A als Initiator für Debian und FB B, oder?
Danke
Graefe
IPSec/StrongSwan auf Debian habe ich aktuell am laufen.
Dann wäre das doch perfekt. So "sagenhaft" ist der Unterschied in der aktuellen Firmware gar nicht solange man nicht mit SHA512 Hashing in Verbindung mit DH14 arbeitet an der FB. (Siehe dazu HIER)
Ist also besser man belässt es bei SHA1 und DH2 oder DH14.
Bester Kompromiss ist es dann die LT8 (Standard 8 Stunden Lifetime) Variante im Main Mode (Tutorial) zu verwenden und mit SHA1, 512 und DH2 zu arbeiten was superstabil rennt.
Alternativ könnte man wohl auch das Debian als Initiator konfigurieren
Ja, das geht problemlos wenn du mit diesen Varinaten das bezogen auf Wireguard meinst. Mit IPsec geht das ja so oder so immer.1
@aqui:
Vielen Dank für Deine Bemühungen. Kann es gerade nicht selber testen, mangels Zeit. Gehe aber – bei der von Dir gewohnten Perfektion – davon aus, dass das so fliegt und habe die 2 entsprechenden "Haupt"-Beiträge als Lösung markiert.
Vielen Dank nochmal ... vermutlich auch von vielen anderen, die den Thread hier ggfs. für Google finden
Vielen Dank für Deine Bemühungen. Kann es gerade nicht selber testen, mangels Zeit. Gehe aber – bei der von Dir gewohnten Perfektion – davon aus, dass das so fliegt und habe die 2 entsprechenden "Haupt"-Beiträge als Lösung markiert.
Vielen Dank nochmal ... vermutlich auch von vielen anderen, die den Thread hier ggfs. für Google finden
1
Ja, klappt alles wasserdicht und absolut stabil. Nicht nur mit Mikrotik sondern auch mit OPNsense / pfSense und generell allen routenden Endgeräten die Wireguard supporten.
Dein Thread sollte hier aber nicht weiter "gekapert" 🏴☠️ werden und bei neuen Fragen besser auch ein neuer Thread eröffnet werden mit einem entsprechenden Verweis. 😉
Dein Thread sollte hier aber nicht weiter "gekapert" 🏴☠️ werden und bei neuen Fragen besser auch ein neuer Thread eröffnet werden mit einem entsprechenden Verweis. 😉
Zitat von @aqui:
Bester Kompromiss ist es dann die LT8 (Standard 8 Stunden Lifetime) Variante im Main Mode (Tutorial) zu verwenden und mit SHA1, 512 und DH2 zu arbeiten was superstabil rennt.
Bester Kompromiss ist es dann die LT8 (Standard 8 Stunden Lifetime) Variante im Main Mode (Tutorial) zu verwenden und mit SHA1, 512 und DH2 zu arbeiten was superstabil rennt.
Könntest Du als Beispiel eine entsprechende config für StrongSwan posten?
Ist doch schon alles hier im Forum! Guckst du hier:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Den unteren Teil "ikev2-mobile-defaults {...}" kannst du dir wegdenken der ist nur fürs Dialin VPN mit IKEv2. Die Phase2 SAs local_ts und remote_ts musst du auf deine IP Adressierung anpassen. Local ist hier die 2te. Loopback Adresse. Die 2te Loopback brauchst du nur dann wenn du einen "one armed" Server hast wie z.B. einen vServer der nur ein Internet Interface hat. Ansonsten legst du local_ts auf das LAN IP Netz bzw. die Netze die du im VPN Tunnel bedienen willst.
Deine Strongswan sollte dann so aussehen. Beachte das diese das neue und modernere swanctl Konzept benutzt für das Setup!!:
Die dazu korrespondierende Fritzbox VPN Konfig Datei zum Importieren:
Wenn das eine etwas längere Session wird hier, solltest du einen separaten Thread aufmachen mit einem hiesigen Verweis darauf um nicht den Thread des Kollegen @Visucius hier zu kapern. 🏴☠️ 😉
(Siehe z.B. hier)
Guckst du hier:IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Den unteren Teil "ikev2-mobile-defaults {...}" kannst du dir wegdenken der ist nur fürs Dialin VPN mit IKEv2. Die Phase2 SAs local_ts und remote_ts musst du auf deine IP Adressierung anpassen. Local ist hier die 2te. Loopback Adresse. Die 2te Loopback brauchst du nur dann wenn du einen "one armed" Server hast wie z.B. einen vServer der nur ein Internet Interface hat. Ansonsten legst du local_ts auf das LAN IP Netz bzw. die Netze die du im VPN Tunnel bedienen willst.
Deine Strongswan sollte dann so aussehen. Beachte das diese das neue und modernere swanctl Konzept benutzt für das Setup!!:
connections {
fritzbox {
local_addrs = <server_ip_addresse>
remote_addrs = 0.0.0.0/0
local {
auth = psk
id = <server_ip_addresse>
}
remote {
auth = psk
id = keyid:strongswan@fritz.box
}
children {
net {
local_ts = 172.25.25.0/28
remote_ts = 192.168.178.0/24
esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
}
}
version = 1
proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
}
}
secrets {
ike-1 {
id = keyid:strongswan@fritz.box
secret = "test1234"
}
} Die dazu korrespondierende Fritzbox VPN Konfig Datei zum Importieren:
vpncfg {
connections {
enabled = yes;
editable = no;
conn_type = conntype_lan;
name = "StrongSwan";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = <server_ip_addresse>;
remote_virtualip = 0.0.0.0;
keepalive_ip = 172.25.24.1;
localid {
key_id = "strongswan@fritz.box";
}
remoteid {
ipaddr = <server_ip_addresse>;
}
mode = phase1_mode_idp;
phase1ss = "LT8h/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.178.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 172.25.25.0;
mask = 255.255.255.240;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 172.25.25.0 255.255.255.240";
}
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";
} (Siehe z.B. hier)
1
