schossel
Apr 26, 2023
view2483
view10
0
Goto Top

VPS Wireguard port forward - externe IP anzeigen

GermansolvedQuestionServerVPNRouters, RoutingLinux
Hallo,

Ich habe mir die letzten Tage eine Weiterleitung von einem VPS per Wireguard zu meiner Opnsense konfiguriert, da ich zu Hause keine öffentliche IPv4 habe.
Die Opnsense leitet Port 80 und 443 nochmal auf einen Reverse Proxy weiter, sowie 25,465,587,993 auf einen lokalen Mailserver. Auch können lokale Clients, welche per Alias in einer Gruppe auf der Opnsense sind, den VPS ausgehend nutzen.
Das funktioniert prinzipiell auch alles, ich kann alle Dienste erreichen, die Zertifikate sind da und der Mailserver geht über die VPS IP nach aussen.
Das einzige Problem, das ich zur Zeit habe, ich bekomme intern nicht die eigentliche IP des Client angezeigt, sondern die interne Wireguard Tunnel IP des VPS.

Konfiguration:

VPS
externe IP: 201.63.198.77
interne Wireguard IP: 10.200.200.10

Opnsense:
interne Wireguard IP: 10.200.200.5
WG Gateway: 10.200.200.4
Reverse Proxy: 10.20.40.20
Mailserver: 10.20.40.40

Komme ich jetzt von aussen mit der IP 6.3.7.2 auf den VPS leitet dieser weiter und es funktioniert auch, allerdings bekomme ich als zugreifende IP 10.200.200.10 angezeigt. Dieses "Problem" rührt meiner Meinung nach vom SNAT auf dem VPS.
Die iptables dort sehen so aus:
# By default drop traffic
sudo iptables -P FORWARD DROP

sudo iptables -P FORWARD DROP
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT

sudo iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o eth0 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Forward traffic back to eth0 from wg0 on specified ports
sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 80 -d 10.200.200.5 -j SNAT --to-source 10.200.200.10
sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 443 -d 10.200.200.5 -j SNAT --to-source 10.200.200.10

# For Mailserver
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 25 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 465 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 587 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 143 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 993 -m conntrack --ctstate NEW -j ACCEPT

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 465 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 587 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 143 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 993 -j DNAT --to-destination 10.200.200.5

sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 25 -d 10.200.200.5 -j SNAT --to-source 10.200.200.10
sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 465 -d 10.200.200.5 -j SNAT --to-source 10.200.200.10
sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 587 -d 10.200.200.5 -j SNAT --to-source 10.200.200.10
sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 143 -d 10.200.200.5 -j SNAT --to-source 10.200.200.10
sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 993 -d 10.200.200.5 -j SNAT --to-source 10.200.200.10

Das SNAT gibt, meiner Meinung nach, den Paketen praktisch die Rückroute mit und verändert die originale externe IP zu der 10.200.200.10 welche ich dann lokal sehe, damit der Client weis, wohin das Paket zurück muss. Richtig?
Ich würde mir allerdings wünschen, dass ich auf den lokalen Client die richtige IP sehen könnte um fail2ban etc zu machen.
Entferne ich die SNAT Sachen, komme ich natürlich nicht mehr irgendwo drauf, weder den Proxy, noch den Mailserver.
Ich stehe im Moment etwas auf dem Schlauch und probiere schon eine ganze Zeit, aber es klappt nicht. Ich denke machbar ist es, ich weiss nur nicht 100 Prozent wie.
Hat irgendjemand eine Idee?
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 6926140553

Url: https://administrator.de/contentid/6926140553

Printed on: May 7, 2024 at 03:05 o'clock

