Frage zu NAT 1:1 vs Outbound

[trixter]

Moin,

hab da eine allgemeine Frage zu NAT (einen etwas komischen Fall)

Ein /23er privates Netz welches über einen Router (VPN) mit einem anderen Netz verbunden ist:

Lan (192.168.74.x/23) -- OPNSense -- (10.100.100.x/24) -- Router -VPN- (10.10.0.0/16)

Der Provider des Routers möchte nun, dass die Kommunikation für eine Anwendung über NAT-Adressen läuft -
also Client 192.168.75.11 auf 10.100.100.11 genattet werden soll. Also baut man ein 1:1 NAT 192.168.75.11 <> 10.100.100.11

Der übrige Traffic 192.168.74.x soll über eine NAT-Adresse laufen - also baut man ein Outbound-Nat 10.10.0.0/16 via 10.100.100.254.

Jetzt stellt sich die Frage: Stört sich das nicht gegenseitig? Geht 1:1 vor Outbound?
 

[viragomann]

Hi,

die Frage beantwortet für mich die Dokumentation auch nicht. Ich glaube, irgendwann mal gelesen zu haben, dass 1:1 Regeln hier den Vorzug haben, aber könnte mich täuschen.

Aber benötigst du überhaupt 1:1. Das heißt, gibt es Verbindungen in beide Richtungen?
Deine Angaben vermitteln mir den Eindruck, dass nur Verbindungen von deiner auf die Remoteseite nötig sind. Das ginge mit eine normalen Outbound NAT Regel auch, und diese kannst du in der Reihenfolge ordnen.

Wenn doch auch eingehende Verbindungen nötig sind, kannst du die 1:1 Regel auch in eine Protforwarding- und eine Outbound-NAT-Regel zerlegen. Dann kannst du die Outbound Regel für die einzelne IP auch wieder höher priorisieren.

Grüße

[Monviech (Cedrik)]

1:1 kommt vor dnat und snat und macht beides gleichzeitig für die matchende Regel.

Wenn danach eine weniger selektive snat Regel kommt sollte die nur Pakete matchen die noch nicht durch 1:1 NAT bearbeitet wurden.

Was interessant ist, man kann 1:1 NAT, Port Forward und Outbound NAT miteinander konfigurieren, um manuell NAT Reflection/Hairpin zu erzeugen ohne Automatische Regeln.

https://forum.opnsense.org/index.php?topic=36326

https://docs.opnsense.org/manual/how-tos/nat_reflection.html#one-to-one-nat-reflection

[trixter]

irgendwann mal gelesen zu haben, dass 1:1 Regeln hier den Vorzug haben ...

Genau so hab ich das bei einem anderen Hersteller auch gelernt - jedoch scheint die Sense die 1:1 Regeln zu ignorieren ?? ...

Habe das jetzt alles in Outbound gepackt - das wird ja schon Top-Down abgearbeitet.
Das ist eigentlich auch verständlicher - wird bloß etwas voll.

Manchmal fragt man sich, ob man einfach in die falsche Richtung läuf.

Danke fürs Mitdenken ;)

[trixter]

1:1 kommt vor dnat und snat und macht beides gleichzeitig für die matchende Regel.

Wenn danach eine weniger selektive snat Regel kommt sollte die nur Pakete matchen die noch nicht durch 1:1 NAT bearbeitet wurden.

Was interessant ist, man kann 1:1 NAT, Port Forward und Outbound NAT miteinander konfigurieren, um manuell NAT Reflection/Hairpin zu erzeugen ohne Automatische Regeln.

https://forum.opnsense.org/index.php?topic=36326

https://docs.opnsense.org/manual/how-tos/nat_reflection.html#one-to-one-nat-reflection

Das klingt sehr spannend, aktuell macht mir das "normale" NAT via Outbound genug Probleme:

Szenario Adresse A soll gegen B getauscht werden, wenn das B-Netz erreicht werden soll - also 1:1 NAT in Outbound vor allen anderen Regeln.
Outbound steht auf Hybrid - wegen des Rück-Traffics.

Aktuell sieht es so aus, als ob der Traffic zwar von einer Seite durch geht also die Adresse A wird gegen B bei Passieren des Interfaces getauscht, ABER:
Der Traffic für den Rückweg funktioniert nicht.
Im Capture ist ein Arp Request zu sehen, welches nicht beantwortet wird - müsste da nicht die Sense stellvertretend mit Ihrer MAC antworten?
Ich kann mich dunkel erinnern, dass es bei der PF eine Checkbox "Proxy-Arp" gab, kann aber nichts in der Richtung finden.

