Port-Forwarding über Wireguard Tunnel

[syhrth]

Hallo liebe Community,

ich verzweifle gerade bei einer eigentlich einfachen Aufgabe: Port-Forwarding
Kurz zu meinem Setup:
- OPNSense mit WAN-IP (PublicIP) und Wireguard-Server 10.0.10.1/24 als VPS
- OPNSense mit WAN-IP2 (CG-NAT) und Wireguard-Client 10.0.10.2/24
   > Außerdem ein Interface für das 10.0.11.1/24 in dem ein Webserver steht (10.0.11.125:8000)

Ich möchte erreichen, dass ich mich über die WAN-IP:8000 mit dem Webserver auf 10.0.11.125:8000 verbinden kann.
Folgende Einstellungen habe ich dafür vorgenommen:
-> Routing: ForceGW auf alle 10.0.11.0/24 und 10.0.10.0/24 mit PublicIP
   > curl ifconfig.me liefert PublicIP
   > tcpdump auf Webserver zeigt eingehende und ausgehende Pakete zwischen ClientIP und 10.0.11.125 (LTE-Client)
-> Port-Forwarding: TCP/UDP auf WAN und Port 8000
   You cannot view this attachment.
   > Dazugehörig die automatisch erstelle Firewallregel auf WAN

Was mich besonders irritiert ist, dass die Pakete beim Webserver ankommen und auch raus gehen, aber nie beim Client ankommen. Das brachte mich zu dem Gedanken, dass es sich um ein asymetrisches NAT handelt, da aber über die ForceGW Regel der gesamte Traffic von beiden Netzen zurück zum VPS 10.0.10.1 geroutet wird bin ich überfragt.
Auf dem VPS läuft außerdem ein nginx Proxy mit Upstream 10.0.11.124, welcher funktioniert.

Habe ich hier irgendwo einen Denkfehler?

[Maurice]

Hast Du auf dem WAN-Interface des VPS auch ein Outbound-NAT für 10.0.11.0/24 konfiguriert? Falls nicht, dann gehen die vom Webserver gesendeten Pakete mit privater Quelladresse ins Internet, werden daher gefiltert und kommen nicht beim Client an.

Grüße
Maurice

[viragomann]

Was mich besonders irritiert ist, dass die Pakete beim Webserver ankommen und auch raus gehen, aber nie beim Client ankommen. Das brachte mich zu dem Gedanken, dass es sich um ein asymetrisches NAT handelt

Damit dürftest du richtig liegen.

da aber über die ForceGW Regel der gesamte Traffic von beiden Netzen zurück zum VPS 10.0.10.1 geroutet wird bin ich überfragt.

Das wirkt sich nur auf ausgehende Verbindungen aus, nicht auf Respones auf eingehende.

Hairpining, wie oben empfohlen, ist eine Möglichkeit, die Antworten auf die richtige Route zu bringen, hat aber den Nachteil, dass dann aus Sicht des Webservers sämtliche Anfragen von 10.0.10.1 kommen. Die wahre Quell-IP bleibt ihm verborgen.
Wenn du diese am Webserver sehen möchtest, braucht es Folgendes:

• Am Client musst du der Wireguard Instanz ein Interface zuweisen und aktivieren, falls noch nicht geschehen.
• Auf diesem muss die Pass-Regel definiert werden, die den eingehenden, weitergeleiteten Traffic vom VPS erlaubt.
• Von "Wireguard" (Interface Gruppe) sämtliche Pass-Regeln entfernen. Solltest du für weitere WG Instanzen Pass-Regeln benötigen, ist es am besten, für diese ebenfalls ein dediziertes Interface einzurichten.
  

Grüße

[syhrth]

Hast Du auf dem WAN-Interface des VPS auch ein Outbound-NAT für 10.0.11.0/24 konfiguriert? Falls nicht, dann gehen die vom Webserver gesendeten Pakete mit privater Quelladresse ins Internet, werden daher gefiltert und kommen nicht beim Client an.

Grüße
Maurice

