Wir haben eine Handvoll Kunden, die nutzen eine FRITZ!Box als Router. Da wir viel via VPN machen (siehe Für verschiedene Kunden-Szenarien VPN-Router in der Werkstatt virtualisieren), wie z.B. neue PCs vorbereiten, Service-Fälle oder Rechner-Wechsel, usw., wurde es notwendig ein Site-to-Site VPN, oder wie es bei AVM heißt “LAN-LAN-Kopplung”, umzusetzen.
Zum Einsatz kommt in unserer Werkstatt ein virtueller OpenWrt-Router (auf Basis unserer Vorlage) und auf Kunden-Seite läuft eine FRITZ!Box 7490. Daraus ergibt sich, das sich OpenWrt via WireGuard zur FRITZ!Box verbindet.
Die FRITZ!Box dient nur als Router, dahinter befindet sich eine Windows-Domäne mit eigenem DNS-Server. Auf der FRITZ!Box-Seite wird (für diesen Beitrag) das Netz 192.168.178.0/24 genutzt und auf der OpenWrt-Seite wird das Netz 192.168.20.0/24 (wie in der AVM-Doku, siehe Quellen) verwendet.
FRITZ!Box konfigurieren
Warum auch immer setzt AVM zwingend ein konfiguriertes DDNS (Muss kein MyFritz sein!) voraus, andernfalls kann man kein WireGuard in den FRITZ!Boxen konfigurieren. Dies gilt auch, wenn man die “LAN-LAN-Kopplung” mit zwei FRITZ!Boxen realisieren möchte! Ist diese Voraussetzung gegeben, kann man direkt unter
Internet - Freigaben - VPN (WireGuard)
nach einem Klick auf “Verbindung hinzufügen” den Einrichtungsassistenten starten.
Anbei als Bilderstrecke der Ablauf:
Wichtig: Das Herunterladen der Einstellungen im letzten Dialog ist extrem relevant, denn später erhält man diese Möglichkeit nicht mehr!
Hat man die Konfigurationsdatei heruntergeladen zusätzlich noch unter
Internet - Freigaben - VPN (WireGuard) - <Name der Site-to-Site-Verbindung>
den öffentlichen Schlüssel kopieren, da man diesen für die Einrichtung der Gegenstelle benötigt.
OpenWrt konfigurieren
Die zuvor von der FRITZ!Box heruntergeladene “wg_config.conf”-Datei mit einem Editor, z.B. Notepad, öffnen und wie folgt fortfahren:
- Unter “Network – Interfaces” auf “Add new interface” klicken.
- Einen Namen, z.B. wg0, eingeben und bei “Protocol” “WireGuard VPN” auswählen.
- Auf “Create interface” klicken.
- Auf der Registerkarte “General” den privaten Schlüssel aus der Konfigurationsdatei und den zuvor kopierten öffentlichen Schlüssel eintragen.
- Bei “IP Addresses” die IP-Adresse aus der Konfigurationsdatei, z.B. “192.168.178.1/24”, eintragen.
- Zur Registerkarte “Firewall Settings” wechseln.
- “Create / Assign firewall-zone:” Aufklappen und bei “custom” einen Namen, wie z.B. “wg”, eintragen.
- Zur Registerkarte “Peers” wechseln.
- Auf “Add Peer” klicken.
- Bei “Description:” einen Namen eingeben.
- Den öffentlichen Schlüssel der FRITZ!Box und den PSK aus der Konfigurationsdatei eintragen.
- Bei “Allowed IPs” das Netzwerk der Gegenstelle aus der Konfigurationsdatei, z.B. “192.168.178.0/24”, eintragen.
- “Route Allowed IPs” aktivieren.
- Bei “Endpoint Host” die öffentliche IP-Adresse oder den FQDN/DDNS der Gegenstelle eintragen.
- Bei “Endpoint Port” den auf der Gegenstelle verwendeten Port eintragen.
- Bei “Persistent Keep Alive” den Wert “25” eintragen.
- Auf “Save” klicken.
- Zu “Network – Firewall – General Settings” wechseln, beim Eintrag “wg => lan” auf “Edit” klicken und wie folgt konfigurieren:
Input: accept
Allow forward to destination zones: lan
Allow forward from source zones: lan - Auf “Save” klicken.
- Auf “Save & Apply” klicken.
Damit ist die eigentliche Konfiguration für das Site-to-Site-VPN auf der OpenWrt-Seite abgeschlossen. Damit die DNS-Namensauflösung funktioniert, kann man das DNS-Suffix und den DNS-Server der Gegenstelle via DHCP an die Clients auf der OpenWrt-Seite verteilen lassen:
-
- Unter “Network – Interfaces – lan” auf “Edit “klicken und auf die Registerkarte “DHCP Server – Advanced Settings” wechseln.
- Bei “DHCP-Options” folgendes Eintragen:
6, <DNS-Server der Gegenstelle>, 9.9.9.9
Bemerkung: In diesem Beispiel wird neben dem DNS-Server der Gegenstelle zusätzlich noch ein weiterer DNS-Service, hier von Quad9, übermittelt. Man könnte auch die IP-Adresse von OpenWrt eintragen. Der Hintergedanke dazu ist, funktioniert das VPN nicht würde auch überhaupt kein DNS klappen. Damit wenigstens das Internet funktioniert, sollte ein zweiter Eintrag vorhanden sein.
- Auf “Save” klicken.
- Zu “Network – DHCP and DNS” und auf der Registerkarte “General” bei “Local domain:” die DNS-Domain der Gegenstelle eintragen.
Bemerkung: In diesem Beispiel ist es so, das alle Standorte bzw. Systeme sich in der selben DNS-Domain befinden (sollen). Das ist hilfreich, damit die Auflösung zu Ressourcen die nur mit dem Hostname angegeben sind, z.B. “\\srv01\share”, funktioniert. - Auf “Save” klicken.
- Auf “Save & Apply” klicken.
Troubleshooting
Auch wenn sich diese Zeilen einfach lesen und es letztlich, wenn man es weiß, kein Problem ist eine solche Vernetzung zu realisieren, so hat es mich dennoch zwei Abende und einen Nachmittag gekostet bis es richtig lief. Daher anbei ein paar Anmerkungen und ein paar Tipps:
Dem aufmerksamen Leser bzw. WireGuard-Admin dürfte auffallen, das kein Transfer-Netz verwendet wird. Bis zu diesem Aufbau wusste ich nicht, das dies bei WireGuard so möglich ist, AVM hat mich eines besseren belehrt.
In OpenWrt fällt einem spätestens unter “Network – Interfaces” auf, das sowohl die LAN- als auch die WireGuard-Schnittstelle die gleiche IPv4-Adresse verwenden. In diesem Kontext ist das offenbar normal.
Unter OpenWrt lässt sich tcpdump installieren und ausführen. Mit folgenden Befehl auf der Konsole oder via ssh kann der ein-/ausgehende Datenverkehr auf der WireGuard-Schnittstelle angezeigt werden:
tcpdump -i wg0
Testweise kann man unter OpenWrt die Firewall deaktivieren, um so prüfen zu können, ob diese eine erfolgreiche Datenübertragung durch den Tunnel verhindert:
/etc/init.d/firewall stop
Bei einer FRITZ!Box besteht die Möglichkeit den Datenverkehr mitzuschneiden um diesen anschließend in Wireshark analysieren zu können. Siehe
AVM FRITZ!Box: Paketmitschnitt erstellen
So fand sich während des Aufbau des hier beschriebenen VPNs folgendes beim Ping-Test:
854 20.685518 192.168.20.1 192.168.178.31 ICMP 102 Destination unreachable (Port unreachable)
Dies entspricht der Meldung unter Windows beim Ping:
... Zielport nicht erreichbar.
Kurzum: Die Firewall blockiert. So fand ich heraus, das auf der OpenWrt-Seite bei der Firewall-Konfiguration für WireGuard bei “Input” “accept” gesetzt sein muss.
Wie hat Dir der Artikel gefallen ?
(4 Stimmen, durchschnittlich 5,00 von 5 Sternen)
Loading...
Du möchtest den Blog unterstützen ?
Neben PayPal.ME gibt es noch weitere Möglichkeiten, lies hier wie du diesen Blog unterstützen kannst.
Quellen
AVM – Service – VPN – WireGuard-VPN zwischen zwei FRITZ!Box-Netzwerken einrichten
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 15 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Hallo Andy,
vielen Dank für Deinen Eintrag, der mir sehr geholfen hat. Ich kenn mich recht gut aus, nur beim Netzwerken gibt es Defizite…
Ich habe meinen OpenWRT Router erfolgreich mit meiner FritzBox verbunden.
Also OpenWRT ist mit dem WLAN meines Nachbarn verbunden(wwan), die Wireguard Verbindung steht, das sehe ich in der FritzBox. Allerdings gehen alle Pakte des Clients nicht über das Interface wg0, sondern über wwan? Also meine externe IP-Adresse ist die meines Nachbarn und nicht die meiner FritzBox…
Ich glaube, da passt etwas mit dem Routing nicht. Kannst Du mir helfen?
Liebe Grüße
Andreas
Wenn man jedweden Traffic durch den Tunnel schicken möchte, muss das Routing angepasst werden. Im OpenWrt bei Allowed IPs 0.0.0.0/0, die Firewall-Regel muss man dann auch anpassen. Wie das genau aussehen muss kann ich mangels Erfahrung in dieser Kombi gerade nicht sagen. Ich kann das gerne die Woche Mal nachstellen.
Genau, das will ich… die 0.0.0.0/24 habe ich eingetragen und auch mit der Firewall etwas versucht. Ich war aber nicht erfolgreich…
Es wäre toll, wenn Du die Zeit finden würdest das für mich nachzustellen!
PS: Danke für die schnelle Antwort… am Sonntag… ☺️
PPS: es geht wohl doch nicht alles… genaugenommen funktioniert nur die Wireguard-Verbindung zur FritzBox, aber ich kann im LAN der FritzBox keinen Server erreichen…
> 0.0.0.0/24
War ein Schreibfehler von mir, gemeint ist 0.0.0.0/0, hab’s im Kommentar bereits korrigiert.
Man darf sich bei WireGuard nicht täuschen lassen, im Gegensatz zu IPsec oder OpenVPN bedeutet “Tunnel aufgebaut” oder eine grüne Anzeige nicht, das der Tunnel wirklich funktioniert. Das kommt daher da WireGuard stateless ist, d.h. es werden Pakete nur gesendet (und verschlüsselt), wenn es benötigt wird.
Mit ein wenig Glück kann ich morgen danach schauen, hab’ das Setup auf dem der Beitrag beruht nach wie vor in der Werkstatt.
Wie besprochen habe ich mal getestet. In meinem Fall hat es ausgereicht im OpenWrt im Peer (der FritzBox) den Wert von “Allowed IPs” von “192.168.178.0/24” zu “0.0.0.0/0” zu ersetzen. Sicherheitshalber wurde dann WireGuard einmal neu gestartet. Vom Client hinter dem OpenWrt aus wurde dann zunächst mittels ping.eu im Browser geschaut welche öffentliche IP zurückgemeldet wird, hier kommt nun die WAN-IP der FritzBox. Ein tracert zu Google (8.8.8.8) bestätigt das funktionierende Routing. Hier die gekürzte Ausgabe mit Kommentaren:
C:WindowsSystem32>tracert 8.8.8.8
Routenverfolgung zu dns.google [8.8.8.8]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 192.168.20.1 <- LAN-IP des OpenWrt
2 20 ms 20 ms 21 ms 192.168.1.1 <- LAN-IP der Fritz!Box
3 34 ms 31 ms 31 ms 195.78.189.144 <- ecotel-Gateway da easybell-Anschluss
…
11 34 ms 33 ms 32 ms dns.google [8.8.8.8]
Getestet wurde von einem Anschluss der Deutschen Glasfaser (OpenWrt-Seite), über S2S-VPN zu einem Anschluss von easybell (Fritz!Box-Seite).
Nochmal vielen Dank für Deine Bemühungen!
Nachdem ich den OpenWRT-Router neu gestartet hatte klappt wenigstens die Verbindung zum Peer (FritzBox). Ein Down und Up des wg0-Interface war nicht ausreichend.
Ich erreiche jetzt vom Laptop aus zum Beispiel meine NAS, wenn ich aber 0.0.0.0/0 im Peer unter “Allowed IPs” eintrage ist meine externe IP-Adresse weiterhin die meines Nachbarn, also nicht die des VPN.
Ich denke, jetzt sollte ich mich ams Forum von OpenWRT wenden…
Sorry, kleiner Fehler oben…
Ich erreiche das NAS vom OpenWRT-Router aus, NICHT vom Laptop…
Was ich gerade sehe.. das Default Gateway des OpenWRT-Routers zeigt zum Router meines Nachbarn. Sollte das nicht meine FritzBox sein?
Beschreib bitte mal deinen Netz-Aufbau, damit man besser nachvollziehen kann, wo welches Gerät ist.
Bitte auch das gewünschte Ergebnis mit Angeben, also sowas wie ob nur die beiden Netze gekoppelt werden sollen oder ob jedweder Datenverkehr durch den Tunnel soll, usw.
Gerne… mittlerweile geht auch der Verkehr ohne WireGuard nicht mehr…
Hintergrund ist, ich möchte einen Travel-Router mit WireGuard an meine FritzBox anschliessen um außerhalb Deutschlands ZDF und ARD sehen zu können:
Zum Testen das WLAN meines Nachbarn mit 192.168.0.0/24
FritzBox mit 192.168.178.0/24
GL.inet Mango Router mit OpenWRT mit 192.168.1.0/24
FritzTV-Stick zum fernsehen
Aller Traffic soll durch OpenWRT nach Deutschland zur FritzBox .
Der GL.inet hat zwei WLAN Interface. Das eine Interface ist mit dem WLAN meines Nachbarn verbunden. Das andere Interface ist mit meinem Laptop verbunden, da soll dann der FritzTV hin..
Der GL.inet soll eine VPN-Tunnel zur FritzBox aufbauen. Der Laptop soll sich mit dem GL.inet verbinden und durch den Tunnel ins Internet, allerdings als ob er in Deutschland wäre.
Alles was mit dem GL.inet verbunden ist soll durch den Tunnel.
Ich habe mich jetzt doch im OpenWRT Forum gemeldet, Du hast mir eh genug geholfen:
https://forum.openwrt.org/t/wireguard-side-to-side-with-avm-fritzbox-i-need-help/
und dies war der Haupt-Fehler bei mir:
Enable Masquerading on the WG zone, so add:
option masq ‘1’
Jetzt gibt es noch ein kleines DNS Problem, das werden wir aber auch noch lösen.
Viele Grüße
Andreas
Und auch das wurde gelöst:
Luci DNS-DHCP > Filter > Rebind protection untick/disable
/etc/config/dhcp > config dnsmasq
option rebind_protection ‘0’
Danke dir für das Feedback und die Updates. Freut mich, das es nun läuft. Dann kann der Urlaub ja kommen.
Hey, danke für die Anleitung, jedoch habe ich ein komisches Verhalten: Ich kann von openwrt-Seite das entfernte FB-Lan erreichen, andersherum jedoch nicht (auch kein ping eines FB-LAN-Rechners zum Openwrt-Gerät).
Gibts hier noch tipps?
Könnte am Routing oder der Firewall liegen.
Ich hab’s gerade mal bei mir getestet, da läuft es in beide Richtungen.
Evtl. mal wie im Beitrag beschrieben mal die Firewall deaktivieren und testen.
Wenn es dann funktioniert, muss es an der Firewall liegen, wenn nicht, dann vmtl. Routing.
Beide Seiten, gemeint sind die Router, schon mal neu gestartet?
Hallo Andy,
zunächst einmal vielen Dank für dein Engagement hier.
Ich habe ein ähnliches Setup und komme an einem Punkt nicht weiter.
Folgendes Setup:
Auf Seite OpenWRT 3 Netze:
– wg 192.168.7.0/24
– LAN 192.168.8.0/24
– WAN (DHCP)
Auf Seite FB
– 192.168.1.0/24
– wireguard Verbindung ins Netz 192.168.7.0/24
Firewall Setup OpenWRT:
– wg Zone in LAN – Masquerading
– LAN Zone forward to wg und WAN
Was geht:
– Zugriff von 192.168.1.0/24 über wireguard auf das 192.168.7.0/24 Netz
– Zugriff über ssh auf Openwrt und von dort per ssh in das 192.168.8.0/24 Netz
– Zugriff vom 192.168.8.0/24 (OpenWRT LAN) auf das 192.168.1.0/24 (FB LAN)
– Zugriff vom LAN ins Internet (WAN)
Was geht nicht
– Zugriff vom 192.168.1.0/24 (FB Netz) auf das 192.168.8.0/24 (OpenWRT LAN)
–> nachvollziehbar, weil die FB nicht weiß, dass das .8.0/24 Netz hinter der WG Verbindung zu finden ist.
Das Problem ist, dass ich bei dem FB WG Setup nur ein Zielnetz angeben kann. Ich kann auf der FB auch keine Netz-Route anlegen mit der 192.168.7.1 als Gateway (wird als ungültig markiert)
Mit anderen Worten, ich weiß nicht, wie ich einem Host auf der FB LAN Seite klar machen kann, dass das 192.168.8.0/24 Netz (OpenWRT LAN) über den Hop 192.168.8.1 erreichbar ist.
Hast du eine Idee?
Vielen Dank!
Gruß,
Oliver
Hallo Oliver,
verstehe ich das richtig, das “192.168.7.0/24” das VPN-/Transfer-Netz ist?
Falls ja, dann liegt hier das “Problem”, da die FRITZ!Box kein VPN-/Transfer-Netz kennt bzw. nutzt.
Man muss direkt das LAN-Netz der Gegenseite in der Fritte eintragen, das wäre demnach “192.168.8.0/24”.
Zum Verständnis noch gefragt: Welche Seite verbindet sich via WG zu wem?
OpenWrt -> FB?
oder
OpenWrt <- FB? oder OpenWrt bidirektional/vice-versa FB?
Das Netz “192.168.20.0/24” aus dem Beitrag und der AVM/FRITZ-Doku entspricht dem LAN-Netz der Gegenseite, es ist kein VPN-/Transfer-Netz.
Hallo Andy,
danke für die Rückmeldung.
Das Ganze soll eine Netzkopplung sein, also bidirektional.
Zum Verständnis: auf Seiten oWRT brauche ich ein Interface vom Typ Wireguard, das eine IP bekommt.
Ein weiteres Interface brauche ich um das eigentliche LAN zu definieren, um zB einen DHCP Server und ein Gateway zu bekommen. Dieses bekommt auch eine IP. Sind dann beide IPs im selben Netz?
Sind dann beide Interfaces in der gleichen Zone?
Irgendwie kann ich mir eine Netzkopplung nicht ohne Transportnetz vorstellen….
Gruß,
Oliver
Wie bereits erwähnt, die Fritte nutzt kein Transportnetz, sondern vergibt auf den WG-Interfaces das Subnetz der anderen Seite. Hab’ das Anfang des Jahres, als der Beitrag entstanden ist, mir auch erst nicht vorstellen können, ist aber so, ganz gleich ob man zwei FBs hat oder eine FB und OpenWrt (oder was anderes) und für die LAN-LAN-Kopplung nutzt. Man kann das Ganze relativ gut im Backup der Fritte rauslesen.
Ab “vpncfg {” findet sich die VPN-Konfiguration.
Hier findet sich kein Transfer-Netz (übrigens auch nicht für Roadwarrior).
Schaut man in die “wg_config.conf” die die Fritz!Box erzeugt und die für die Gegenseite bei LAN-LAN-Kopplung bestimmt ist, sieht man folgendes:
[Interface]
…
Address = 192.168.20.1/24
…
[Peer]
…
AllowedIPs = 192.168.178.0/24
…
Bei Address erwartet man für gewöhnlich ein Transfer-Netz, das ist hier auch nicht der Fall, dort steht die LAN-IP des Gegenstellen-Routers, also am Beispiel des Beitrags die LAN-IP des OpenWrt.
Guten Morgen,
ich habe es nun zum Laufen gebracht. Aber “sauber” sieht das für mich nicht aus 🙁
Auf oWRT Seite: wireguard interface und Interface ins LAN (Gateway) im gleichen Netz (wg x.254 und gw x.1)
Dann sieht ein traceroute wie folgt aus:
Vom FB LAN (192.168.1.12) über wireguard Tunnel ins oWRT Netz:
traceroute to 192.168.7.10 (192.168.7.10), 64 hops max
1 192.168.1.1 0.967ms 1.468ms 1.619ms <— FB default gw
2 192.168.7.254 3.100ms 1.435ms 1.639ms <— oWRT wg Interface
3 192.168.7.10 2.871ms 1.588ms 1.674ms <— Zielhost
Vom oWRT LAN (192.168.7.10) über wireguard Tunnel ins FB Netz:
traceroute to 192.168.1.12 (192.168.1.12), 30 hops max, 60 byte packets
1 OpenWrt.lan (192.168.7.1) 0.677 ms 0.736 ms 0.448 ms <— oWRT LAN gw
2 192.168.1.12 (192.168.1.12) 3.583 ms 5.590 ms 3.480 ms <— Zielhost
3 * 192.168.1.12 (192.168.1.12) 4.833 ms 4.729 ms
Vom oWRT LAN (192.168.7.10) über WAN ins Internet:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 OpenWrt.lan (192.168.7.1) 0.618 ms 0.984 ms 0.831 ms
2 192.168.179.1 (192.168.179.1) 3.337 ms 3.297 ms 3.842 ms
3 * * *
4 de-ess01a-cr07-eth-6-0-1070.ess.unity-media.net (81.210.136.162) 19.215 ms 20.881 ms 20.850 ms
5 de-ess01a-rd03-ae-0-0.aorta.net (84.116.196.82) 25.458 ms 27.269 ms 27.469 ms
6 de-fra01b-rc2-ae-14-0.aorta.net (84.116.197.46) 30.606 ms 27.860 ms 27.750 ms
7 de-bfe18a-rt01-lag-1.aorta.net (84.116.190.34) 24.118 ms 27.216 ms 27.137 ms
8 * 74.125.32.52 (74.125.32.52) 19.802 ms 24.119 ms
9 * * *
10 dns.google (8.8.8.8) 22.690 ms 22.502 ms 20.822 ms
Funktionert, ist aber alles andere als ein "ästhetisches" Netz-Design 😉
Danke für den Support!
Oliver