Leserartikel Wireguard Heimnetzwerk Zugriff hinter CG-NAT o.Ä. ohne WG auf Router

Hallo zusammen,

da ich im Heimnetzwerk ein wenig umgebaut habe und einige Zeitfresser unterwegs aufkamen, dachte ich mir ich teile einmal meine Erfahrung mit der Community

Zielgruppe​

Die Zielgruppe sind Personen, welche hinter einem CG-NAT oder Ähnlichem sitzen und eine WireGuard-Verbindung ins Heimnetz über einen VPS herstellen möchten. Die Verbindung wird dabei nicht über den Router realisiert, sondern über ein anderes beliebiges Gerät (z.B. RapberryPi), welches sich im Subnet befindet. Es ist somit kein Router mit Wireguard-Funktionalität notwendig.

Was benötigt wird​

1. Der VPS natürlich. Ich habe den kleinsten IONOS Server für 1€/Monat dafür angemietet, welcher auf Ubuntu 24.04 läuft. Wichtig ist die öffentliche IPv4.
2. Ein Endgerät auf dem WireGuard läuft, welcher als Gateway in das interne Netz dient. Bei mir ist das eine Proxmox VM basierend auf debian12. Es ist aber auch ein RaspberryPi, BananaPi oder sonstiges Gerät möglich, auf dem Linux läuft (Toaster )
3. Grundlegendes Wissen über Konsole
4. Private und Public Keys für Wireguard, z.B. hier: https://www.wireguardconfig.com

Der Aufbau gestaltet sich wie folgt:​

Die blauen IP Adressen sind die WireGuard IPs, die grünen die internen Heimnetzwerk IPs und die schwarzen die normalen im Internet verfügbaren IPs.

Konfiguration des "Servers" / Host "S"​

Das ist unsere wichtigste Konfigdatei und diese muss den folgenden Aufbau haben:

[Interface]
Address = 10.0.0.1/24 ## Adresse eures Adapters im WG Netz
ListenPort = 45678 ## Hier kommt eure Portnummer rein, über die man sich verbinden kann
PrivateKey = ## Private Key vom Server

# IP forwarding
PreUp = sysctl -w net.ipv4.ip_forward=1
# IP masquerading
PreUp = iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x45
PreUp = iptables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x45 -j MASQUERADE
PostDown = iptables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x45
PostDown = iptables -t nat -D POSTROUTING ! -o wg0 -m mark --mark 0x45 -j MASQUERADE

# Gateway Peer, Host "H"
[Peer]
PublicKey = ## Public Key vom Host "H"
PresharedKey = ## Optional einen PSK für erhöhte Sicherheit hinzufügen
AllowedIPs = 10.0.0.2/32, 172.16.1.0/24 ## IP vom WG Adapter des Host "H" zzgl. zu benutzendem Subnet im Heimnetzwerk

# Peer von außen, Host "A"
[Peer]
PublicKey = ## Public Key vom Host "A"
PresharedKey = ## Optional einen PSK für erhöhte Sicherheit hinzufügen
AllowedIPs = 10.0.0.3/32 ## Hier wird NUR die IP des WG Adapter des Host "A" eingetragen

Zur Erklärung der IP Routing Regeln:
iptables -t mangle: Dies bedeutet, dass die Regel in der "mangle"-Tabelle angewendet wird. Die "mangle"-Tabelle wird benutzt, um spezielle Paketänderungen vorzunehmen.

-A PREROUTING: Die "PREROUTING"-Kette wird verwendet, um Pakete zu manipulieren, bevor eine Routing-Entscheidung getroffen wird.

-i wg0: Die Regel gilt nur für Pakete, die über das Interface "wg0" eintreffen, also über eure wg0.conf Datei konfiguriert wird.

-j MARK --set-mark 0x45: Dies bedeutet, dass alle Pakete, die diese Regel passieren, mit dem Wert "0x45" markiert werden. Da kann jeder beliebige Byte Wert stehen. Also von 0x00 bis 0xFF.

Damit hätten wir unseren "Server" fertig konfiguriert. Dies spielen wir jetzt in die wg0.conf ein und können den Adapter starten.

Konfiguration des Gateway Peers, Host "H"​

Die Konfiguration des Gateway Peers in unserem Heimnetzwerk muss folgendermaßen aussehen:

[Interface]
Address = 10.0.0.2/32 ## IP Adresse des WG Adapters
PrivateKey = ## Private Key vom Host "H"

# IP forwarding
PreUp = sysctl -w net.ipv4.ip_forward=1
# IP masquerading ## Der IP Marker muss hier der selbe sein wie oben festgelegt, damit das Routing funktioniert.
PreUp = iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x45
PreUp = iptables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x45 -j MASQUERADE
PostDown = iptables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x45
PostDown = iptables -t nat -D POSTROUTING ! -o wg0 -m mark --mark 0x45 -j MASQUERADE

[Peer]
PublicKey = ## Public Key vom Host "S"
PresharedKey = ## Optional einen PSK für erhöhte Sicherheit hinzufügen
AllowedIPs = 10.0.0.0/24 ## Hier ist nur das WG Subnet einzutragen
Endpoint = 12.23.12.12:45678 ## Öffentliche IP und Port eures VPS
PersistentKeepalive = 25 ## Damit die Verbindung am Leben gehalten wird

