Port Forwarding mit originall Quell IP über mehrere Hops.

[lennart]

Link zu PDF: https://nc.ljoswig.de/s/ACw6yZK2HxNRdmB

Moin,
wie in der Zeichnung (ganz unten im PDF) und in der Aufzählung geschildert,
der Aufbau (der einwandfrei) funktioniert und das Problem, das sich daraus ergibt.
1.   TCP-Paket eingehend auf WAN-Adresse bei Hetzner
2.   Port Forwarding auf Server im Lan (Opnsense Home)
3.   Outbound NAT: Quell IP wird auf Interface (wg) IP der Opnsense (10.99.99.1) gesetzt
4.   Antwort vom Server zurück über Wireguard zum Hetzner Router
5.   Outbound NAT. Quell IP wird wieder zurückgesetzt. (Automatisch durch 3)
6.   Port Forwarding: Destination wird wieder ersetzt (Automatisch durch Regel 2)
7.   Paket ausgehend zum Client
Das Problem, das sich daraus ergibt, ist das die Quell IP nicht mehr für den Web-Server sichtbar ist. So ist z.B. Brute Force Erkennung und Abwehr nicht mehr möglich.
Ohne das Outbound Nat würde der Webserver das Paket jedoch über das Default gateway schicken und nicht über den WG, weil die Source ja eine öffentliche IP ist.
Lösungsidee: Die Opnsense bei Hetzner wird als Default Gateway für den LAN Traffic des Webservers. Dann landet die Antwort auch wieder bei der Hetzner Opnsense.
Problem: Es funktioniert nicht! Der Upstream über Opnsense (Hetzner) geht.

Aber das Paket kommt ohne Outbound Nat (Schritt 3) nicht wieder beim Client an. Auf der Opnsense Home sind keine Port Forward oder eigenen Outbound NAT Rules generiert. Leider kann ich das Paket ja nicht wieder zurückverfolgen. Oder? Nach dem Erreichen des Web-Servers wird ja kein Log mehr bei der Antwort geschrieben?
Egal ob mit oder ohne Quell IP Umschreibung. Das Paket kommt beim Webserver an! Das habe ich überprüft.
Hat jemand eine Idee, woran das liegen könnte?

[lennart]

Hier die Bilder nochmal direkt

[lennart]

Bild2

[albi]

Wenn es nur um einen Webserver geht, gibt es z.B. für Apache eine Helper mod:
libapache2-mod-rpaf                                           - Apache2-Modul zur Entnahme der letzten IP aus dem »X-Forwarded-For«-Header
Allerdings musst du dann beim Hetzner Server einen Webproxy installieren, z.B. Apache2 oder Nginx, der zu deiner internen IP Webserver IP weiterleitet und den Header einfügt.
Ob es sowas auch auf IP Ebene gibt weiß ich nicht.

[Patrick M. Hausen]

Ich würde bei Hetzner das Caddy-Plugin einsetzen und in dem als Backend/Handler die Ziel-IP-Adresse des Webservers im internen Netz konfigurieren. Diese müsste dann über die Tunnel erreichbar sein, damit das funktioniert.

[lennart]

Danke für den Denk Anstoß,

1. der Webserver über Port 80 dienst  nur zur Demonstration. Hinter dem Port forwarding stehen noch weitere TCP und UDP anwendungen.

2. Ist der Aufbau so wie ich ihn beschrieben habe überhaupt möglich? Eigendlich ist bis auf den zusätlichen Hob ja technisch gesehen nichts anders. Oder?

3. Gibt es eine möglichkeit herauszufinden wo die antwort des Webservers tatsächlich landet bzw. welchen weg diese nimmt. Wenn ich das wüste, dann könnte ich das Problem vieleichst selbst fixen.

Die Idee mit dem Caddy hallte ich mir aber offen.

Danke für die bisherige Hilfe!
 

[Alpha_DE]

Ich habe bei mir solche Services unter Proxmox mit OPNsense als einer VM laufen, der Traffic läuft vom Host über die OPNsense zu den anderen VM, die Quelladresse bleibt aber erhalten trotz 1:1 NAT oder Portdorwarding und Nutzung von privaten IP für die internen Verbindungen.

Warum sollte die Quelle IP überschrieben werden, die Ziel IP muss richtig gesetzt werden und Outbou d wieder korrekt erfolgen. Das passiert aber bei Port Forward bzw 1:1 NAT

[lennart]

@Alpha_DE die Quell IP ändert sich aufgrund des Outbound Nat das notwendig ist, damit der Webserver nach beantworten der Anfrage wieder den richtigen Router findet. Wnn ich das Outbount NAT deaktiviere das im WG interface arbeitet (von mir selbst ersdtellt), dann wird zwar die richtige Quell IP weitergeleitet aber das Paket findet nicht denn weg zum richtigen Router zurück.

[Bob.Dig]

Ohne jetzt alles nachvollzogen zu haben, versuch doch mal statt NAT zuhause das reply-to zu setzen, wie hier im zweiten Bild zu sehen ist.
https://administrator.de/tutorial/feste-ips-zuhause-in-pfsense-via-wireguard-tunnel-1124828094.html#comment-7914158237

[lennart]

@Bob.Dig danke für Hilfe. Das funktioniert wie es soll. Ich verstehe nur noch nicht ganz was reply to auf technischer ebene genau bedeutet, aber das finde ich schon noch heraus.

Danke natürlich auch an alle anderen die hier versucht haben zu helfen