Messages

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.

Vielen Dank für deine Hinweise, ich habe tatsächlich nicht geprüft ob die Pakete auf anderen Interfaces auftauchen. Das wäre noch ein möglicher Debugging-Schritt.

Das ist denke ich aber auch nicht mehr nötig, da der Vorschlag

-> 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).

das Ganze sofort gelöst hat. Mir war diese Option tatsächlich noch nicht bekannt. Sie macht aber durchaus Sinn.

Auch dir vielen Dank für deine Hinweise :)

case closed

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

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.

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?

[Ich danke dir für deinen Hinweis]

Eine wilde Vermutung für einen in meinen Augen wilden Fehler. Ich danke dir für deinen Hinweis, daran hatte ich nie gedacht.

Lösung:
In meinem Setup musste ich die MSS im MikroTik und in der OPNSense auf 1460 setzen. (was einer MTU von 1420 entspricht und somit für das Wireguard Interface geeignet ist, dieses wird mit MTU von 1420 gelistet).
In meinem Fall kommt weder IPv6 noch PPPoE dazu, ansonsten muss der Wert weiter reduziert werden.
Ergänzend eine Anleitung um dies im MikroTik zu bewerkstelligen: https://support.ispsupplies.com/portal/en/kb/articles/pmtu-and-mss-discovery-issues-resolved-with-mikrotik
Grüße syhrth

Hallo liebes Forum,
Ich bin leider ratlos was ein aktuelles Problem angeht. Erstmal die Beschreibung meines Testaufbaus um euch etwas abzuholen (detailliert im Bild zu sehen):
VPS mit öffentlicher IPv4 soll den eingezeichneten Webserver über den Wireguard Tunnel für das Internet erreichbar machen (was soweit auch einwandfrei funktioniert). Möchte jetzt allerdings der Webserver auf bestimmte Internetseiten zugreifen (getestet habe ich reddit.com und speedtest.net), so timed der Browser bei Domains wie z.B. b.cdnst.net aus. Ergebnis ist eine vollkommen unfertig geladene Seite.
Das Problem besteht für jeden Client im 10.11.0.0/24 und 10.10.0.0/24 Netz, unabhängig vom Betriebssystem/Browser. (Ich kann den MikroTik Router als Fehlerquelle ausschließen, da das selbe Verhalten bei meinem PC auftritt, wenn ich ihn in den Wireguard Tunnel also mit IP 10.10.0.3 hänge)
Der VPS mit LiveCD hat keine Probleme die Seiten zu laden.

Zur Konfiguration in OPNSense (bzw Routen und GW auch Mikrotik Router):
- Gateways gesetzt und Routen definiert (Clients im 10.11.0.0/24 müssen den Weg über das Gateway 10.10.0.1 also die OPNSense nehmen, eine andere Route gibt es nicht)
- Firewall Floating: Definierte Port Forwards erlaubt (automatische Regelerstellung)
- Firewall WireguardInterface: 10.10.0.0/24 -> * erlaubt und 10.11.0.0/24 -> * erlaubt
- Firewall WAN: Zugriff auf Wireguard Port erlaubt
- Firewall NAT Outbound Mode Hybrid + 2 manuelle Regeln
---WAN   10.10.0.0/24    *   *   *   Interface address   *   NO   Outbound NAT
---WAN   10.11.0.0/24    *   *   *   Interface address   *   NO   Outbound NAT

Ehrlich gesagt bin ich etwas überfragt weshalb das Setup grundlegend funktioniert (bspw. bild.de, google.de und viele andere Seiten), aber für gewisse Seiten wiederum nicht.
Vielleicht hat von euch noch jemand einen heißen Tipp was das Problem sein könnte, danke im Vorraus :)

MfG syhrth
P.S.: Da ich den Fehler nicht genauer eingrenzen kann, ist der Beitragstitel etwas unelegant  :-X