[JeGr]

Genau so hab ich das bei einem anderen Hersteller auch gelernt - jedoch scheint die Sense die 1:1 Regeln zu ignorieren ?? ...

Nö tut sie nicht :) Das wird schon ordentlich gemacht. Aber eben nur für die eine Adresse, die angegeben ist - oder für den entsprechenden Subnetzblock im Spezialfall.

Szenario Adresse A soll gegen B getauscht werden, wenn das B-Netz erreicht werden soll - also 1:1 NAT in Outbound vor allen anderen Regeln.
Outbound steht auf Hybrid - wegen des Rück-Traffics.

Was ein ganz klassischer Outbound Fall ist, es sei denn du machst das für eine Netz-auf-Netz Umsetzung die ggf. noch auf beiden Seiten stattfindet, dann wäre das ein 1:1 Job. Sehe da jetzt aber erstmal nichts, was 1:1 ruft, daher Outbound völlig korrekt.

ABER:
Der Traffic für den Rückweg funktioniert nicht.

Das ist dann aber Job der anderen Seite? Wenn der Traffic rausgeht und dabei umgeschrieben wird - was man im tcpdump sehen kann bzw. man einfach auf der Remote Seite dann sehen können sollte - ist das kein Fehler der Sense. Meist klemmts dann eher eingehend auf der anderen Seite, weil man dort nicht mit der Adresse B sondern den Adressen A gerechnet/konfiguriert hatte.

Im Capture ist ein Arp Request zu sehen, welches nicht beantwortet wird - müsste da nicht die Sense stellvertretend mit Ihrer MAC antworten?

Wenn es kein ARP von ihr ist - nein warum? Das hat ja nichts mit NAT oder nicht NAT zu tun. Das klingt jetzt tatsächlich wieder eher nach dem vermuteten Fall von weiter oben, dass auf beiden Seiten 1:1 ein ganzes Netz geNATtet wird? Vielleicht wäre es da einfacher, wenn du das Szenario genauer erklärst, dann kann man besser helfen :)
Es erinnert ein wenig an https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-binat.html

Ich kann mich dunkel erinnern, dass es bei der PF eine Checkbox "Proxy-Arp" gab, kann aber nichts in der Richtung finden.

Proxy ARP gabs/gibts an den normalen Stellen eigentlich nur bei Virtual IPs, nicht bei NAT. Oder vermixt du das vllt mit dem Port Forward (NAT+Proxy)? Das wäre dann wieder was ganz anderes :)

Ich bin eigentlich die Fraktion "NAT auf manuell" zu stellen. Bei OPNsense radiert das leider die ganzen default Regeln erstmal aus (bei PF wurden sie kopiert), daher Vorsicht damit. Aber wenn man erstmal den Default (ggf. mit ein zwei Aliasen) nachbaut und damit vereinfacht, dann wird es meist auch einfacher, solche NAT Szenarien hinzubekommen.



Cheers

[trixter]

wenn du das Szenario genauer erklärst, dann kann man besser helfen :)

ich versuchs mal zu erklären :

User-Netz > OpnSense > Transfer-Netz > VPN-Router > Dienstleister (Serverfarm)

Man hat sich mit dem Dienstleister darauf geeinigt Server des Dienstleisters zu erreichen, indem man teils 1:1 User-Adressen auf Transfer-Netz-Adressen NATet, um damit bestimmte Server zu erreichen. Für einige Dienste braucht es jedoch keine eindeutige Zuordnung (1:N-Nat).
1-N funktioniert, 1:1 macht Probleme.

Bisher hat das eine andere Software erledigt, die auf Grund ihres Alters (der Kollege der dies betreute ist nicht mehr), gegen eine OpnSense getauscht werden soll.

[JeGr]

ich versuchs mal zu erklären :

User-Netz > OpnSense > Transfer-Netz > VPN-Router > Dienstleister (Serverfarm)

Man hat sich mit dem Dienstleister darauf geeinigt Server des Dienstleisters zu erreichen, indem man teils 1:1 User-Adressen auf Transfer-Netz-Adressen NATet, um damit bestimmte Server zu erreichen. Für einige Dienste braucht es jedoch keine eindeutige Zuordnung (1:N-Nat).
1-N funktioniert, 1:1 macht Probleme.

OK und was dabei funktioniert nicht und welche Regel soll die Sense ignorieren? Das liest sich eher nach entweder der VPN Router mit falschen Einstellungen zum Transfernetz oder falschem Mapping auf der OPNsense aber ignoriert wird nichts. Ich tippe eher auf falsches Mapping und Mißverständnis, was wo wie hin soll?

