Routing Wireguard
Hallo und einen schönen Sonntag euch.
Seit längerem Versuche ich mein DSLite Problem mit einem VPS und wireguard zu lösen.
Ich habe es bis her soweit geschafft das sich meine Fritzbox als Client mit dem VPS verbindet und ich vom heimischen LAN auf Dienste des VPS zugreifen kann.
Das gleiche klappt auch vom Mobildevice aus über Mobilfunk und auch aus fremden WLANs heraus
Was nicht klappt, vom Mobildevice über VPS ins Heimische LAN
Aktuell geht auch der komplette Traffic über das VPN. Das wäre aber nicht sinnvoll aus dem Heimischen LAN aber erstmal nicht Das vorrangige Problem.
Ich vermute das ich hier im Routing nachbessern muss und oder in der WG config
Aber hier stehe ich gerade vor einer Wand. Ich habe das Szenario mal aufgemalt und hoffe ihr könnt mir tips geben. Danke schon mal.
Seit längerem Versuche ich mein DSLite Problem mit einem VPS und wireguard zu lösen.
Ich habe es bis her soweit geschafft das sich meine Fritzbox als Client mit dem VPS verbindet und ich vom heimischen LAN auf Dienste des VPS zugreifen kann.
Das gleiche klappt auch vom Mobildevice aus über Mobilfunk und auch aus fremden WLANs heraus
Was nicht klappt, vom Mobildevice über VPS ins Heimische LAN
Aktuell geht auch der komplette Traffic über das VPN. Das wäre aber nicht sinnvoll aus dem Heimischen LAN aber erstmal nicht Das vorrangige Problem.
Ich vermute das ich hier im Routing nachbessern muss und oder in der WG config
Aber hier stehe ich gerade vor einer Wand. Ich habe das Szenario mal aufgemalt und hoffe ihr könnt mir tips geben. Danke schon mal.
wg0.conf
[Interface]
Address = 192.168.9.1/24,fd42:42:42::1/64
ListenPort = wireguardport
PrivateKey = DER Key
PostUp = iptables -I INPUT -p udp --dport PORT -j ACCEPT
PostUp = iptables -I FORWARD -i ens192 -o wg0 -j ACCEPT
PostUp = iptables -I FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE
PostUp = ip6tables -I FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o ens192 -j MASQUERADE
PostDown = iptables -D INPUT -p udp --dport PORT -j ACCEPT
PostDown = iptables -D FORWARD -i ens192 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o ens192 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o ens192 -j MASQUERADE
### Client 1
[Peer]
PublicKey =
PresharedKey =
AllowedIPs = 192.168.9.3/32,fd42:42:42::3/128
### Client 2
[Peer]
PublicKey =
PresharedKey =
AllowedIPs = 192.168.9.4/32,fd42:42:42::4/128
### Client 3
[Peer]
PublicKey =
PresharedKey =/=
AllowedIPs = 192.168.9.2/32,fd42:42:42::2/128
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7567079219
Url: https://administrator.de/contentid/7567079219
Ausgedruckt am: 22.11.2024 um 20:11 Uhr
8 Kommentare
Neuester Kommentar
Ebenso einen schönen Sonntag!
Nein, dein Routing ist soweit OK. Das Cryptokey Routing bei Wireguard macht beim VPS so oder so weitgehend alles automatisch. Auffällig sind 2 Punkte:
Das Fehlverhalten bedingt sehr wahrscheinlich ein fehlendes NAT/Masquerading im Tunnel am VPS.
VPN Clients die dort über den VPS reinkommen ohne NAT am Tunnelport werden am Ziel, sprich deiner heimischen FritzBox, mit ihrer öffentlichen IP lokal durch die dortige FB lokale ins Internet geroutet ohne zurück über den Tunnel zum VPS zu gehen.
Das hat dann zur Folge das der Rückrouten Traffic aus dem FB LAN mit einer anderen Absender IP am Client ankommt, was dann am VPN Client zum sofortigen Session Abbruch führt.
Hier findest du 2 Forenthreads die diese Problematik näher beschreiben:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP
NAT/Masquerading solltest du am VPS auch besser nicht in der WG Konfig machen sondern separat in der Firewall.
Mit anderen Worten musst du den Traffic zur heimischen FB am VPS Tunnelinterface NAT/Masqueraden. Nur so "sieht" die FB dann Tunneltraffic vom VPS und routet den Rückrouten Traffic auch wieder in den Tunnel zurück zum VPS statt lokal.
Tip:
Wenn du übrigens IKEv2 am VPS verwendest, kannst du dir die Frickelei mit zusätzlichen VPN Clients sparen und immer die onboard VPN Clients verwenden. Siehe dazu HIER.
Das Tutorial beschreibt auch gleich die Jumphost Konfig der FritzBox und das NAT aber mit den moderneren nftables statt dem Auslaufmodell iptables.
Auch eine gemischte VPN Infrastruktur kann man so realisieren. Client VPN Dialin mit IKEv2 und die Fritzbox Jumphost Kopplung mit Wireguard wenn man hier kein IPsec will. Den Jumphost in einem IKEv2 Umfeld auch mit IPsec anzubinden ist dann aber in dem Falle auch die Clients mit IPsec zu bedienen die sinnvollere Lösung.
Wie dort z.B. eine nftables Firewall Konfig aussehen kann zeigt dieser Thread.
Das Masquerading im Tunnel müsste man noch mit...
...ans Ende anhängen.
(172.25.25.0/24 ist hier das IKEv2 Client VPN Dialin IP Netz am VPS)
Wireguard mit der Fritzbox ist wegen der nicht Standard konformen AVM Implementation etwas tricky. Wenn man von oder auf die Fritzbox von oder auf klassische Wireguard Infrastruktur terminiert muss man einige Fallen beachten die dieses Tutorial im Detail beschreibt!
Nein, dein Routing ist soweit OK. Das Cryptokey Routing bei Wireguard macht beim VPS so oder so weitgehend alles automatisch. Auffällig sind 2 Punkte:
- Ein preshared Key ist mehr oder minder überflüssiger Overhead den du dir ersparen kannst (und solltest) für eine schlankere Konfig. (Siehe dazu HIER)
- Außerdem ist zumindest eine der Client Konfigs fehlerhaft nämlich die die den Fritzbox WG Tunnel bestimmt. Dort fehlt unter den "AllowedIPs" das lokale LAN der FritzBox! (Siehe dazu auch hier) Ansonsten routet der WG VPS den Fritzbox LAN Traffic nicht in den Tunnel!
Das Fehlverhalten bedingt sehr wahrscheinlich ein fehlendes NAT/Masquerading im Tunnel am VPS.
VPN Clients die dort über den VPS reinkommen ohne NAT am Tunnelport werden am Ziel, sprich deiner heimischen FritzBox, mit ihrer öffentlichen IP lokal durch die dortige FB lokale ins Internet geroutet ohne zurück über den Tunnel zum VPS zu gehen.
Das hat dann zur Folge das der Rückrouten Traffic aus dem FB LAN mit einer anderen Absender IP am Client ankommt, was dann am VPN Client zum sofortigen Session Abbruch führt.
Hier findest du 2 Forenthreads die diese Problematik näher beschreiben:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP
NAT/Masquerading solltest du am VPS auch besser nicht in der WG Konfig machen sondern separat in der Firewall.
Mit anderen Worten musst du den Traffic zur heimischen FB am VPS Tunnelinterface NAT/Masqueraden. Nur so "sieht" die FB dann Tunneltraffic vom VPS und routet den Rückrouten Traffic auch wieder in den Tunnel zurück zum VPS statt lokal.
Tip:
Wenn du übrigens IKEv2 am VPS verwendest, kannst du dir die Frickelei mit zusätzlichen VPN Clients sparen und immer die onboard VPN Clients verwenden. Siehe dazu HIER.
Das Tutorial beschreibt auch gleich die Jumphost Konfig der FritzBox und das NAT aber mit den moderneren nftables statt dem Auslaufmodell iptables.
Auch eine gemischte VPN Infrastruktur kann man so realisieren. Client VPN Dialin mit IKEv2 und die Fritzbox Jumphost Kopplung mit Wireguard wenn man hier kein IPsec will. Den Jumphost in einem IKEv2 Umfeld auch mit IPsec anzubinden ist dann aber in dem Falle auch die Clients mit IPsec zu bedienen die sinnvollere Lösung.
Wie dort z.B. eine nftables Firewall Konfig aussehen kann zeigt dieser Thread.
Das Masquerading im Tunnel müsste man noch mit...
table ip nat {
define VPN_NETS = {
192.168.178.0/24
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oifname $pub_iface ip daddr $VPN_NETS accept
ip saddr 172.25.25.0/24 oifname $pub_iface masquerade
}
}
(172.25.25.0/24 ist hier das IKEv2 Client VPN Dialin IP Netz am VPS)
Wireguard mit der Fritzbox ist wegen der nicht Standard konformen AVM Implementation etwas tricky. Wenn man von oder auf die Fritzbox von oder auf klassische Wireguard Infrastruktur terminiert muss man einige Fallen beachten die dieses Tutorial im Detail beschreibt!
Wenn es das denn nun war bitte deinen Thread auch als erledigt schliessen!
Aber wenn das VPN richtig funktioniert brauche ich ja eigentlich keine Ports weiterleiten
Das ist absolut richtig! 👍Ein VPN ermöglich immer den geschützten Zugriff auf das heimische Netz.
Portforwarding hingegen ist immer unsicher und mit dem Loch in der Router Firewall lässt man immer ungeschützt Internet Traffic in sein lokales LAN was generell nicht ratsam ist.
Also gelöst ist hier noch garnichts. Ich würde sagen die Probleme fangen erst noch an
Na dann freuen wir uns auf kommende Herausforderungen! 😉
Deine Vorstellungen sind OK. Das ist ein simples, klassisches Jumphost Szenario.
Zusätzlich zu dem was da beschrieben ist konfigurierst du noch einen einfachen Wireguard Zugang und dann hast du einen universellen VPN Server der parallel beide klassischen VPN Protokolle je nach Geschmack supportet.
Ersterer hat den grossen Vorteil das du das auf jedem beliebigen Endgerät mit den bordeigenen VPN Clients nutzen kannst ohne mit externer VPN Clientsoftware rumfrickeln zu müssen. ;–)
Und zwar so das ich dann über einen externen Clienten auf den VPS Zugreifen kann und dann quasi zu Hause im eigenen Netz bin mit zugriff auf meine VLANS
Ist doch hier alles schon in einem Tutorial beschrieben! Einfach mal die Suchfunktion benutzen. ;–)Zusätzlich zu dem was da beschrieben ist konfigurierst du noch einen einfachen Wireguard Zugang und dann hast du einen universellen VPN Server der parallel beide klassischen VPN Protokolle je nach Geschmack supportet.
Ersterer hat den grossen Vorteil das du das auf jedem beliebigen Endgerät mit den bordeigenen VPN Clients nutzen kannst ohne mit externer VPN Clientsoftware rumfrickeln zu müssen. ;–)