Damit haben wir schon das meiste abgeschlossen. Jetzt fehlt es nur noch daran, die Peers zu verbinden, welche auf das Heimnetzwerk Zugriff erhalten sollen.

Konfiguration eines Teilnehmers, Host "A"​

Hier kommt jetzt der Part, der beliebig vervielfältigt werden kann, man muss nur die Adapter IP + Keys anpassen und den Peer im Host "S" eintragen und dann hat man einen weiteren Teilnehmer hinzugefügt.

[Interface]
Address = 10.0.0.3/32 ## IP Adresse des WG Adapters
PrivateKey = ## Private Key vom Host "A"

[Peer]
PublicKey = ## Public Key vom Host "S"
PresharedKey = ## Optional einen PSK für erhöhte Sicherheit hinzufügen
AllowedIPs = 10.0.0.0/24, 172.16.1.0/24 ## Subnet vom WG Netz "H" zzgl. zu benutzendem Subnet im Heimnetzwerk
Endpoint = 12.23.12.12:45678 ## Öffentliche IP und Port eures VPS
PersistentKeepalive = 25 ## Damit die Verbindung am Leben gehalten wird

Nachdem man diese Konfiguration vom Host "A" auf seinen "Client" übertragen hat, und nun sich mit dem VPS verbindet, erlangt man Zugriff auf das Heimnetzwerk.
Ich habe bei meinem VPS z.B. nur einen einzigen Port offen und das ist der Wireguard Port. Sollte man per SSH auf den VPS drauf wollen, geht das getunnelt über Wireguard, ohne die Verbindung dem bösen Internet preiszugeben.

Ich weiß es ist eine kurze Anleitung und vielleicht baue ich diese in Zukunft noch ein wenig weiter aus, aber ich hoffe, dass ich damit trotzdem einigen helfen kann, die eben nicht auf der Fritz!Box oder anderen Routern Wireguard laufen lassen können oder wollen.

Gruß,
Xiao

Disclaimer: Es wird keine Garantie oder ähnliches für irgendwas übernommen. Es ist eine Anleitung im Internet von einem Foren-Dude, sollte wohl klar sein?

 

[s1ave77]

Konfiguration des "Serwers" / Host "S"

Kleiner Schönheitsfehler .

 

[Xiaolong]

War doch klar, man macht sich die Mühe der Community was mitzuteilen und das erste was kommt ist sie Rechtschreibpolizei 👍🏻🤣 /SCNR

 

[s1ave77]

Kam dann doch interessehalber vorbei - Thema taucht ja immer wieder auf. Der brannte halt direkt im Auge und hat meine Mustererkennung getriggert. Gerade Überschriften sind halt 'prominent'.

Glücklicherweise habe ich eine öffentliche IPv4 und Wireguard als Teil des Docker-Stacks.

 

[riversource]

Warum setzt du Masquerading Regeln ein? Das behindert ggf. gewisse Zugriffe und Protokolle. Ich hab ein nahezu identisches Setup, allerdings mit statischen Routen.

 

[Xiaolong]

Weil sich ein ganzes Subnetz (172.16.1.0/24) hinter der 10.0.0.2 versteckt.
Wo du jedoch recht hast, ich habe das jetzt ohne MASQUERADE nicht ausprobiert Welche Protokolle meinst du? Ich habe bis jetzt keine Einschränkungen festgestellt.

 

[riversource]

Weil sich ein ganzes Subnetz (172.16.1.0/24) hinter der 10.0.0.2 versteckt.

Genau dafür sind ja die statischen Routen. In Host S sorgt Wireguard ja schon selbst dafür durch die Allowed IPs. Fehlt nur eine Route im Netz von Host H für das Transportnetz.

Welche Protokolle meinst du

Alle, die bidirektional Ports öffnen oder Verbindungslos arbeiten. FTP, SIP, viele UDP Dienste, ...

 

[Raijin]

NAT hat in solchen Szenarien auch den faden Beigeschmack, dass das Zielsystem nicht zwischen Clients aus dem lokalen und dem remote Subnetz unterscheiden kann. Ggfs möchte man dies ja separat handhaben, aber bei NAT hätte man nur die Möglichkeit, das VPN-Gateway als solches komplett zu blocken - auch wenn das Gateway möglicherweise selbst der Client ist und gar kein Gerät hinter dem VPN.

Oder, anderer Fall, es gibt mehrere VPN-Endpunkte mit jeweils eigenen Subnetzen. Im Falle von NAT sähen auch diese alle, durch die Bank, aus wie das VPN-Gateway selbst.

In einem voll gerouteten Netzwerk hat man freie Hand. Natürlich kann man auch in der Firewall des Gateways blocken, aber vielleicht geht's auch gar nicht um's blocken, sondern um Clientstatistiken, o.ä. Zum Beispiel dann, wenn man daheim einen Filter-DNS nutzt, der auch per VPN genutzt werden soll, inkl. eindeutiger Clientzuordnung.

 

