Interne Pakete zur externen IP
-
Hallo zusammen,
ich habe ein Setup mit der pfSense so wie das hier ~:
WAN | IP or Protocol | .-----+-----. priv. DMZ .------------. | pfSense +-------------+ DMZ-Server | '-----+-----' 172.16.16.1 '------------'
Auf dem DMZ Server läuft ein Nginx Proxy Manager und diverse Services auf die der Nginx dann, je nach Domain, weiterleitet.
Auf der pfSense habe ich unter Firewall > NAT > Port Forward folgende Regeln| Interface | Protocol | Source Address | Source Port | Dest. Address | Dest. Ports | NAT IP | NAT Ports | | WAN | TCP | * | * | WAN address | 80 (HTTP) | 172.16.16.1 | 80 (HTTP) | | WAN | TCP | * | * | WAN address | 443 (HTTPS) | 172.16.16.1 | 443 (HTTPS) |
Soweit funktioniert das Setup auch. Wenn ich von außen eine Domain aufrufe z.B. https://test.example.com dann bekomme ich die erwartete Antwort vom Service A hinter dem Nginx Reverse Proxy.
Jetzt zum eigentlichen Problem, wenn ich jetzt vom DMZ Server z.B. folgendes mache, bekomme ich einen Timeout.
curl -iv http(s)://test.example.com
Mit Packet Capture kann ich sehen, dass die Pakete auf jeden fall am DMZ Interface ankommen, aber leider nicht am WAN interface. Ich vermute, dass die pfSense schlau genug ist zu erkennen, dass es sich bei der aufgelösten IP um ihre eigene handelt und es deshalb nicht über das WAN interface routed, kann das sein?
Da ich die Port Weiterleitung ja aber fürs WAN interface definiert habe, gehen die Pakete dann scheinbar verloren, zumindest habe ich sie in keinem anderen Interface sehen können.Wie bekomme ich es jetzt hin, dass die pfSense entweder das Packet, auch wenn es sich um ihre eigene IP handelt, dennoch über das WAN interface leitet, oder macht man das ganz anders?
Bin über jeden Tipp Dankbar.
-
@sascha-sphw
Hallo,Mit Packet Capture kann ich sehen, dass die Pakete auf jeden fall am DMZ Interface ankommen, aber leider nicht am WAN interface.
Da haben sie auch nichts verloren.
Ich vermute, dass die pfSense schlau genug ist zu erkennen, dass es sich bei der aufgelösten IP um ihre eigene handelt und es deshalb nicht über das WAN interface routed, kann das sein?
So ähnlich. Die Pakete gehen werden vom Kernel verarbeitet, aber der verwirft sie, weil ihm nicht gesagt wurde, was er damit tun soll.
Da ich die Port Weiterleitung ja aber fürs WAN interface definiert habe, gehen die Pakete dann scheinbar verloren, zumindest habe ich sie in keinem anderen Interface sehen können.
Genau. Du bräuchtest dieselbe Regel auch am DMZ Interface.
Wie bekomme ich es jetzt hin, dass die pfSense entweder das Packet, auch wenn es sich um ihre eigene IP handelt, dennoch über das WAN interface leitet, oder macht man das ganz anders?
Die beste Lösung ist, ein DNS Host Override für die Domain anzulegen, so dass sie von intern direkt auf die IP des Proxys aufgelöst wird. Dann braucht es auch keine Port Forwarding.
Voraussetzung ist aber, dass ein lokales DNS verwendet wird wie der DNS Resolver auf der pfSense.Ist das keine Option, müssen die Request weitergeleitet werden. Wenn Server und Client am selben Interface hängen, geht das nur mit gleichzeitigem Umsetzen der Quell-IP in die Interface IP von pfSense. Ansonsten käme es zu einem asymmetrischen Routing und Paket würden blockiert.
Das ist mit NAT Reflection am einfachsten umsetzbar. Das "spiegelt" quasi die NAT Regeln vom WAN auf die internen Interfaces, ohne die Regeln explizit auch anzuzeigen.
Die Funktion kannst du in jeder Port Forwarding Regel aktivieren oder auch global in System > Advanced > NAT.
Ob der "pure NAT" Modus ausreicht, weiß ich jetzt nicht. Kann sein, dass es den Proxy-Modus erfordert, um vom selben Interface auf den Server zugreifen zu können. War jedenfalls früher so, jetzt verwende ich die Funktion nicht mehr. -
Danke für die ausführliche Antwort. Das hilft mir schon sehr weiter.
OK, dann muss ich mich noch etwas damit spielen, denn den DNS Resolver habe ich mit dem Server noch nicht zum laufen bekommen.