Inbound NAT ohne Maskierung

[maraD]

Hallo Leute,

ich habe eine Frage zum Thema NAT. Habe dies auch schon paar Male benutzt konfiguration ist sehr simpel:

Quell Interface: WAN
IPversion: v4
Prot: TCP
Source: any
Source Port: any
Destination: WAN Adresse / Diese Firewall
Weiterleiten an DMZ Server: 10.20.1.10
Port Weiterleitung 80/443
Pool keine Option

Aufbau:

Code Select Expand


      WAN / Internet
            :
            : -
            :
      .-----+------.
     |  Gateway  |  (ISP-Router)
      '-----+------'
            |
        WAN | IP or Protocol
            |
      .-----+------.   private DMZ   .--------------.
      |OPNsense +-----------------+DMZ-Server |
      '-----+------'   172.20.0.1     '---------------'
            |
        LAN | 10.1.0.1/24
            |
      .-----+------.
      |LAN-Switch|
      '-----+------'
            |
    ...-----+------... (Clients/Servers)


In dieser Konfiguration sehe ich auf dem Webserver nur dass die Opensense 10.20.0.1 (DMZ Interface) auf mein Webserver zugreift.

Ich möchte gerne die Source IP auf dem Webserver sehen welche zugreifen sprich die WAN IP des Besuchers. ???

Wie lässt sich diese Konfiguration bewerkstelligen. (Ein Proxy wird nicht benötigt) Ist für mein Verständnis.  :D

Danke  ;)

[meyergru]

Geht per IPv4 grundsätzlich nicht, weder mit NAT noch per Proxy.

Mit NAT findet, wie der Name schon sagt, eine Adressübersetzung statt. Mit einem Reverse Proxy könnte man zumindest einen HTTP-Header hinzufügen, den man auf dem Webserver auswerten kann. Die IP des "Absenders" ist aber in keinem Fall die wirkliche.

Was geht, ist IPv6. Dabei findet ja keine NAT statt.

[maraD]

Danke für den raschen Input.

Wie löse ich dann folgende Problematik hinter der Firewall ist eine WAF und hinter der WAF kommt der Webserver zum Einsatz.

Die WAF macht ihren Job und blockiert die IP des Angreifers erfolgreich, da die Absender IP immer die Firewall ist, wird schlussendlich jeder Traffic von der IP also die 10.20.1.1 geblockt für die eingestellte Zeit. Heisst jeder andere hat auch keinen Zugriff mehr. Es muss doch möglich sein die Maskierung aufzuheben sodass die Absender IP nicht das Firewall Interface ist.

Auf der WAF sollten die IP der Besucher terminieren.

(Ein Proxy auf der Opensense kann dies händeln da der Dienst diekt auf dem terminierenden Gerät läuft.)

Mache ich hier einen Denkfehler :-\ ?

[marcquark]

Kannst du mal Screenshots deiner NAT Regeln posten? Bin der Meinung das sollte gehen, beim DNAT ist es eigentlihc nicht notwendig die Sourceadresse und -port anzufassen, und bin mir auch relativ sicher das in der Vergangenheit schon häufiger so mit OPNsense umgesetzt zu haben - hab allerdings gerade kein Testsetup zur Verfügung um es zu verifizieren...

[maraD]

Die Source IP muss bei der WAF ankommen sonst lässt sich in der Theorie Security schlecht umsetzen.  :-[

Das wäre diese Konfiguration:

[marcquark]

Hmmm, laut Eingangspost hast du es mit Destination "This Firewall" auch schon probiert, richtig? Die Regel sieht erst mal gut aus, wüsste nicht warum die OPNsense die Source Adresse austauschen sollte. Kannst du mal noch deine Outbound NAT Regel screenshotten, inklusive der automatisch generierten? Eventuell liegt da der Hase im Pfeffer.

Ansonsten passen die Adressen deines ersten Posts, des Screenshots und der ASCII Grafik alle nicht zusammen. Laut Grafik ist da ein weiterer Router. Könnte der eventuell das Problem sein? Zeichne das vielleicht noch mal sauber neu...

[maraD]

Oke, mache ich sobald ich dazu komme.  ;)

[JeGr]

Bitte mal nachschauen in den erweiterten Optionen bezüglich NAT Reflection ob da irgendwas angeschaltet wurde (in der Regel selbst ja nicht, aber generell) und ob das ggf. auf NAT via Proxy steht. Sofern nicht gebraucht darf Reflection gern auf "nope" stehen oder auf PureNAT was eigentlich genügt.

Prinzipiell hat Marc aber recht - und @meyerguru nicht - dass beim simplen Port Forwarding eigentlich die Source IP des Absenders nicht verändert wird. Die Firewall proxy'ed hier nicht einfach und macht eine neue Verbindung auf, sondern schreibt die Ziel IP um, die Source bleibt aber gleich. Daher würde sich mir auch nicht erschließen, warum du Verbindungen von der Firewall bekommen solltest statt von der Quelle im Internet.

Wäre es anders, könnten ja sämtliche Pakete der Verbindung entweder nach Verbindungsaufbau nicht mehr zugestellt werden oder müssten immer durch einen Proxy der Firewall laufen (mit entsprechend Overhead). Das macht so keinen Sinn...

Cheers

[meyergru]

Stimmt. Ich hatte es zwar verifiziert, aber dummerweise mit Port 443, wo der HAproxy hinter lag. Damit geht es natürlich nicht. Mit reiner DNAT geht es schon, dann allerdings muss man auf HAproxy verzichten und die namensbasierte Verteilung dahinter machen.

[maraD]

Danke, ich schaue es mir an.

Merci für euere Inputs, melde mich nach den Ferien.