OPNsense Forum
International Forums => German - Deutsch => Topic started by: almo on March 05, 2020, 04:20:57 pm
-
Hallo Zusammen,
ich habe wieder mal eine Frage oder ein Problem. Ich habe ein Netz 192.168.112.0/24 für diese Netz ist meine FW DHCP; DNS und Gateway. Die FW sitzt aber mit einer anderen Nic in einem alten bestehend Netzwerk 10.100.0.0/24. In diesem alten Netzwerk sind noch alte Server und für dieses Netzwerk gibt es noch eine alte FW die dort Gateway ist.
Die neue FW hat eine Route um vom 192.168.112.0/24 Netz Richtung dem alten Netz zu gehen und es gibt auch eine Regel die das erlaubt. Nur folgendes Problem.
Ein Server X mit der 192.168.112.68 möchte mit dem Server 10.100.0.12 reden. Eine Regel erlaubt das auch. Das Paket geht an die FW und fällt bei der FW bei der NIC für das Netzwerk 10.100.0.0 raus. Dort hat die FW die IP 10.100.0.240. Der FW möchte dem 112.68 Antworten daher schickt er das Paket an das Gateway für das 10.100.0.0/24 Netz dieses ist dort die .254. Das Gateway kennt den weg zum 192.168.112.0-Netz als Route über den Hop 10.100.0.240. Leider drückt die alte FW Ihre IP als Absender in das Paket. Die OPNSense ignoriert das Paket weil es nicht vom 10.100.0.12 stammt.
Frage:
Ich würde gerne eine NAT bauen was dafür sorgt das wenn ein Paket vom 192.168.112.0-Netz richtung 10.100.0.0 geht der Absender aus dem 192.168.112.0 Netz durch die 10.100.0.240 ersetzt wird. Dann würde der Antwortend Server nicht das alte Gateway befragen sondern direkt das Paket zusenden und die OPNSense dann zurück ein NAT richtung 192.168.112.0 Urheber machen?!
Meine ersten Versuchen haben alle nicht funktioniert. Klar könnte ich natürlich bei dem Server auch Lokal eine Route setzen damit die Antwort gleich richtig läuft, aber in diesem Fall habe ich keine Option eine Route zu setzen.
Ich hoffe Ihr könnt mir folgen und mir irgendwie weiterhelfen.
-
Kann ich das über ein Ausgehendes NAT realisieren?
Schnittstelle: OPT2
IPv4: Any
Port: Any
Quelle: 192.168.112.68 (OPT2-Netz)
Quellport: Any
Zieladresse: 10.100.0.12 (OPT1-Netz)
Zielport: Any
Übersetzungsadresse: OPT1-Adresse
Damit müsste doch das Paket aus OPT2 auf dem weg richtung OPT1 die Schnittstellen-Adresse von OPT1 bekommen und der Server im OPT1 müsste ja seine Antwort an die Schnittstellen-Adresse schicken und damit müsste es ja wieder auch zurück gehen zum Anfragend Server aus OPT2 und damit der Kreis in der Netzwerkkomunnikation geschlossen sein.
-
Möglicherweise habe ich Dich missverstanden, deshalb frage ich mal nach, kannst Du nicht auf der alten FW eine Route konfigurieren die in das neue Netz zeigt, diese Route darf von der alten FW natürlich nicht genattet werden.
Wenn ich das richtig verstehe ist der Ablauf doch so
Datenpaket kommt aus dem neuen Netz zum Server im alten Netz
Der Server im alten Netz will antworten kennt aber das neue Netz nicht, also antwortet er an sein default GW
Das default GW schickt die Daten wiederum über sein Standargateway und führt dabei ein NAT durch
Falls das oben beschrieben zutrifft gibt es 2 Lösungsansätze
1. eine Route auf der alten FW, das würde bewirken daß der alte Server einen ICMP redirect bekommt und damit die neue Route kennt.
2. Falls die Server ihre Route/default GW per dhcp bekommen dann über den dhcp Server eine entsprechende Route verteilen
Falls die IP auf dem Server statisch konfiguriert ist dort die zusätzliche Route eintragen.
-
Fast richtig,
die alte FW hat eine Route zu dem neuen Netz über die neue FW. Mein Problem an der Sache ist folgendes. Server vom neuen Netz baut die Verbindung auf über die neue FW ins alte Netz der Server will antworten das Paket landet bei der FW. Diese kennt die Route und leitet das Paket an die neue FW. Doch die neue FW verwirft das Paket weil es als Absender die IP der alten FW hat. Die FW wartet ja auf ein Paket vom Server.
Durch das weiter reichen an der alten FW wird die Quelle geändert und damit darf es bei der Türe für die Antwort ins neue Netz nicht rein. Weil der Türsteher sagt moment da stimmt was nicht.
Konntest du mir jetzt folgen ?
-
Mir erschliesst sich irgendwie nicht warum Du das überhaupt NATen möchtest, das ist doch eine reine Routingaufgabe.
Die neue Firewall kennt das alte Netzt und die neuen Server benutzen die neue FW als default GW. Somit kommt das Datenpaket am alten Server an. Der alte Server antwortet an sein default GW oder an ein Gateway das für die Route zuständig ist, in diesem Fall wohl die alte FW, diw sendet dem alten Server ein redirect auf die neue Firewall und von da geht es weiter auf den neuen Server. Warum das NAT?
-
Warum das NAT?
Weil die alte Firewall so dumm ist und beim Empfang des Pakets und weiterleitung an die neue Firewall die Quelladresse durch Ihre IP Adresse ersetzt. Und damit die neue Firewall die Antwort zwar bekommt aber bei der Quelle die falsche IP Adresse drin stehen hat und es Dropt weil die Firewall ja auf eine Antwort von 10.100.0.12 wartet. Das Paket aber durch das "next-hope" von der alten FW an der stelle eben nicht mehr Quell IP 10.100.0.12 drin stehen hat sondern 10.100.0.254.
Versteht jetzt irgendwer mein Problem was ich versuche zu lösen mit NAT? Ich hab mir jetzt in der VM im anderen netz mit einem zweiten Adapter auf die schnelle beholfen aber das Problem habe ich bei allen weiteren Imigrationen auch noch so lange bis die alte FW kompeltt abgelerrt ist. Verzweilfung pur ...
-
Kenne das Ausmaß der Infrastruktur ja nicht, aber wäre es nicht eventuell einfacher auf den Servern im alten Netz manuell einen Routing Eintrag anzulegen?
-
Bekommen die alten Server ihre IP auch per DHCP, dann könntest Du über den DHCP-Server ja auch eine Route an die Server verteilen.
Oder Du trägst auf der alten FW eine Route in das neue Netz ein, dann sollten die alten Server einen icmp-redirect bekommen.
Was spricht dagegen das NAT auf der alten FW abzuschalten?
-
Kenne das Ausmaß der Infrastruktur ja nicht, aber wäre es nicht eventuell einfacher auf den Servern im alten Netz manuell einen Routing Eintrag anzulegen?
Geht bei der virtualisierungs Umgebung leider nicht so einfach, da ich diese global am Virtualisierungsgeber setzen müsste und damit auch 100 andere Maschinen treffe die das Netz vorher nicht erriechen sollen (Vorgabe)
Den der Server aus dem anderen Netz spricht direkt mit dem Virtualisierungsserver und teilt Ihm mit welche VM er Abholen möchte und transferieren will. Also müsste ich die Route auf unterster Ebene setzen.
----
Bekommen die alten Server ihre IP auch per DHCP, dann könntest Du über den DHCP-Server ja auch eine Route an die Server verteilen.
Oder Du trägst auf der alten FW eine Route in das neue Netz ein, dann sollten die alten Server einen icmp-redirect bekommen.
Was spricht dagegen das NAT auf der alten FW abzuschalten?
DHCP leider nein. In der alten FW (Junipier) ist eine Static Router für das Netz gesetzt mit 192.168.112.0/24 next-hope 10.100.0.240. Das NAT an der alten FW habe ich schon mal deaktiviert was einen Stillstand von intern nach extern oder auch andersrum zur folge hatte.
Ich hatte ja auch schon die Idee ein Transfernetz zwischen der alten FW und der neuen FW zu spannen. Aber ich habe an der alten FW kein freien Port mehr. Und ein neues Modul für eine EoL Gerät werde ich nicht kaufen da es auch schwer zu bekommen ist und exterm mit Aufpreis verkauft wird selbst gebraucht.
-
Na ja, wenn Du das NAT abstellst musst Du per Regel den ausgehenden Verkehr erlauben, d.h. es wird eine Regel benötigt die das erlaubt.