[Xiaolong]

@riversource und @Raijin

Also ich kann ohne Probleme auf meinen FTP drauf...
Andersherum gefragt: Wie würdet ihr das lösen? Dann pass ich oberen kleinen Artikel kurz an, um den Suchenden ein wenig besser zu helfen, was ich mache ist ja auch nicht der Weißheit letzter Schluss

 

[riversource]

Warum markierst du die VPN Pakete mit 0x45? Machst du im System noch was damit?

Ansonsten: Die iptables Regeln komplett raus aus der Wireguard Konfig (ist meines Erachtens eh der falsche Ort dafür, auch wenn man sie braucht). Dafür im Internet-Router auf der Seite des Hostes H eine statische Route auf 10.0.0.0/24 mit Gateway 192.168.1.20. Mehr ist nicht nötig. In Host S und im Client sorgt die Liste der Allowed IPs für die richtigen Routen.

 

[Raijin]

Also ich kann ohne Probleme auf meinen FTP drauf...

Passives FTP ja, aber aktives FTP nein.

FTP besteht aus 2 Verbindungen, der Control- und der Data-Verbindung. Im passiven Modus werden beide vom Client aus zum Server aufgebaut, im aktiven ist es jedoch der Server, der die Data-Verbindung zum Client aufbaut, also in die andere Richtung. Genau diese würde dann am NAT hängen bleiben. Das ist aber auch nur ein einzelnes Beispiel. Ein weiteres Beispiel für NAT-spezifische Probleme kennt man von Spielekonsolen wie PlayStation und Co. "Ich kann xy im Chat nicht hören, aber alle anderen schon" - wegen NAT-Problemen bei den Client<>Client Verbindungen im VoiceChat...

Wie gesagt, es gibt verschiedene Phänomene, wenn man NAT einfach nur verwendet, weil's vielleicht einfacher aussieht. NAT dient einem Zweck, der aber innerhalb des eigenen Netzwerks in den wenigsten Fällen gegeben ist. Selbst wenn man nicht in Verbindungsprobleme läuft, weil man ggfs gar kein aktives FTP, o.ä. nutzt, verliert man wie bereits erwähnt die Fähigkeit, Clients jenseits des NAT eindeutig zu identifizieren. Würdest du zB pihole, o.ä. betreiben, kämen sämtliche Anfragen aus dem VPN augenscheinlich vom VPN-Gateway, hinter dem sich womöglich Dutzende von Clients verstecken könnten.

Wie würdet ihr das lösen?

Mit vollständigem Routing. Wenn jede Seite weiß welches Subnetz auf der anderen Seite liegt, kann sie auch dahin routen, ohne NAT.

Ein Client im Netzwerk hat in der Regel nur eine relevante Route, die Standardroute 0.0.0.0/0 zum Standardgateway = Router. Dorthin schickt der Client also alles, was als Ziel außerhalb des lokalen Subnetzes liegt.

Wenn der Router selbst das VPN-Gateway ist, regelt dessen VPN-Konfiguration bereits die Route ins gegenüberliegende Subnetz - dafür ist zB bei WireGuard Allowed IPs verantwortlich. Die Clients schicken also alle Pakete zu externen Zielen an den Router und dieser entscheidet dann anhand der Ziel-IP ob er die Pakete direkt ins www leitet oder in den VPN-Tunnel.

Ist das VPN-Gateway nicht der Router, sondern ein eigenständiges Gerät im Netzwerk (zB ein Raspberry PI, o.ä. wie du es ja auch beschreibst), muss man im Router von Hand eine Route anlegen, die ins gegenüberliegende Subnetz zeigt und das lokale VPN-Gateway als Ziel hat. Die Clients würden Pakete an externe Ziele nach wie vor an den Router schicken und dieser entscheidet nun erneut ob das Ziel direkt im www liegt oder ob er das Paket an das VPN-Gateway durchreichen soll.
Voraussetzung hierfür ist allerdings, dass der Router die Möglichkeit der Eingabe von statischen Routen bietet. Das tun leider nicht alle.


Der Routing-Ansatz mag komplizierter klingen als NAT, aber er ist konsistent und man behält sich alle Möglichkeiten offen. NAT ist maximal der Weg des geringsten Widerstands, schränkt aber auch entsprechend ein.

P.S.: Trotzdem natürlich Daumen hoch dafür, dass du so eine Anleitung schreiben möchtest. Versteh die Kritik also bitte nicht als Dämpfer, sondern als Verbesserungsansätze.

 

[Nultsch]

Super Anleitung - kann ich mit dem Setup auch einen bestimmten TCP Port zu einem Gerät im Heimnetz weiterleiten bzw. dafür freigeben?

 

[riversource]

Klar, kann man. Die Frage ist, wofür? Die Idee ist ja, sich per VPN auf den VPS zu verbinden, und dann aufs Heimnetz zuzugreifen. Aber klar kann man auf dem VPS eine Portweiterleitung einrichten. Eine entsprechende iptables Regel könnte ich dir zusammenbauen, falls wirklich noch Interesse besteht.