lowbudget
Goto Top

OPNsense Hairpin-reflection nat funktioniert nicht

Hi,

seit kurzen habe ich eine opnsense Firewall. Zusätzlich dazu habe ich einen kleinen Webserver. Über Portforwarding erreiche ich diesen von außen auch schon. Leider erreiche ich ihn aus dem internen Netz nicht. Es kommt die DNS Rebind Warnung.

Kurz gesucht und anscheinend muss ich mich hier auch mit ausgehenden Nat beschäftigen. Ich habe versucht, mich an diese Anleitung zu halten:
https://docs.opnsense.org/manual/how-tos/nat_reflection.html

Allerdings habe ich keine DMZ. Mein Webserver und meine Clients sind im selben Lan. Jetzt bin ich mir nicht sicher, was ich an der Anleitung ändern muss.

Mein letzter Stand war, dass die Rebind Warnung nicht mehr kommt, dafür hat er sich tot geladen. Ich denke meine Ausgehende Natregel ist falsch. Kann mir hier einer weiterhelfen?

Die automatisierten Einstellungen unter den erweiterten Firewallregel wollte ich nicht nehmen. Ich hatte gelesen, dass damit zu viele unnötige Regeln erstellt werden. Außerdem würde ich das Problem gerne vollumfänglich verstehen.

Content-ID: 4715917339

Url: https://administrator.de/contentid/4715917339

Printed on: October 13, 2024 at 11:10 o'clock

14260433693
Solution 14260433693 Aug 25, 2024 updated at 15:34:42 (UTC)
Goto Top
Buonasera.

Außerdem würde ich das Problem gerne vollumfänglich verstehen.

👍. Das ist gut so und der allererste Schritt vor allen anderen!

Gegeben sei das folgende Beispiel fürs Verständnis:

back-to-topTest-Umgebung


  • A-Record für server.mydomain.de => 1.2.3.4
  • Externe IP der OPNSense am WAN 1.2.3.4
  • Internes LAN 10.1.1.0/24
  • LAN IP der OPNSense 10.1.1.1.
  • Webserver im LAN mit IP 10.1.1.20/24
  • Client im LAN mit IP 10.1.1.50/24

back-to-topPacket Flow (ohne Hairpin-NAT):


  • Client sendet DNS Abfrage für "server.mydomain.de" und erhält 1.2.3.4 als Antwort
  • Client sendet Initiales Paket an 1.2.3.4
  • OPNSense erhält das Paket und erkennt das die IP 1.2.3.4 eines ihrer Interfaces gehört.
  • Daraufhin wendet sie direkt das DNAT an, schreibt also die Zieladresse um auf 10.1.1.20, die Quelladresse bleibt gleich 10.1.1.50, und schickt das Paket an den Server im LAN.
  • Das Paket kommt am Server an und der Server schickt nun die Antwort direkt an den Absender den Client mit 10.1.1.50
  • Da die IP des Clients im selben Netz wie des Servers liegt stellt der Server das Paket direkt an den Client zu ohne den Umweg über die OPNSense. Der Client erwartet das TCP Antwort-Paket aber stattdessen von der Adresse 1.2.3.4, worauf der Client das Paket des Servers verwirft und es so zu keiner Verbindung kommt.

back-to-topPacket Flow (mit Hairpin-NAT):


  • Client sendet DNS Abfrage für "server.mydomain.de" und erhält 1.2.3.4 als Antwort
  • Client sendet Initiales Paket an 1.2.3.4
  • OPNSense erhält das Paket und erkennt das die IP 1.2.3.4 eines ihrer Interfaces gehört.
  • Daraufhin wendet sie direkt das DNAT an, schreibt also die Zieladresse um auf 10.1.1.20
  • Im SNAT schreibt sie dann die Quelladresse um auf ihre LAN-Adresse 10.1.1.1 und schickt das Paket an den Server im LAN.
  • Das Paket kommt am Server an und der Server schickt nun die Antwort wieder an die OPNSense (10.1.1.1) welche ja im Paket als Absender stand.
  • Da in der NAT-Tabelle der OPNSense ein Eintrag für die Verbindung steht schreibt sie nun die Quelladresse wieder um auf 1.2.3.4 und die Zieladresse wieder auf die des Clients 10.1.1.50 und schickt das Paket an den Client.
  • Der Client erhält die korrekte Antwort von der Absender IP 1.2.3.4 und die Verbindung ist erfolgreich.

Wenn du das nun verstanden hast (so oft lesen bis du es hast), dann weißt du nun selbst was du brauchst, genau zwei NAT Regeln :

  • Erstens wie gewohnt eine DNAT Regel für die Portweiterleitung von Extern
  • SNAT Regel die Pakete vom internen Netz als Quelle in das interne Netz als Ziel auf die Router-LAN-IP umschreibt.

Das entspricht der Variante 1 im Link
https://docs.opnsense.org/manual/how-tos/nat_reflection.html#method-1-cr ...
, also sämtliche automatic reflections abschalten und DNAT und SNAT Regel manuell anlegen und automatische Firewall Regel erstellen lassen.

Also DNAT wie gewohnt und als SNAT (Outbound NAT):

Interface: LAN
Protocol: TCP
Source Address: LAN Netzwerk
Source Port:Any
Destination Address: IP des Servers im LAN
Destination Port: 443
Translation/target: LAN Adresse der OPNSense

Hoffe es hat nun Klick gemacht 😉

🖖
Ciao.
lowbudget
lowbudget Aug 25, 2024 at 18:37:34 (UTC)
Goto Top
Hey vielen Dank. Hat direkt geklappt.

Bei Zieladresse kann man keine direkte Adresse eintragen, aber man kann "Lan Adresse" auswählen. Das hatte mich etwas verwirrt. Mit dem Translation target/port konnte ich dann gar nichts mehr anfangen. Da ich auch noch den https Port auf einen Custom-port umleite, war ich dann nachher ganz raus. Jetzt klappt’s aber. Danke für die ausführliche Anleitung. Ist doch n bisschen was anderes, als ne Fritzbox :D
StefanKittel
StefanKittel Aug 26, 2024 at 01:26:43 (UTC)
Goto Top
Moin,
Du hast es ja schon wie gewünscht gelöst.
Es gibt noch eine andere Möglichkeit: Split-DNS.

Hier bekommt der Client für seine URL, z.B. cloud.firma.de, direk die LAN IP geliefert.
Damit entfällt der "Umweg" über den Router. Dafür ist es Mehraufwand den internen DNS-Server entsprechend zu pflegen. Je nach Anzahl der User und der Anwendung, z.B. Exchange-Server, macht sich das durchaus bemerkbar.

Stefan
lowbudget
lowbudget Aug 26, 2024 at 12:01:55 (UTC)
Goto Top
moin Stefan,

danke für den zusätzlichen Hinweis. Schau ich mir auch mal an.
HansFenner
HansFenner Aug 27, 2024 at 21:49:19 (UTC)
Goto Top
Split-DNS ist m.M.n die eleganteste Lösung. Wenn man Bind9 verwendet, nennt sich das dort Views.

Ein Vorteil ist, dass man z.B. im Web-Log auch wirklich die richtige IP des internen Clients bekommt.