Wireguard Lan-Lan Kopplung: Netze dahinter erreichbar machen

miomio

New member
Ich habe 2 Haushalte mit jeweils einer Fritzbox 7520 als DSL Modem. Ich nenne diese hier Client und Server, weil in einem Haushalt Server mit Diensten stehen, die in dem anderen genutzt werden sollen können, als erstes der Windows Domänencontroller.
Im Augenblick ist die Fritzbox "Client" auch der DHCP Controller für die Clients in diesem Haushalt, das wird sich später ändern, wenn ich hier noch einen richtigen Router anschaffe. Im Haushalt "Server" ist die Fritzbox nur DSL Modem im Einsatz und der eigentliche Router/Gateway dahinter ist als exposed Host konfiguriert, an den alles weitergeleitet wird. Für das Minimalbeispiel haben wir also 3 IP Bereiche, den von der Client FB, den Von der Server FB und den vom Server Router.
Nach Einrichtung der Wireguard Verbindung kann ich aus dem Netz des Server Routers die Client FB erreichen, aber aus dem Netz der Client FB nicht den Server Router. Klar, der Client Adressbereich steht in der Config des Tunnels drin, der vom Server Router nicht (Anmerkung, ich kann auch aus dem Client netz die Server Fritzbox erreichen, aber das ist halt kein Usecase). In der Maske der Wireguard Konfiguration auf der Fritzbox kann man nur einen Zieladressbereich eintragen. Ich habe im Internet gelesen, dass man die Config der Serverseite vor dem importieren im Client einfach kommaseperiert ergänzen soll:
Code:
AllowedIPs = 192.168.10.0/24, 192.168.1.0/24
Das hat mir nicht geholfen.
Ich weiß nicht genau wo es hängt bzw wie ich das analysieren soll. Ich habe ein tracert auf eine ServerIP vom Client-Netz aus gemacht und er geht von der Client FB mit dem nächsten hop direkt auf den Server, und nichtmal über die Server FB. Eigentlich würde ich erwarten: ClientFB->ServerFB->ServerRouter->Server(zB DC). Antworten gibt es ja keine , die Pings versacken direkt hinter der Fritzbox. Ich weiß also nicht, ob sie die Anfragen an das Servernetz überhaupt in den Wireguard Tunnel routet, und sie auf der anderen siete nicht ankommen, oder eben die Antworten nicht richtig zurückgeroutet werden.
 
. Im Haushalt "Server" ist die Fritzbox nur DSL Modem im Einsatz und der eigentliche Router/Gateway dahinter ist als exposed Host konfiguriert, an den alles weitergeleitet wird.
Dann schau doch mal dort nach (Firewall), oder lass direkt dort die VPN-Verbindung terminieren. Eine zusätzliche Route könntest Du auch auf der Client-Fritz!Box angeben. Davon ab: Wenn Du NAT auf Deinem Router/Gateway laufen hast, passiert folgendes:

Netze mal exemplarisch:

Client-Fritz!Box: 192.168.0.0/24
Server-Fritz!Box: 192.168.1.0/24
Gateway/Router: 192.168.2.0/24 (im Netz der Fritz!Box 192.168.1.2)

Paket startet im Client-Fritz!Box-Netzwerk wie folgt:
Quelle: 192.168.0.100 (Client)
Ziel: 192.168.2.100 (Zielhost)

Paket im Server-Fritz!Box-Netzwerk:
Quelle: 192.168.0.100 (Client)
Ziel: 192.168.2.100 (Zielhost) <- kennt die Server-Fritz!Box überhaupt die Route in dieses Netz?

Falls die Server-Fritz!Box die Route in das nachgelagerte Netzwerk kennt, schickt der Zielhost seine Antwort zurück:
Quelle: 192.168.2.100
Ziel: 192.168.0.100

Sofern jetzt NAT (Source-NAT) am Router/Gateway aktiviert ist, passiert folgendes mit dem Paket:
Quelle: 192.168.1.2
Ziel: 192.168.0.100

