4
Iptables: VPN (WireGuard) + NAT und Masquerading
Hallo zusammen,
folgende Ausgangslage:
Ich habe einen vServer, der als WireGuard-Server fungiert. Es verbinden sich mehrere Clients mit verschiedenen IP-Ranges (z. B. 192.168.33.0/24 oder 192.168.4.0/24) dorthin, die sich alle gegenseitig erreichen sollen und das auch tun. Zusätzlich sind auf dem vServer einige Portweiterleitungen eingerichtet, sodass einzelne Ziele in diesen IP-Ranges über die jeweilige VPN-Verbindung öffentlich über die IP-Adresse des vServers erreichbar sind. Auch das funktioniert wunderbar.
iptables sieht so aus:
Das Interface ins Internet ist ens6, WireGuard ist wg0.
Wie gesagt, alles, was ich tun möchte, funktioniert einwandfrei. Mein Anliegen ist jetzt mehr eine Schönheitskorrektur, da im Moment ja alles, was über den vServer läuft, einem Masquerading unterzogen wird. Für die Portfreigaben muss das sein, behaupte ich mal ganz naiv, da sonst die Antwort aus der privaten IP-Range ja nicht korrekt geroutet wird. Sobald ich das Masquerading rausnehme, funktionieren die Portfreigaben auch nicht mehr. Aber: Es werden auch sämtliche WireGuard-internen Verbindungen diesem Masquerading unterzogen. Wenn ich also z. B. von 192.168.4.25 auf 192.168.33.1 zugreife, ist es immer die WireGuard-IP-Adresse des vServers, welche als Quell-IP dort erscheint und nicht 192.168.4.25.
Das ist funktional kein Problem, aber ich hätte das eben lieber so, dass ich sehen kann, von welcher Quell-IP Anfragen innerhalb der WireGuard-Verbindungen kommen. Soll heißen: WireGuard-intern (von wg0 nach wg0) soll kein Masquerading stattfinden und/oder das Masquerarding soll nur für die Portweiterleitungen stattfinden (von ens6 nach wg0 und andersherum).
Nun habe ich schon versucht, mir das zu ergooglen, aber alle bisherigen Möglichkeiten mit Ein- oder Ausschluss von Interfaces, Ein- oder Ausschluss von IP-Ranges etc. hat immer nur dazu geführt, dass (anscheinend) gar kein Masquerading mehr stattgefunden hat und somit die Portfreigaben nicht mehr funktioniert haben.
Kann mir jemand einen Tipp geben, wie ich vorgehen muss?
folgende Ausgangslage:
Ich habe einen vServer, der als WireGuard-Server fungiert. Es verbinden sich mehrere Clients mit verschiedenen IP-Ranges (z. B. 192.168.33.0/24 oder 192.168.4.0/24) dorthin, die sich alle gegenseitig erreichen sollen und das auch tun. Zusätzlich sind auf dem vServer einige Portweiterleitungen eingerichtet, sodass einzelne Ziele in diesen IP-Ranges über die jeweilige VPN-Verbindung öffentlich über die IP-Adresse des vServers erreichbar sind. Auch das funktioniert wunderbar.
iptables sieht so aus:
*nat
-A PREROUTING -p tcp -m tcp --dport 8081 -j DNAT --to-destination 192.168.33.152:8089
-A PREROUTING -p tcp -m tcp --dport 8082 -j DNAT --to-destination 192.168.33.88:22
(und weitere Portweiterleitungen)
-A POSTROUTING -j MASQUERADE
COMMITDas Interface ins Internet ist ens6, WireGuard ist wg0.
Wie gesagt, alles, was ich tun möchte, funktioniert einwandfrei. Mein Anliegen ist jetzt mehr eine Schönheitskorrektur, da im Moment ja alles, was über den vServer läuft, einem Masquerading unterzogen wird. Für die Portfreigaben muss das sein, behaupte ich mal ganz naiv, da sonst die Antwort aus der privaten IP-Range ja nicht korrekt geroutet wird. Sobald ich das Masquerading rausnehme, funktionieren die Portfreigaben auch nicht mehr. Aber: Es werden auch sämtliche WireGuard-internen Verbindungen diesem Masquerading unterzogen. Wenn ich also z. B. von 192.168.4.25 auf 192.168.33.1 zugreife, ist es immer die WireGuard-IP-Adresse des vServers, welche als Quell-IP dort erscheint und nicht 192.168.4.25.
Das ist funktional kein Problem, aber ich hätte das eben lieber so, dass ich sehen kann, von welcher Quell-IP Anfragen innerhalb der WireGuard-Verbindungen kommen. Soll heißen: WireGuard-intern (von wg0 nach wg0) soll kein Masquerading stattfinden und/oder das Masquerarding soll nur für die Portweiterleitungen stattfinden (von ens6 nach wg0 und andersherum).
Nun habe ich schon versucht, mir das zu ergooglen, aber alle bisherigen Möglichkeiten mit Ein- oder Ausschluss von Interfaces, Ein- oder Ausschluss von IP-Ranges etc. hat immer nur dazu geführt, dass (anscheinend) gar kein Masquerading mehr stattgefunden hat und somit die Portfreigaben nicht mehr funktioniert haben.
Kann mir jemand einen Tipp geben, wie ich vorgehen muss?
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: 672177
Url: https://administrator.de/forum/iptables-vpn-wireguard-nat-und-masquerading-672177.html
Ausgedruckt am: 29.03.2025 um 23:03 Uhr
4 Kommentare
Neuester Kommentar
Es werden auch sämtliche WireGuard-internen Verbindungen diesem Masquerading unterzogen
Was natürlich wenig sinnvoll ist. Tutorial zu der Thematik lesen hilft ggf.:Merkzettel: VPN Installation mit Wireguard
Da in fast allen Debian basierten Distros seit längerem die moderneren nftables verwendet werden ist es auch sinnvoller diese für die Firewall zu verwenden. Ein paar Ansätze dazu findest du auch HIER und in den weiterführenden Links dort.
Für die Portfreigaben muss das sein, behaupte ich mal ganz naiv, da sonst die Antwort aus der privaten IP-Range ja nicht korrekt geroutet wird
Doch geht auch alles ohne NAT, man muss nur beim WG-Empfänger die Pakete markieren so dass sie wieder über den Tunnel zurück ins Internet laufen statt über den Default-Zugang, dann gehen selbst die Verbindungen der Portforwardings ohne NAT über den TunnelGuckst du hier :
- Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
- Routing zwischen zwei PfSense - Nutzung von public IP
Wenn das Markieren der Pakete nicht in deinem Einflussbereich liegt dann schränke stattdessen das NAT auf die Portforwardings ein.
-A POSTROUTING ! -s 192.168.0.0/16 -o wg0 -j MASQUERADE
-A POSTROUTING -o ens6 -j MASQUERADEWürde aber wie schon gesagt wurde auch zu nftables raten, Prinzip bleibt ja immer ähnlich.
1
Danke für eure Tipps!
ist tatsächlich die Lösung. Problem nur: Man kann ja anscheinend keine zweite solche Regel/Range anwenden. Ich bräuchte aber auch noch 10.0.0.0/8 und habe es nicht geschafft, das zusätzlich noch hinzubekommen.
Aber: Ich habe jetzt ein Tool gefunden, sodass ich die Portweiterleitungen gar nicht über iptables machen muss:
https://wiki.ubuntuusers.de/rinetd/
iptables ist jetzt also komplett leer und es gibt kein Masquerading. Das für die Portweiterleitungen notwendige Masquerading erledigt rinetd intern. So ist das wunderbar.
-A POSTROUTING ! -s 192.168.0.0/16 -o wg0 -j MASQUERADE
-A POSTROUTING -o ens6 -j MASQUERADEist tatsächlich die Lösung. Problem nur: Man kann ja anscheinend keine zweite solche Regel/Range anwenden. Ich bräuchte aber auch noch 10.0.0.0/8 und habe es nicht geschafft, das zusätzlich noch hinzubekommen.
Aber: Ich habe jetzt ein Tool gefunden, sodass ich die Portweiterleitungen gar nicht über iptables machen muss:
https://wiki.ubuntuusers.de/rinetd/
iptables ist jetzt also komplett leer und es gibt kein Masquerading. Das für die Portweiterleitungen notwendige Masquerading erledigt rinetd intern. So ist das wunderbar.
Zitat von @DigiAndi:
Danke für eure Tipps!
ist tatsächlich die Lösung. Problem nur: Man kann ja anscheinend keine zweite solche Regel/Range anwenden. Ich bräuchte aber auch noch 10.0.0.0/8 und habe es nicht geschafft, das zusätzlich noch hinzubekommen.
Du kannst entweder mit IPSET eine Liste mit den Subnets anlegen und in der Regel angeben, oder alternativ Regeln vor dem Masquerade mit -j ACCEPT anlegen.Danke für eure Tipps!
-A POSTROUTING ! -s 192.168.0.0/16 -o wg0 -j MASQUERADE
-A POSTROUTING -o ens6 -j MASQUERADEist tatsächlich die Lösung. Problem nur: Man kann ja anscheinend keine zweite solche Regel/Range anwenden. Ich bräuchte aber auch noch 10.0.0.0/8 und habe es nicht geschafft, das zusätzlich noch hinzubekommen.
-A POSTROUTING -s 192.168.0.0/16 -o wg0 -j ACCEPT
-A POSTROUTING -s 10.0.0.0/8 -o wg0 -j ACCEPT
-A POSTROUTING -o wg0 -j MASQUERADE
-A POSTROUTING -o ens6 -j MASQUERADE
