7
OPNsense Routing - NAT Problem
Hallo
Ich hab das Problem das ich zwei getrennte Netzwerkinstallation habe und nun dazwischen mittels "Routing" Subnet eine Verbindung für den Zugriff auf ein Gerät einrichten muss.
Wichtig, es ist kein VPN sondern ein physischer Ethernet Link zwischen zwei OPNsense und dieser muss so bleiben.
Im Anhang ein einfaches Schema des Aufbau's, der wie folgt aussieht:
Netzwerk A: (mit dem Gerät "Web Server")
WAN: 1.1.1.1
LAN: 192.168.200.0/24
Routing Netz: 192.168.10.0/24
Gerät "Web Server": 192.168.200.20
OPNsense A:
WAN: 1.1.1.1
LAN: 192.168.200.1
Routing: 192.168.10.254 mit GW 192.168.10.1
Netzwerk B: (mit dem Client)
WAN: 2.2.2.2
LAN: 192.168.20.0/24
Routing Netz: 192.168.10.0/24
Client: via DHCP im Bereich 192.168.20.0/24
OPNsense B:
WAN: 2.2.2.2
LAN: 192.168.20.1
Routing: 192.168.10.1 ohne GW
Der Zugriff übers WAN erfolgt pro Firewall über den eigenen Anschluss.
Ich hab nur zwei Anforderungen, welche nicht korrekt funktionieren:
- Gerät "Web Server" muss über das WAN von OPNsense A errerichbar sein
- Gerät "Web Server" muss über DNAT via Routing IP 192.168.10.1 und PNAT (Bsp. 22222 -> 8081) erreichbar sein
Am Ende sollte der Client zB https://192.168.10.254:22222 eingeben und erhält dann die Ausgabe des Web Servers, eigentlich simpel.
Siehe:
Die Routing Verbindung dazwischen funktioniert, da ich von beiden LAN Subnet aus via Ping oder Web Gui über die jeweilige Routing Interface IP Zugreifen kann.
Ebenfalls funktioniert ein Traceroute ins dahinter gelegene Subnet bis zum Routing Interface der Gegenseite, weiter komme ich logischerweise nicht ohne entsprechende Freigaben.
Daher schliesse ich ein Fehler in der Routing Konfiguriation aus.
Damit ich von A nach B und umgekehrt komme, muss ich auf der OPNsense A das Outbound NAT auf Manuell stellen und habe dort die Einträge gemäss Anhang "Outbound NAT A" erstellt.
Wenn ich das Outbound NAT auf Seite A auf automatisch stelle, funktioniert der Zugriff über das WAN A auf das Gerät "Web Server", dabei habe ich dann aber nicht mehr auf die gegenseitige Routing IP Zugriff.
Wenn ich das Outbound NAT auf Seite A auf Manuelle gemäss Anhang stelle, funktioniert der Zugriff übers WAN A nicht mehr, jedoch kann ich dann die gegenseitige Routing IP wieder erreichen.
Sowohl auf OPNsense A auch B sind im LAN und Routing Netz eine Any to Any Rule hinterlegt.
Irgendwas mache ich falsch, nur finde ich den Fehler nicht.
Wer kann mir einen Tipp geben?
Im Anhang sind noch diverse Screenshots von der Firewall A, weitere kann ich gerne machen.
Gruss Philippe
Ich hab das Problem das ich zwei getrennte Netzwerkinstallation habe und nun dazwischen mittels "Routing" Subnet eine Verbindung für den Zugriff auf ein Gerät einrichten muss.
Wichtig, es ist kein VPN sondern ein physischer Ethernet Link zwischen zwei OPNsense und dieser muss so bleiben.
Im Anhang ein einfaches Schema des Aufbau's, der wie folgt aussieht:
Netzwerk A: (mit dem Gerät "Web Server")
WAN: 1.1.1.1
LAN: 192.168.200.0/24
Routing Netz: 192.168.10.0/24
Gerät "Web Server": 192.168.200.20
OPNsense A:
WAN: 1.1.1.1
LAN: 192.168.200.1
Routing: 192.168.10.254 mit GW 192.168.10.1
Netzwerk B: (mit dem Client)
WAN: 2.2.2.2
LAN: 192.168.20.0/24
Routing Netz: 192.168.10.0/24
Client: via DHCP im Bereich 192.168.20.0/24
OPNsense B:
WAN: 2.2.2.2
LAN: 192.168.20.1
Routing: 192.168.10.1 ohne GW
Der Zugriff übers WAN erfolgt pro Firewall über den eigenen Anschluss.
Ich hab nur zwei Anforderungen, welche nicht korrekt funktionieren:
- Gerät "Web Server" muss über das WAN von OPNsense A errerichbar sein
- Gerät "Web Server" muss über DNAT via Routing IP 192.168.10.1 und PNAT (Bsp. 22222 -> 8081) erreichbar sein
Am Ende sollte der Client zB https://192.168.10.254:22222 eingeben und erhält dann die Ausgabe des Web Servers, eigentlich simpel.
Siehe:
Die Routing Verbindung dazwischen funktioniert, da ich von beiden LAN Subnet aus via Ping oder Web Gui über die jeweilige Routing Interface IP Zugreifen kann.
Ebenfalls funktioniert ein Traceroute ins dahinter gelegene Subnet bis zum Routing Interface der Gegenseite, weiter komme ich logischerweise nicht ohne entsprechende Freigaben.
Daher schliesse ich ein Fehler in der Routing Konfiguriation aus.
Damit ich von A nach B und umgekehrt komme, muss ich auf der OPNsense A das Outbound NAT auf Manuell stellen und habe dort die Einträge gemäss Anhang "Outbound NAT A" erstellt.
Wenn ich das Outbound NAT auf Seite A auf automatisch stelle, funktioniert der Zugriff über das WAN A auf das Gerät "Web Server", dabei habe ich dann aber nicht mehr auf die gegenseitige Routing IP Zugriff.
Wenn ich das Outbound NAT auf Seite A auf Manuelle gemäss Anhang stelle, funktioniert der Zugriff übers WAN A nicht mehr, jedoch kann ich dann die gegenseitige Routing IP wieder erreichen.
Sowohl auf OPNsense A auch B sind im LAN und Routing Netz eine Any to Any Rule hinterlegt.
Irgendwas mache ich falsch, nur finde ich den Fehler nicht.
Wer kann mir einen Tipp geben?
Im Anhang sind noch diverse Screenshots von der Firewall A, weitere kann ich gerne machen.
Gruss Philippe
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: 551232
Url: https://administrator.de/forum/opnsense-routing-nat-problem-551232.html
Ausgedruckt am: 23.12.2024 um 23:12 Uhr
7 Kommentare
Neuester Kommentar
Moin,
wieso Nattest du zwischen den beiden Netzen ? Sehe hier den Sinn nicht, ausser dass Du die Sache unnötig verkomplizierst.
Mit den Hintergrundinfos kann man Dir bestimmt besser helfen.
Henere
wieso Nattest du zwischen den beiden Netzen ? Sehe hier den Sinn nicht, ausser dass Du die Sache unnötig verkomplizierst.
Mit den Hintergrundinfos kann man Dir bestimmt besser helfen.
Henere
Genau das habe ich auch nicht verstanden.... Aus welchem Grund wird über die lokale .10.0er Verbindung geNATet ? Das ist doch irgendwie sinnfrei zumal die IP Adressen ja eindeutig sind und es lokal damit keinerlei Grund für ein NAT gibt ?!
Hallo
Mir erschliesst sich der Sinn des NAT auch nicht. Du hast ja ein Transit Netz. Einfach das Netzsegment welches du möchtest über das Transit Netz routen + Rückroute auf der Gegenseite setzen. Per Firewall kannst du nachher definieren welche Ports etc. du zulassen möchtest.
Somit wäre das ganze schon abgehandelt.
Gruss
adminst
Mir erschliesst sich der Sinn des NAT auch nicht. Du hast ja ein Transit Netz. Einfach das Netzsegment welches du möchtest über das Transit Netz routen + Rückroute auf der Gegenseite setzen. Per Firewall kannst du nachher definieren welche Ports etc. du zulassen möchtest.
Somit wäre das ganze schon abgehandelt.
Gruss
adminst
Danke für eure Kommentare.
Leider kann ich an der Vorgabe eines NAT's nichts ändern, da im Kundennetz die Firewall B von einer staatlichen Organisation verwaltet wird. Der Zugriff wird nur exakt auf meine Interface IP gewährt.
Beim Kunden habe ich das gleiche Problem, weswegen ich es selbst mit zwei OPNsense nachgebaut habe und daher euch so Frage.
Mir ist weiterhin nicht klar wieso das verändern des Outbound NAT nur immer die eine Seite zulässt.
Gruss Philippe
Leider kann ich an der Vorgabe eines NAT's nichts ändern, da im Kundennetz die Firewall B von einer staatlichen Organisation verwaltet wird. Der Zugriff wird nur exakt auf meine Interface IP gewährt.
Beim Kunden habe ich das gleiche Problem, weswegen ich es selbst mit zwei OPNsense nachgebaut habe und daher euch so Frage.
Mir ist weiterhin nicht klar wieso das verändern des Outbound NAT nur immer die eine Seite zulässt.
Gruss Philippe
Irgendwie machst du hier einen Denkfehler !
Du schreibst z.B. "Am Ende sollte der Client zB https:/ /192.168.10.254:22222 eingeben und erhält dann die Ausgabe des Web Servers, "
Das kann so nicht klappen.
Wenn man das etwas kranke Konstrukt richtig versteht dann haben wir folgende Fakten:
Damit ist die Zielangabe oben dann Unsinn, denn "192.168.10.254:22222" würde ja einzig nur einen Host erreichen der im Koppelnetz .10.0 steht. Dort ist der Webserver aber gar nicht !! Gar kein Endgerät befindet sich hier.
Logischerweise muss dann also vom Client aus dem lokalen Site A-LAN (.20.0) dann immer die wirkliche Zieladresse des Webservers eingegeben werden nämlich .200.20.
Das wird dann über das Koppelnetz .10.0 geroutet und bekommt dann mit dem Outbound NAT an FW A eine Absender IP 192.168.10.1. Gaukelt der Firewall B damit also wegen ihres o.g. strikten Regelwerkes auf nur diese IP einen Absender im 10.0er Netz vor.
Die Firewall B erhält dann dieses Paket mit Zieladresse 192.168.200.20 und Absender IP 192.168.10.1, was ja dann auch ihr striktes, staatliches Regelwerk passieren kann, da dies ja laut TO rein nur Traffic von der Absender IP .10.1 zulässt. Soweit so gut....
Firewall B routet das Paket dann zum Webserver weiter und gut ist.
In sofern stimmen also oben schonmal die Webserver Zieladresse aus dem Client Netz A gar nicht.
Auch das LAN Regelwerk ist sinnfrei. Oben wir alles ins 10er und 20er explizit zugelassen und dadrunter wird dann so oder so alles durchgelassen. Dann hätte man sich die Regeln oben auch gleich sparen können, denn sie sind vollkommen überflüssig.
Viele Dinge passen da also irgendwie nicht zusammen....?!
Du schreibst z.B. "Am Ende sollte der Client zB https:/ /192.168.10.254:22222 eingeben und erhält dann die Ausgabe des Web Servers, "
Das kann so nicht klappen.
Wenn man das etwas kranke Konstrukt richtig versteht dann haben wir folgende Fakten:
- 1.) OPNsense A ist die rechte FW (2.2.2.2 WAN Adresse, leider fehlt die Beschreibung was A und B ist
) - 2.) OPNsense B nimmt über eine entsprechende Regel rein nur Traffic von der IP 192.18.10.1 an.
- 3.) Daraus (Punkt 2.) folgt dann im Umkehrschluss das FW B dann ein Outbound NAT machen muss an diesem Port für Traffic mit der Absender IP 192.168.20.x und Ziel IP 192.168.200.x oder präziser: nur die .200.20 wenn rein nur der Web Server erreicht werden soll.
Damit ist die Zielangabe oben dann Unsinn, denn "192.168.10.254:22222" würde ja einzig nur einen Host erreichen der im Koppelnetz .10.0 steht. Dort ist der Webserver aber gar nicht !! Gar kein Endgerät befindet sich hier.
Logischerweise muss dann also vom Client aus dem lokalen Site A-LAN (.20.0) dann immer die wirkliche Zieladresse des Webservers eingegeben werden nämlich .200.20.
Das wird dann über das Koppelnetz .10.0 geroutet und bekommt dann mit dem Outbound NAT an FW A eine Absender IP 192.168.10.1. Gaukelt der Firewall B damit also wegen ihres o.g. strikten Regelwerkes auf nur diese IP einen Absender im 10.0er Netz vor.
Die Firewall B erhält dann dieses Paket mit Zieladresse 192.168.200.20 und Absender IP 192.168.10.1, was ja dann auch ihr striktes, staatliches Regelwerk passieren kann, da dies ja laut TO rein nur Traffic von der Absender IP .10.1 zulässt. Soweit so gut....
Firewall B routet das Paket dann zum Webserver weiter und gut ist.
In sofern stimmen also oben schonmal die Webserver Zieladresse aus dem Client Netz A gar nicht.
Auch das LAN Regelwerk ist sinnfrei. Oben wir alles ins 10er und 20er explizit zugelassen und dadrunter wird dann so oder so alles durchgelassen. Dann hätte man sich die Regeln oben auch gleich sparen können, denn sie sind vollkommen überflüssig.
Viele Dinge passen da also irgendwie nicht zusammen....?!
Hallo aqui
Die Firewall A ist links und B rechts.
Ich konnte mittlerweile das Problem lösen.
Aus irgendeinem Grund hat mir der Proxy auf Seite A dazwischen gefummelt.
Ich habe die Konfiguration auf einer Fabrikneuen OPNsense nochmals aufgebaut und nun funktioniert es einwandfrei.
Sowohl über das WAN als auch über das DNAT vom Routing Interface.
Damit kann der Therad geschlossen werden.
Die Firewall A ist links und B rechts.
Ich konnte mittlerweile das Problem lösen.
Aus irgendeinem Grund hat mir der Proxy auf Seite A dazwischen gefummelt.
Ich habe die Konfiguration auf einer Fabrikneuen OPNsense nochmals aufgebaut und nun funktioniert es einwandfrei.
Sowohl über das WAN als auch über das DNAT vom Routing Interface.
Damit kann der Therad geschlossen werden.
Damit kann der Therad geschlossen werden.
Das solltest dann bitte DU selber machen !!Wie kann ich einen Beitrag als gelöst markieren?
FAQs lesen und verstehen hilft wie immer !!
