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.
Please also mark the comments that contributed to the solution of the article
Content-ID: 4715917339
Url: https://administrator.de/contentid/4715917339
Printed on: October 13, 2024 at 11:10 o'clock
5 Comments
Latest comment
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.
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