10 Comments
Latest comment
Goto Top
Member: aqui
Solution aqui Apr 26, 2023 updated at 17:21:10 (UTC)
Goto Top
damit der Client weis, wohin das Paket zurück muss. Richtig?
Das ist richtig!
SNAT im VPS ist zwingend, ansonsten würde dein lokaler Router die Antwortpakete direkt ins Internet routen die dann mit einen anderen IP am Ausgangspunkt ankommen und ein Client dort sofort die Session beendet.
SNAT sorgt also immer dafür das Rücktraffic auch wieder über den Tunnel zurückgeht, ansonsten würde so ein Konzept nicht funktionieren.
Diese Thematik ist auch in den folgenden Threads umfassend beschrieben:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP
Bzw. HIER siehst du genau so ein Design an einem IPsec Beispiel mit den moderneren nftables. (Kapitel: "Port Forwarding mit nftables Firewall absichern" und dort das "table ip nat" Statement.
dass ich auf den lokalen Client die richtige IP sehen könnte
Das geht nicht, weil dann dein lokaler Router diesen Rücktraffic eben direkt routet. Siehe oben...
heart1
Member: Spirit-of-Eli
Solution Spirit-of-Eli Apr 26, 2023, updated at Apr 27, 2023 at 04:56:24 (UTC)
Goto Top
Moin,

die beste Variante ist mMn. die in meinem Thread beschriebene. Du taggest den Traffic, welcher vom VPS kommt. Dann weiß die Sense wohin die Antwort Pakete müssen.

Funktioniert hier jedenfalls super.

Routing zwischen zwei PfSense - Nutzung von public IP

Gruß
Spirit
Member: schossel
schossel Apr 26, 2023 at 18:03:38 (UTC)
Goto Top
Kannst du das kurz erläutern? Welcher Thread?
Member: michi1983
michi1983 Apr 26, 2023 at 18:13:15 (UTC)
Goto Top
Zitat von @schossel:

Kannst du das kurz erläutern? Welcher Thread?

Zweiter Link in @aqui‘s Antwort.
heart1
Member: schossel
schossel Apr 26, 2023 updated at 21:30:54 (UTC)
Goto Top
Sorry, ich probiere hier schon den ganzen Tag, ich war leicht verwirrt.

Ich habe mir das jetzt mal durchgelesen und so verstanden, dass ich das SNAT weglassen kann, indem ich eingehende Pakete auf meinem WGVPS Interface tagge und dann als policy festlege, wenns getagged ist -> WGVPS gateway!?

Das hier wäre bei mir dann eingehend:
Bild gelöscht, war eh falsch

Das Proxmox Netz mit dem Reverse Prox ist bei mir ein VLAN, dann habe ich gedacht ausgehend wäre dann
Bild gelöscht, war eh falsch

Ich bekomme aber so keine Verbindung und auch die LiveView zeigt mir die getaggte Regel ausgehend nicht an.
Bild gelöscht, war eh falsch

Irgendwo habe ich einen Denkfehler oder was vergessen!?
Member: Spirit-of-Eli
Spirit-of-Eli Apr 26, 2023 at 20:18:28 (UTC)
Goto Top
Ich antworte dir morgen genauer.

Lass mal den Policy GW Einträge an der ausgehenden Rule weg. Das passiert automatisch für den Rückweg durch den tagg.

Wäre zumindest das, was mir gerade auffällt. Ich schau morgen noch mal bei mir.
Member: schossel
schossel Apr 26, 2023 updated at 21:32:06 (UTC)
Goto Top
Oooooooookkkkkkkk,
2 Sachen, erstens bin ich ein bisschen dumm und zweitens wurde da bei der Opnsense scheinbar was geändert.

Dumm bin ich weil ich bei dem ganzen klicken vorne auf den Pfeil gekommen bin
2023-04-26 23_03_18-proxmox _ rules _ firewall
Wenn die Regel ausgeschaltet ist, kommt auch nix im Log...

Als dann aus dem Proxmox Netz nichts mehr raus ging, habe ich mir das mal noch genauer angeschaut und den Fehler mit der Regel gefunden, dann habe ich mir gedacht, ok, vielleicht einfach nochmal machen und dabei ist mir das hier aufgefallen
2023-04-26 23_06_35-proxmox _ rules _ firewall
Ich hatte vorher dort den Gateway geändert, das hatte aber keine Wirkung. Dann ist mir das reply-to Feld aufgefallen und ich habe dort den Gateway ausgewählt und was soll ich sagen.
2023-04-26 23_13_09-live view _ log files _ firewall
Dann habe ich die iptables auf
# By default drop traffic
sudo iptables -P FORWARD DROP

sudo iptables -P FORWARD DROP
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT

sudo iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o eth0 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# For Mailserver
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 25 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 465 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 587 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 143 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 993 -m conntrack --ctstate NEW -j ACCEPT

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 465 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 587 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 143 -j DNAT --to-destination 10.200.200.5
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 993 -j DNAT --to-destination 10.200.200.5
angepasst. Also das hier
sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 80 -d 10.200.200.5 -j SNAT --to-source 10.200.200.10
sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 443 -d 10.200.200.5 -j SNAT --to-source 10.200.200.10
komplett raus geworfen.
Letzter Test
2023-04-26 23_17_13-mailcow ui - brave
Er zeigt jetzt über die VPS kommend im Log die externe IP an.
Ich denke, das sollte so laufen oder habe ich irgendwas spezielles vergessen?
Member: Spirit-of-Eli
Spirit-of-Eli Apr 26, 2023 at 21:27:51 (UTC)
Goto Top
Das Resultat klingt korrekt. Wenn der Rückweg über den VPS jetzt auch noch funktioniert hast du es geschafft👌
Member: schossel
schossel Apr 26, 2023 updated at 21:34:25 (UTC)
Goto Top
Ja, Rückweg geht. Interne Clients können über den VPS raus. Reverse Proxy geht. Mir fällt soweit nichts mehr ein.

Vielen Dank auf jeden Fall! Auf die Idee mit dem tagging wär ich nicht gekommen.

Ich habe deinen Beitrag oben als Lösung markiert, cool wäre, wenn du deinen Thread dort selbst nochmal verlinkst, dann muss man ihn in Aquis Beitrag nicht extra suchen!
Member: Spirit-of-Eli
Spirit-of-Eli Apr 27, 2023 at 05:28:03 (UTC)
Goto Top
Zitat von @schossel:

Ja, Rückweg geht. Interne Clients können über den VPS raus. Reverse Proxy geht. Mir fällt soweit nichts mehr ein.

Vielen Dank auf jeden Fall! Auf die Idee mit dem tagging wär ich nicht gekommen.

Ich habe deinen Beitrag oben als Lösung markiert, cool wäre, wenn du deinen Thread dort selbst nochmal verlinkst, dann muss man ihn in Aquis Beitrag nicht extra suchen!

Sehr gut. Ist erledigt.
Aber markiere ruhig auch den Beitrag von aqui. Er zielt ja auf das selbe hin.
GermansolvedQuestionServerVPNRouters, RoutingLinux
Hotly discussed
LinuxeroWireguard with systemd and nftablesLinuxero - 9 Comments