So wird das Paket auch beim ursprünglich anfragenden Client ankommen, welcher das Paket verwerfen wird, weil er von dieser Quelle keine Antwort erwartet.

Kannst es mal aus dem Router/Gateway testen. Wenn der Wireguard-Tunnel funktioniert, sollte ein anfragender Client aus dem Router/Gateway-Netz auch eine Antwort von der anderen Seite bekommen. Sofern Du die Möglichkeit hast, kannst Du ggf. auch NAT unterbinden, wenn Pakete durch den Tunnel gehen bzw. zum entsprechenden Zielnetz.

Ich persönlich fände es allerdings einfacher, wenn man einfach hingeht und den Wireguard-Tunnel direkt auf dem Router/Gateway terminieren lässt, da Du dort vermutlich auch wesentlich mehr Möglichkeiten bzgl. Logging/Konfiguration hast (weiss ja nicht, was Du da im Einsatz hast).
 
@Spielebernd: Die Routen alleine bringen es nicht, wenn die Gegenseite via NAT auch noch die Quelle überschreibt, dann passen die Paketinformationen nicht mehr zusammen und das Paket wird vom Client verworfen.
 
Also es ist alles genau wie du beschreibst, auch dass die server Fritzbox nattet also der Router für die Server Fritzbox ein client im eigenen DHCP Bereich ist und der Router selbst wiedeum in seinem Bereich Adressen vergibt. Dadurch dass aber er in der Fritzbox als exposed Host konfiguriert ist, sollte er jeglichen traffic abbekommen und das NAT dürfte keine Probleme machen, oder? letztenendes ist es doch genauso, wie wenn ein Client aus dem Internet eine Anfrage stellt, da kommt die Antwort ja auch über diese Kaskade wieder zurück. Beim Nat werden doch in den Antworten auch die Adressen ersetzt, damit der Client wieder etwas damit anfangen kann.

Hintergrund dieser Lösung ggü dem Tunnel direkt zum Server Router ist, dass die Fritzboxen beide nativ erstmal Wireguard sprechen könenn und die Verbindung ja grundsätzlich funktioniert. Der Router ist ein Freshtomato von 2020, der kann kein schnelles Protokoll wie wireguard. Da ist in die Konfiguration viel Zeit reingeflossen, so dass ich lieber kein Update riskieren will, denn wenn der "kaputt" geht habe ich hier richtig Arbeit, aber das wäre grundsätzlich ein klarer Ausweg (Vorausgesetzt, die sind auch miteinander kompatibel).

Die Client FB muss ja erstmal die zusätzlichen Adressbereiche aus der manuell angepassten Config übernehmen/akzeptieren. Kann man das irgendwie prüfen? Standardmäßig kann man ja nur den einen konfigurieren.

Statische Routen zufügen auf der Fritzbox kann man nur mit Ganteway IPs aus dem Adressbereich der eigenen Fritzbox. Ich denke mir, dass der Hersteller durch diese künstlichen Einschränkungen bei der Konfiguration genau so ein Szenario wie meins verhindern will. Die Frage ist, ob es dennoch mit den Fritzbox-Mitteln geht und das kann ich nicht einschätzen.
 
Und ich verstehe hier nur "ganz" wildes Konstrukt. :D Der Server mit seinem eigenen Netz (dahinter) ist in der FritzBox als "exposed host" eingetragen?! Warum?! Soll der Server selbst auch "nakt" im Internet stehen?!
 
Weil es mal hieß, ich weiß nicht ob das heute noch so ist, dass Fritzboxen die besten DSL Modems haben. Es gibt da noch was von Draytek aber das hat halt nicht so breiten Support in Deutschland wie die Fritzbox, also der Markt an desl Modems ist klein, aber Marktanteil von DSL in Deutschland als Zugangstechnologie riesengroß. Wie kann man sonst einen Router hinter die Fritzbox packen? Einen reinen Modembetrieb gibt es da ja nicht. Der Router ist im Internet genauso exposed wie die Fritzbox davor, ich sehe da keinen unterschied.
Ich finde es nicht so superwild, denn gerade in Deutschland sind die Fritzboxen als DSL Modems auch sehr populär, aber nicht jeder will die als Router benutzen.
Was ich zugebe, ist, dass man normalerweise einen Tunnel von Router zu Router hinter den Fritzboxen einrichten würde. Sicher der ordentliche Weg, aber trotzdem bleibt die Frage ob man dieses hier nicht auch konfigurieren kann.
 