Das ist selbstverständlich konfiguriert: NAT-Modus: Hybrid und neben den automatischen Regeln die für 10.0.11.0/24 auf WAN ergänzt. Ich denke, sonst würde der Internetzugriff vom Webserver per bspw. curl nicht korrekt funktionieren.

[syhrth]

Was mich besonders irritiert ist, dass die Pakete beim Webserver ankommen und auch raus gehen, aber nie beim Client ankommen. Das brachte mich zu dem Gedanken, dass es sich um ein asymetrisches NAT handelt

Damit dürftest du richtig liegen.

da aber über die ForceGW Regel der gesamte Traffic von beiden Netzen zurück zum VPS 10.0.10.1 geroutet wird bin ich überfragt.

Das wirkt sich nur auf ausgehende Verbindungen aus, nicht auf Respones auf eingehende.

Hairpining, wie oben empfohlen, ist eine Möglichkeit, die Antworten auf die richtige Route zu bringen, hat aber den Nachteil, dass dann aus Sicht des Webservers sämtliche Anfragen von 10.0.10.1 kommen. Die wahre Quell-IP bleibt ihm verborgen.
Wenn du diese am Webserver sehen möchtest, braucht es Folgendes:

• Am Client musst du der Wireguard Instanz ein Interface zuweisen und aktivieren, falls noch nicht geschehen.
• Auf diesem muss die Pass-Regel definiert werden, die den eingehenden, weitergeleiteten Traffic vom VPS erlaubt.
• Von "Wireguard" (Interface Gruppe) sämtliche Pass-Regeln entfernen. Solltest du für weitere WG Instanzen Pass-Regeln benötigen, ist es am besten, für diese ebenfalls ein dediziertes Interface einzurichten.
  

Grüße

Vielen Dank für deine Erklärung, ich verstehe grundlegend was du meinst.
Verstehe ich es richtig, dass du mit Client in diesem Fall die OPNSense an meinem Zuhause meinst. Zumindest ist diese ein Client vom Wireguard Server in der Cloud.
-> Dort ist bereits ein WG-Interface mit 10.0.10.2 konfiguriert.
-> Dort sind Pass Regeln Any -> 10.0.10.0/24 & Any->10.0.11.0/24 & Any -> NonLocal definiert
WireGuard(Group) hat keine Regeln.

Das ist das aktuelle Setup, das so weit ich dich richtig verstehe bereits deine Hinweise umsetzt. Korrigiere mich gerne, falls ich etwas missverstanden habe

[viragomann]

Hairpining, wie oben empfohlen, ist eine Möglichkeit, die Antworten auf die richtige Route zu bringen

Ich hatte das falsch verstanden das ist gar nicht Hairpining für eingehende Verbindungen.

Das wäre am VPS eine Outbound NAT-Regel am Wireguard Interface für Source = any, Ziel = der Webserver.

Verstehe ich es richtig, dass du mit Client in diesem Fall die OPNSense an meinem Zuhause meinst.

Ja, genau.
Wenn das alles gemacht ist, sollte es eigentlich klappen, aber das

> tcpdump auf Webserver zeigt eingehende und ausgehende Pakete zwischen ClientIP und 10.0.11.125 (LTE-Client)

deutet darauf hin, dass die Regel nicht greift. Jedenfalls nicht, wenn du auf OPNsense am Wireguard Interface die Antwort-Pakete nicht siehst, dafür aber am WAN.

[Maurice]

-> Dort ist bereits ein WG-Interface mit 10.0.10.2 konfiguriert.
-> Dort sind Pass Regeln Any -> 10.0.10.0/24 & Any->10.0.11.0/24 & Any -> NonLocal definiert
WireGuard(Group) hat keine Regeln.

Hast Du in der Regel "Pass Any -> 10.0.11.0/24" reply-to explizit auf das das Gateway 10.0.10.1 gesetzt? Das ist erforderlich, damit die Antworten des Webservers auch wieder durch den Tunnel zurückgeroutet werden.

Die "Force Gateway"-Regel greift nur bei Verbindungen, die vom Webserver initiiert werden (z. B. der curl-Test).