Wireguard - Routing ins "Client"-Netzwerk
Hallo in die Runde,
mal wieder ne Wireguard-Frage. Ich quäle mich schon einige Tage damit und vielleicht habt Ihr ne Idee wie ich das folgende konfiguriere:
Strato-Windows-"VPN-Server" mit WG-SW
auf der anderen Seite
Fritzbox als DHCP mit Wireguard/PiHole-Raspi (pivpn.io)
Wunsch: Zugriff vom Strato-Server auf die Geräte im Client-Netzwerk (NetzwerkDrucker)
Die Verbindung zu erstellen ist erstmal kein Thema. Ebenso, habe ich so ein Setup laufen, wenn der Raspi der "VPN-Server" ist - dann klappt der Zugriff auf die dann "serverseitigen" Drucker.
Das erfolgt dann ja über die folgenden 2 Zeilen:
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
Nur wollte ich in der "Version 2.0" explizit den Windows-Strato als VPN-Server (auch für die anderen Clients) nutzen - alleine schon wegen der dortigen Bandbreite. Die iptables-Befehle klappten da natürlich nicht und wären da ja auch auf der "falschen" Seite, weil die Drucker sozusagem am VPN-Client hängen. Den Code beim Client reinzuhängen klappt aber auch nicht. Selbst alle Firewalls zu deaktivieren klappt auch nicht und irgendwie gehen mir langsam die Ideen aus und ich verbastle das Setup immer mehr.
Hat das schon jemand mal probiert oder ne Anleitung gesehen dazu?! Wenn ich das richtig verstehe ein Site2Point-Aufbau?!
mal wieder ne Wireguard-Frage. Ich quäle mich schon einige Tage damit und vielleicht habt Ihr ne Idee wie ich das folgende konfiguriere:
Strato-Windows-"VPN-Server" mit WG-SW
auf der anderen Seite
Fritzbox als DHCP mit Wireguard/PiHole-Raspi (pivpn.io)
Wunsch: Zugriff vom Strato-Server auf die Geräte im Client-Netzwerk (NetzwerkDrucker)
Die Verbindung zu erstellen ist erstmal kein Thema. Ebenso, habe ich so ein Setup laufen, wenn der Raspi der "VPN-Server" ist - dann klappt der Zugriff auf die dann "serverseitigen" Drucker.
Das erfolgt dann ja über die folgenden 2 Zeilen:
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
Nur wollte ich in der "Version 2.0" explizit den Windows-Strato als VPN-Server (auch für die anderen Clients) nutzen - alleine schon wegen der dortigen Bandbreite. Die iptables-Befehle klappten da natürlich nicht und wären da ja auch auf der "falschen" Seite, weil die Drucker sozusagem am VPN-Client hängen. Den Code beim Client reinzuhängen klappt aber auch nicht. Selbst alle Firewalls zu deaktivieren klappt auch nicht und irgendwie gehen mir langsam die Ideen aus und ich verbastle das Setup immer mehr.
Hat das schon jemand mal probiert oder ne Anleitung gesehen dazu?! Wenn ich das richtig verstehe ein Site2Point-Aufbau?!
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 592049
Url: https://administrator.de/forum/wireguard-routing-ins-client-netzwerk-592049.html
Ausgedruckt am: 25.04.2025 um 02:04 Uhr
2 Kommentare
Neuester Kommentar
Mach aus deinem Raspi einfach einen Site-Knoten. Also der Raspi muss Forwarding aktiviert haben, dann muss auf beiden Seiten jeweils in der AllowedIPs der Range des jeweiligen Remote-Netzes hinzugefügt werden. Wenn du auf dem Raspi den eingehenden Traffic ins lokale LAN nicht NATen willst noch eine static Route für das Remote-Netz auf dem Default-GW das auf den Raspi als Gateway zeigt. Fertsch.
Beide Rechner vServer UND RasPi müssen IPv4 Forwarding aktiv haben sonst wird das nix. Klar, denn sonst könnte der Kernel nicht routen bei einer Site-2-Site Kopplung.
Wenn beide Seiten die jeweils remoten IP Netze in ihrer Routing Tabelle ip route show (netstat -r -n) haben sollte auch das Routing fehlerfrei klappen.
Im Grunde sind es routingtechnisch die gleichen DoTos wie bei OpenVPN:
OpenVPN - Erreiche Netzwerk hinter Client nicht
und im Detail
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Nach deinen iptables Kommandos zu urteilen ist wohl den Kardinalsfehler das du im Tunnel selber NAT machst. Sowas ist nicht nur völlig überflüssig und frisst Performance, es gibt zusätzlich Probleme mit der NAT Firewall da damit ein transparentes Routing zwischen beiden IP Netzen nicht mehr möglich ist. Vermutlich genau dein Problem und deshalb predigen wir hier zu Recht immer das NAT im Tunnel Unsinn ist.
Wenn beide Seiten die jeweils remoten IP Netze in ihrer Routing Tabelle ip route show (netstat -r -n) haben sollte auch das Routing fehlerfrei klappen.
Im Grunde sind es routingtechnisch die gleichen DoTos wie bei OpenVPN:
OpenVPN - Erreiche Netzwerk hinter Client nicht
und im Detail
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Nach deinen iptables Kommandos zu urteilen ist wohl den Kardinalsfehler das du im Tunnel selber NAT machst. Sowas ist nicht nur völlig überflüssig und frisst Performance, es gibt zusätzlich Probleme mit der NAT Firewall da damit ein transparentes Routing zwischen beiden IP Netzen nicht mehr möglich ist. Vermutlich genau dein Problem und deshalb predigen wir hier zu Recht immer das NAT im Tunnel Unsinn ist.