Wie kann man sonst einen Router hinter die Fritzbox packen? Einen reinen Modembetrieb gibt es da ja nicht. Der Router ist im Internet genauso exposed wie die Fritzbox davor, ich sehe da keinen unterschied.
Könntest auch einfach nur benötigte Ports in der Fritz!Box an den hinteren Router durchreichen (so mache ich das, halt kein exposed host).
Dadurch dass aber er in der Fritzbox als exposed Host konfiguriert ist, sollte er jeglichen traffic abbekommen und das NAT dürfte keine Probleme machen, oder?
Najo, je nachdem halt...
letztenendes ist es doch genauso, wie wenn ein Client aus dem Internet eine Anfrage stellt, da kommt die Antwort ja auch über diese Kaskade wieder zurück. Beim Nat werden doch in den Antworten auch die Adressen ersetzt, damit der Client wieder etwas damit anfangen kann.
Grundsätzlich erstmal "nein". Es kommt auf die Art des NAT an. SNAT (Source-NAT/Quell-NAT) läuft bei Dir sowieso - alle internen IP-Adressen werden beim verlassen mit der öffentlichen IP des Routers überschrieben (damit externe Ziele, auch Antworten zurück schicken können). DNAT (Destination-NAT/Ziel-NAT) kennst Du auch - z.B. eine IPv4-Portweiterleitung in einer Fritz!Box. Das Ziel (öffentliche IP) wird umgeschrieben (interne IP).

Ich mag mich irren, aber die Fritz!Boxen waren sowieso schon immer etwas "eigen"... In welchem Netz befindest Du Dich denn grade? Falls Du im Client-Netz bist, versuch doch einfach mal die IP der Remote-Fritz!Box über den Browser aufzurufen, um zu überprüfen, ob diese Strecke überhaupt erstmal funktioniert (ist dem nicht so, kannst Du Dir alles andere auch erstmal sparen).

Ansonsten bliebe noch zu sagen, dass irgendwo zwischen internen Netzen ein NAT nicht wirklich Sinn macht. Demnach wäre a) auf der Fritz!Box (Server-Standort) die Route zum Netz hinter dem Tomato einzutragen (statische Route) und b) auf dem Tomato NAT zu deaktivieren. Bitte erst die Route anlegen und erst danach NAT deaktivieren(!).

https://fritz.com/apps/knowledge-ba...e-IP-Netzwerke-hinter-der-FRITZ-Box-zugreifen das hattest Du ja sicherlich auch schon gelesen?
 
Wobei, wenn der "exposed Host" ... sorry, das hatte ich wohl falsch verstanden. Ein "echter Router" ist, dann frage ich mich, wieso Du das Wireguard von FritzBox zu FritzBox machst?!

Ich würde es von "echtem Router" zu FritzBox machen, so lange in der "Außenstelle" noch kein richtiger Router ist. Und es dann auf Router - Router umstellen, und die FritzBoxen komplett ignorieren.

Das Problem mit dem WireGuard FritzBox zu FritzBox ist, wie Du schon erkannt hast, dass das Netz hinter Deinem "echter Router" nur mit Klimmzügen einzubinden ist.
 
Man KÖNNTE nun dies ganze mit viel hin und her lösen.. aber für solche Sachen kann man auch Tailscale nutzen =P

Mach dich da mal bitte schlau, damit bist du sogar noch flexibler wie als mit einem einfach Site2Site VPN und in der Basic Community Variante kostet es nichts =)

1783104958308.png
 

Letzte Anleitungen

Statistik des Forums

Themen
8.104
Beiträge
79.919
Mitglieder
8.828
Neuestes Mitglied
Pfeife
Zurück
Oben