Zugriff interner Server auf Public IP der Firewall funktioniert nicht

[theq86]

Hallo,

Folgendes Szenario habe ich:
Eine aktuelle OPNsense als Edge Gateway.
1 WAN (sagen wir mal 1.2.3.4)
1 DMZ (10.11.0.1/24) in dem 1 Reverse Proxy Server steht
1 WEB (10.11.1.1/24)
+ weitere Netze für Datenbanken zB.

Am Standort ist nur 1 Öffentliche IP verfügbar und gewünscht. Sämtlicher Traffic soll über das GW

Regeln:
- Je internem Netz (WEB, DB, DMZ) eine Outbound NAT Regel auf WAN mit Interface IP
- 2 Port Forwardings an WAN für HTTP und HTTPS an den Reverse Proxy in DMZ
- Schnittstellenregeln, die HTTP und HTTPS aus den Netzen erlauben

Problem:
- Externer Zugriff funktioniert wie gewünscht, DNAT leitet auf den Proxy weiter
- Zugriff nach draußen via SNAT geht, sofern die angefragte IP NICHT die externe IP der Firewall ist
- Möchte ein interner Server einen HTTP/S Request auf die externe IP der Sense machen bleibt der Traffic in der Sense hängen

Warum soll das funktionieren? Nun, viele Webapplikationen machen Self-Requests. Diese funktionieren in dem Zustand nicht. (Weil die A-Records der Domain auf die Sense zeigen) Was ich vermeiden möchte sind Split DNS Szenarios oder Hosts-Einträge.

Diverse NAT Reflection Einstellungen habe ich schon erfolglos durchprobiert.

Hat jemand ne Idee ?

[JeGr]

> 1 WAN (sagen wir mal 1.2.3.4)

Sagen wir lieber mal: 203.0.113.123/24  (--> https://datatracker.ietf.org/doc/html/rfc5735, IPv4 Doku Netze)

> - Möchte ein interner Server einen HTTP/S Request auf die externe IP der Sense machen bleibt der Traffic in der Sense hängen

Bleibt nicht hängen, aber ist nicht definiert, wenn dein Port Forwarding/Redirection keine "NAT Reflection" aktiv hat. Ansonsten ist die Weiterleitung NUR von WAN AUS ANkommend erlaubt, aber nicht von innen. Daher passiert auch nichts.

> Nun, viele Webapplikationen machen Self-Requests.

Wenn die auf die Domain gehen - was sie sollten(!) - dann geht das über einfachen DNS Rewrite bzw. DNS Override in der Sense -> besserer Weg und direkter, weil dann der Host gleich mit sich selbst spricht. Bei NAT Reflection gibts Ping-Pong mit der Firewall, was kann/sollte man dadurch vermeiden.

> Weil die A-Records der Domain auf die Sense zeigen) Was ich vermeiden möchte sind Split DNS Szenarios oder Hosts-Einträge.

Warum will man das vermeiden, wenn genau das

a) Abhilfe schafft und
b) die bessere Alternative dazu ist, da direkter mit weniger Lag/Latenz für die Anwendung und ohne unnötige Laufzeit via Firewall wieder zum Host zurück?

Alles was NAT Reflection (was du enablen müsstest) hier dann für deine Anwendung tut, ist sie langsam zu machen. Ja es läuft, es läuft aber "doof".

Besser:

1) Anwendung verbessern (lokale Zugriffe der Software sollten via localhost oder konfigurierbaren DNS/IP gehen) -> bringt am Meisten
2) DNS Rewrite (ggf. direkt auf dem Host der Anwendung schon) -> bringt am zweitmeisten da das Paket direkt auf dem Host bleibt und keinen Umweg über die Firewall drehen muss.

Wenn einem die Anwendung oder die Performance o.ä. komplett egal ist, kann man dann beim Port Forwarding direkt angeben, dass PureNAT (besseres Übel) oder NAT via Proxy (noch schlimmer) aktiviert werden. Dann gilt das Redirecting auch für interne Zugriffe auf die externe IP und dann sollte wieder alles "normal" klappen.

