Hallo zusammen,
ich hoffe Ihr könnt mir helfen bzw. mir erklären ob mein Vorhaben überhaupt funktioniert.
Folgende Konstelation habe ich:
Site A (Home) :
Netz: 192.168.178.0/24
FritzBox die kein Wireguard nativ unterstützt.
DynDNS Funktion ist gegeben
Öffentlich IP ist v4.
Site B (Remote) :
Netz: 192.168.124.0/24
FritzBox die Wireguard unterstützt.
DynDNS Funktion ist gegben.
Öffentliche IP ist v4.
Auf Site A (Home) habe ich einen raspberrypimit Docker und einem Wireguard Container erstellt. Dieser soll sich via Wireguard mit der Site B (Remote) verbinden.
Ich möchte das ich aus Site A zu Site B komme und andersherum.
Aktuell schaff ich es nur das ich von Site A die Site B über Masquerading erreiche, aber von Site B zu Site A geht nicht.
Ist mein Vorhaben mir der aktuellen Konstellation mit einer FB die Wireguard kann und einem client auf demraspi überhaupt möglich? Habe ich da eventuell einen Denkfehler?
Vielen Dank im Voraus
Moin,
Also diese WireGuard-in-Docker-Geschichten haben nach meiner Erfahrung noch nie gut funktioniert. Bau das lieber auf dem Pi direkt…
Und ja, die eine FB kann da auch noch mit reinspielen, weil man da mit der Config aufpassen muss…
Generell sollte es kein Problem sein, wenn die Verbindung nur von Site A zu Site B aufgebaut werden kann. Du musst dann halt nur dafür sorgen, dass diese Verbindung persistent konfiguriert wird.
Mit anderen Worten: Die Site a muss die Verbindung immer umgehend nach jeder zwangstrennung wieder neu aufbauen und ein Keep-Alife muss dafür sorgen, dass sie auch nicht abgebaut wird, wenn kein Traffic über den Tunnel geht.
Vielen Dank für die Rückmeldungen.
Ich konnte bereits über eine längere Zeit die Verbindung von Site A zu Site B aufrecht erhalten.
Bei der Konfiguration ist die Wireguard Konfig in der FB als Client und nicht als LAN2LAN definiert. Ich hatte es bis jetzt nicht geschafft den Docker Container mit LAN2LAN zu koppeln.
Muss hier auch noch was beachtet werden auf der Remote Site?
Ja, du musst am besten eine fertige Config importieren…
Und da darf kein Transfer etc genutzt werden, weil die Fritzbox sonst fehlerhaftes NAT macht und nichts richtig funktioniert
Du meinst die config die die FritzBox erstellt hat?
Ich habe schon gesehen, dass in der config bei Interface-Address die IP Adresse der FB in Site B steht. Ich wunderte mich schon warum da kein Transfernetz drin steht.
Aber das heißt dann schon das die FB Site B die Daten für das Netz in Site A in den Tunnel schiebt?
Das weiß ich nicht, was genau ging jetzt und was nicht?
Erwäge den Kauf einer neueren Fritteuse oder gleichwertigen Ersatzes. Alle Fritteusen, die noch mit Sicherheitsupdates versorgt werden, unterstützen inzwischen Wireguard.
Selbst die letzte Fritte aus der 74er Serie, die 7490, die noch auf OS 7.62 stehen bleibt wird noch mit Sicherheitsupdates versorgt und kann Wireguard. Die 7430 hingegen wird nicht mehr mit Sicherheitsupdates versorgt und kann auch kein Wireguard.
Eine 7430 muss daher als Risiko für das gesamte LAN betrachtet werden und wenn man dann dahinter noch per Wireguard in andere LAN’s kommt ist diese auch ein Risiko für diese anderen LAN’s,
Ich würde so eine Kiste nicht mehr am WAN betreiben wollen. Sie ist reif für den Wertstoffhof.
1 Like
Da hast Du natürlich recht. Momentan ist es aber leider hier nicht möglich eine neu Box zu verbauen.
Ich konnte jetzt aber erfolgreich den „Site2Site“ Verbinden und Daten zwischen beiden Sites schicken. Ich hatt bis jetzt auf der Site B eine „Einzelgerät Verbindung“ in der FritzBox konfiguriert. Nach dem ich eine LANzuLAN Verbidung eingerichtet habe lief es.
Jetzt habe folgendes Problem dadurch. Eventuell kann mir das nochmal einer erklären.
Wenn die Verbindung via Einzelgerät Verbindung steht gehen folgende Funktion bzw. gehen nicht:
„Einzelgerät Verbindung“
Funktioniert:
- Ping von Site A Wireguard Container → Site B Host (z.B. 192.168.124.48)
- Ping von Site A Docker Host → Site B Host (z.B. 192.168.124.48)
- Ping von Site A Host im Netz → Site B Host (z.B. 192.168.124.48)
Funktioniert NICHT:
- Ping von Site B Host (192.168.124.48) → Site A Host (z.B. 192.168.178.20)
„LANzuLAN“:
Funktioniert:
-
Ping von Site A Wireguard Container → Site B Host (z.B. 192.168.124.48)
-
Ping von Site A Docker Host → Site B Host (z.B. 192.168.124.48)
-
Ping von Site A Host im Netz → Site B Host (z.B. 192.168.124.48)
-
Ping von Site B Host (192.168.124.48) → Site A Host (z.B. 192.168.178.20)
Funktioniert NICHT:
- Ping von Site A Docker Host → Site B Host (z.B. 192.168.124.48)
- Ping von Site A anderer Docker Container → Site B Host (z.B. 192.168.124.48)
Ich habe mal gehört, dass das ein Problem mit den Docker Containern ist. Lösung wäre hier den Wireguard VPN auf einen externen raspi zu packen.
Kann da eventuell einer was dazu sagen?
Vielen Dank
LG
Zu Docker und den damit verbundenen Besonderheiten / Problemen kann ich nichts sagen, da ich kein Docker nutze. @m-electronics hat dir ja auch bereits von der Nutzung von Wireguard als Docker-Container abgeraten.
Du musst wissen was du tust 
Google aber mal: CVE-2026-31431.
Alle Linux-Distros liefern bzw. lieferten deswegen trotz langem Mai-Wochende bereits neue Kernel aus, damit Linux-Kernel-Lücke CVE-2026-31431 geschlossen wird.
Es hat schon einen tieferen Sinn nur Software zu verwenden, die noch mit Sicherheitsupdates versorgt wird. Du kannst jetzt denken, dass es ja dein Risiko ist, wenn eine nicht mehr sichere Fritte gehackt wird. Doch das ist leider eine nur bedingt zutreffende Annahme. WIrd die dann teil von Bot-Netzen wird, dann kann davon ein Risiko für andere ausgehen, weil damit Angriffe auf deren Hard-/Software gestartet wird. Im ungünstigsten Fall Angriffe auf Kritische Infrastruktur, wie z.B. Strom-, Gasversorger Notrufzentralen, Krankenhäuser, etc.
Im schlimmsten Fall kannste dann tagelang nicht mal mehr eine Dosensuppe zum erhitzen auf dem alten Campingkocher aus dem Keller beim Aldi oder Edeka kaufen, weil deren Kassensysteme ohne Strom ja auch nicht funktionieren.