Cheers

[trixter]

Sorry für die späte Rückmeldung,
habe nochmals mit dem Kollegen auf der anderen Seite reden wollen, bevor Missverständnisse aufkommen.
Der Kollege auf der anderen Seite sagte er sähe zwar die Packete kommen, die MAC-Adressen jedoch würde sein L3 Switch nicht lernen, die blieben bei "incomplete"
Im Capture sehe ich die Packete jedoch mit der Adresse vom physikalischen Interface von der Primären Sense raus gehen.
Habe daraufhin mal ins Proxmox geschaut, dort sehe ich auch "nur" die physikalischen Adressen und die CARP-Interfaces.
Bin bisher davon ausgegangen, dass Adressen die ich im 1:1 NAT eintrage, auch via Arp übermittelt werden (Arp-Proxy)- dem scheint nicht so zu sein.
Daher habe ich die 1:1 Nat-Adressen jetzt ebenfalls bei Carp mit eingetragen, damit sie mit dem Cluster wandern.

Jedenfalls sieht man die NAT-IPs jetzt auch im Proxmox mit der MAC vom physikalischen Inteface, ebenso meldet dies auch der Kollege auf der anderen Seite, die Arp-Tabelle wäre jetzt okay.

[Patrick M. Hausen]

Bin bisher davon ausgegangen, dass Adressen die ich im 1:1 NAT eintrage, auch via Arp übermittelt werden (Arp-Proxy)- dem scheint nicht so zu sein.

Richtig. NAT ist nur Layer 3. Proxy-ARP ist böse, will man normalerweise nicht.

[trixter]

Richtig. NAT ist nur Layer 3. Proxy-ARP ist böse, will man normalerweise nicht.

Die Anleitungen sind echt gut, daher wäre gut, wenn jemand vielleicht einen Vermerk mit aufnimmt, wie .... Damit das sauber funktioniert muss die betroffene IP noch als Virtuelle IP eingetragen werden .... oder so ähnlich.

Bin da nicht der einzige, der in diese Falle tappt.

[viragomann]

NAT passiert eben nicht auf Layer 2. Das ist Netzwerkstandard und die Kenntnis darüber sollte Voraussetzung sein, wenn man mit OPNsense startet.
So steht es auch in den Docs > Introductions.

NAT Regeln würden in deinem Fall aber auch ausreichen, wenn die IP auf deine geroutet werden würde.

[trixter]

NAT passiert eben nicht auf Layer 2. Das ist Netzwerkstandard und die Kenntnis darüber sollte Voraussetzung sein, wenn man mit OPNsense startet.
So steht es auch in den Docs > Introductions.

NAT Regeln würden in deinem Fall aber auch ausreichen, wenn die IP auf deine geroutet werden würde.

Komisch dass bei anderen Herstellen wie Sophos oder Cisco ein Eintrag ausreicht?
Oder willst Du mir erzählen, dass die dort alle keine Netzwerkstandards kennen?

Manche Software bedient sich halt wie eine Behörde, wo man alles doppelt und dreifach braucht, damit man eine Chance bekommt sich selbst zu widersprechen.

[viragomann]

Ja, es gibt auch Router, die der Hersteller auch "Firewall" bezeichnet, die machen zum Beispiel automatisch mit einer Weiterleitung auf eine interne IP ein Masquerading auf ihre LAN IP (S-NAT).
Damit umgeht der Router Sicherheitsmechanismen auf dem Zielgerät. Das Zielgerät vertraut dem Paket dann, weil der Zugriff vermeintlich aus dem internen Netzwerk kommt. Die Funktion lässt sich zwar abschalten, ist aber von Haus aus aktiv.
Das freut den Laien, weil der Zugriff auf seinen Server von außen auf Anhieb funktioniert.

In meinen Augen ist das kein geringes Sicherheitsrisiko, über das man klar informieren sollte.
Sichere Firewall gehen da anders. Da lässt sich das auch einrichten, ist aber nicht von vorne weg so.

Und zu diesem Fall: NAT ist nicht gleichzeitig ARP, auch wenn du es gerne so haben würdest.
Nicht immer, wenn man eine Weiterleitung braucht,  will man gleichzeitig die ursprüngliche Ziel-IP auch dem Router zugeordnet haben. Wofür auch??
Das sind verschiedene Dinge für unterschiedliche Anwendungsfälle.

Warum das andere namhafte Hersteller so machen, wär mir rätselhaft.