Wie gesagt schöner ist tatsächlich einfach ein interner Rewrite des DNS auf die interne IP. SplitDNS will man da nicht vermeiden, sondern genau nutzen, damit man unnötige Latenz minimiert.

Cheers
\jens

[theq86]

> Sagen wir lieber mal: 203.0.113.123/24  (--> https://datatracker.ietf.org/doc/html/rfc5735, IPv4 Doku Netze)

Geh ich konform mit.

> Bleibt nicht hängen, aber ist nicht definiert, wenn dein Port Forwarding/Redirection keine "NAT Reflection" aktiv hat. Ansonsten ist die Weiterleitung NUR von WAN AUS ANkommend erlaubt, aber nicht von innen. Daher passiert auch nichts.

Seltsam. Ich habe alle möglichen Kombinationen mit den NAT Reflection Einstellungen ausprobiert und nichts führte zum Ergebnis. Aber eventuell haben mir da weitere Firewallregeln gefehlt ?!?

Ich habe einen Weg gefunden, der bei mir funktioniert. In Anhang 1 meine DNAT Regel vorher, in Anhang 2 nachher.
Ich weiß allerdings auch nicht genau wie "optimal" das ist.

> Wenn die auf die Domain gehen - was sie sollten(!)

Tun sie!

> dann geht das über einfachen DNS Rewrite bzw. DNS Override in der Sense -> besserer Weg und direkter, weil dann der Host gleich mit sich selbst spricht.

Ja, das ist durchaus ein bequemer und auch sauberer Weg. Nur dass in meinem Fall der Web-Host mit dem Proxy sprechen muss, nicht sich selbst, da der Proxy SSL terminiert und der webserver nicht.

> Warum will man das vermeiden

Ganz einfach, weil dann gewisse DNS Informationen an verschiedenen Stellen stehen und man die bei Änderungen dann immer mit bedenken muss. Ich bin generell ein Freund davon an so wenig Baustellen wie möglich zu arbeiten.

[JeGr]

> Seltsam. Ich habe alle möglichen Kombinationen mit den NAT Reflection Einstellungen ausprobiert und nichts führte zum Ergebnis. Aber eventuell haben mir da weitere Firewallregeln gefehlt ?!?

Sollten - wenn eingestellt - eigentlich automatisch generiert werden von der NAT Regel.

> Ja, das ist durchaus ein bequemer und auch sauberer Weg. Nur dass in meinem Fall der Web-Host mit dem Proxy sprechen muss, nicht sich selbst, da der Proxy SSL terminiert und der webserver nicht.

Ah das erklärt den Wunsch. Verständlich, aber dann wäre der DNS auf den Proxy ja trotzdem zielführend?

> Ganz einfach, weil dann gewisse DNS Informationen an verschiedenen Stellen stehen und man die bei Änderungen dann immer mit bedenken muss. Ich bin generell ein Freund davon an so wenig Baustellen wie möglich zu arbeiten.

Kann ich nachvollziehen, bei der Problemstellung ist das aber durchaus der Weg, den man lieber geht/gehen möchte. Wenn nicht, kann man das immer noch mit Reflection machen

Bei den Shots: Sorry, die sind so hart klein gecuttet, da sehe ich weder welches Interface noch ob NAT oder Regel etc. da wären wirkliche Screenshots oder Edits von der Regel etc. einfacher als genau die eine Zeile in groß Zumal ich keine Ahnung habe, was jetzt wieder WAN WEB ist? Ist gerade eher irritierend als hilfreich

[theq86]

Okay, die Screenshots sagen eigentlich nur folgendes aus:

Ein Port Forwarding an der WAN Schnittstelle mit Ziel "This Firewall", Port 443, weitergeleitet an den Proxy auf Port 443.
Dann hab ich einfach die WEB Schnittstelle hinzugefügt. Das ist das Interface, mit dem die Sense im Webserver-Netz ist.
Nach dem Hinzufügen des WEB Netzes zu dieser Forwardingregel ging es auf ein mal. Wenn ich NUR das WAN Netz drin hatte, ging es trotz Reflection nicht.

Ich habe mich jetzt doch für den DNS Override via Unbound entschieden. Einfach weil es sauberer und durchsichtiger ist, wie du schon sagst.

Danke auf jeden Fall für deinen Input.

[JeGr]

> Ein Port Forwarding an der WAN Schnittstelle mit Ziel "This Firewall", Port 443, weitergeleitet an den Proxy auf Port 443.

Ziel bitte lieber "WAN address". This Firewall includiert wesentlich mehr als die WAN IP und kann sehr unerwünscht sein!

> Dann hab ich einfach die WEB Schnittstelle hinzugefügt. Das ist das Interface, mit dem die Sense im Webserver-Netz ist.

Wie hinzugefügt?
Das ist irgendwie unklar.

> Danke auf jeden Fall für deinen Input.

Gern

[theq86]

> Wie hinzugefügt?
> Das ist irgendwie unklar.

Du kannst ja grundsätzlich ein Port Forwarding auf mehreren Interfaces zugleich einstellen (multi select).
nachdem meine regel nun an den Interfaces WAN und WEB war, hat es geklappt.

[JeGr]

OK langsam dämmert mir was bei dir falsch läuft bzw. was da buggy ist.

Forwards sind nicht dafür ausgelegt gewesen (ursprünglich), dass sie auf mehreren Interfaces laufen. Das kam wohl neu mit dazu. Früher gings nicht. Bei mehreren Interfaces ist es auch klar, dass das mit Regel Erstellung schwierig wird, da es keine "eine" normale Regel geben kann, die assoziiert wird. Also wird - zumindest in meinem Test - bei Multi Selects eine Floating Rule erstellt und assoziiert. Allerdings nur beim ersten Mal, also beim Anlegen eines neuen Redirects (Port Forwards). Wenn mans danach ändert auf None, kann man die Regel nicht mehr auswählen und die Floating Rule wird gelöscht. Danach kann man nur noch None oder Pass auswählen, Rule ist weg und taucht nicht mehr auf.

Da man dazu bei Destination bei Multiselect des Interfaces auch kein korrektes Interface angeben kann (weils mehrere sind) und auf "This Firewall" ausweichen muss, würde ich nicht empfehlen das so zu machen. Kann man - klar - finde ich aber aktuell dann schlecht gelöst. Da fehlt mir dann eine Auswahl an Destination wie "selected addresses", so dass bspw. bei WAN1/WAN2 auch nur WAN1 address und WAN2 address als Destination ausgewählt sind und nicht plötzlich alle IPs die man hat. Gerade wenn per Virtual IP dann mehr IPs gebunden sind, könnte das böse ins Auge gehen.

Im Anhang sieht man meinen Test: Interfaces WAN_VF und WAN_1U1 sind selektiert, dann kann man beim "Neu erstellen" unten "Add rule" auswählen. Das erzeugt dann eine Floating Rule (weil multiple Interfaces). Ich denke aber eher, dass das ggf. negative Seiteneffekte bezüglich Gateway Selection etc. bei MultiWAN haben könnte.


Betrifft dich wegen MultiWAN jetzt nicht direkt, aber deshalb wirst du wohl die Einstellung mit der Regel nicht sehen, weil du multiple Interfaces ausgewählt hast - vermute ich.
Würde daher die Forwards nochmal löschen, nur am WAN anlegen, NAT Reflection Enable, Filter Rule Assoc mit Add Rule machen (sollte dann am WAN ne Rule auftauchen) und bei System Advanced Settings noch die NAT Reflection auf Pure NAT stellen.

[theq86]

Interessant, obwohl das ja auf der Hand gelegen hat, hab ich nie ganz tabula rasa mit den forwarding regeln gemacht.
Eventuell hätte das auch geholfen. Da ich mich aber mittlerweile mit der DNS Lösung angefreundet habe, habe ich jetzt auch keine Lust mehr nachträglich noch mehr zu debuggen.

[JeGr]

DNS ist eh freundlicher