5
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.
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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4715917339
Url: https://administrator.de/forum/opnsense-hairpin-reflection-nat-funktioniert-nicht-4715917339.html
Ausgedruckt am: 25.12.2024 um 02:12 Uhr
5 Kommentare
Neuester Kommentar
Buonasera.
👍. Das ist gut so und der allererste Schritt vor allen anderen!
Gegeben sei das folgende Beispiel fürs Verständnis:
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 :
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.
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:
Test-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
Packet 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.
Packet 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.
3
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
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
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
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
moin Stefan,
danke für den zusätzlichen Hinweis. Schau ich mir auch mal an.
danke für den zusätzlichen Hinweis. Schau ich mir auch mal an.
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.
Ein Vorteil ist, dass man z.B. im Web-Log auch wirklich die richtige IP des internen Clients bekommt.
