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