NAT rotiert virtual IPs

[franco]

@franco: was war denn die Überlegung dahinter, das im Automatischen Modus default zu machen (also round-robin IPs)? IMHO hat das doch im Normalfall nur Nachteile für den Anwender, denn wenn er eh schon multiple IPs auf dem WAN hat, kann man davon ausgehen, dass es kein 08/15 Standard Anschluß ist, sondern zumindest Business etc. mit kleinem Subnetz. Und dann abgehend RR die IPs in der Outbound NAT zu rotieren ist doch eher kontraproduktiv was session handling etc. angeht?

Gute Frage. Die alten automatischen Outbound-Regeln haben mehr Logik benötigt. Jetzt wird nur noch über die Interfaces agiert, z.B.:

nat on em1 inet from (em0:network) to any -> em1 port 1024:65535

Das beschriebene Rotieren macht pf dann schon automatisch für alle angeschlossenen internen Netze.

Die alten Regeln sahen expandiert so hier aus:

nat on em1 from 192.168.56.0/24 to any -> 10.0.3.15/32 port 1024:65535

Letztlich haben die automatischen Regeln einem Subset abgebildet, es ist aber vorteilhafter wenn hier zukünftig manuell geregelt wird was passieren soll mit welcher externen IP. Im Regelfall einer externen IP ändert sich natürlich nichts.

Über Sinn oder Unsinn hier darf man sich definitiv streiten im Einzelfall. Das Gesamtkonzept sieht vor aus dem NAT Rewrite schon alle Regeln der Firewall als Plugin-Basis bereitzustellen, was dann letztlich dazu führen soll die API darauf aufsetzen kann. Für diese Änderung gab es andere Workarounds, Bugs und Dead Code der gleichzeitig wegfällt und wir wissen nun auch wo unsere Limits in der Automatic-Outbound-Kategorie sind.


Grüsse
Franco

[JeGr]

> Über Sinn oder Unsinn hier darf man sich definitiv streiten im Einzelfall

Ich mag ja überhaupt nicht streiten ;) Nur stelle ich - wie so oft in Software :D - eben die Teufel's Advokaten-Frage: Will und braucht man das (im Regelfall). Wenn nicht: Warum ist es dann ein Default? Denn die Software Maxime - zumindest hat man das bei mir noch so gelehrt :P - ist ja eigentlich das Prinzip der geringsten Überraschung. Ich würde jetzt bei einer automatisch erzeugten abgehenden NAT - auch bei mehreren IPs die drauf gelegt sind als VIPs - nicht damit rechnen, dass damit plötzlich meine Outbound NAT anfängt lustig IPs durchzurotieren. Auch mit dem Sticky Bit wäre das ja nicht wirklich anders, dass mehrere Clients mehrere externe IPs hätten. Ich klebe aber im normalen Anwendungsfall ja mehrere IPs auf die Sensen, weil ich ggf. einen Service o.ä. drauf binden will, einen Service durch-NAT-ten möchte (1:1 o.ä.) oder derlei. Dass sich dann nach so einem Change plötzlich mein Outbound Verhalten ändert und meine Clients nicht mehr nur ihre normale, sondern auch noch die IP des Service mitnehmen, ist für mich vom Verständnis her eher unerwartet.

Deshalb wäre mein Ansatz: Es ist zwar toll, dass ich das machen kann (Interface Mapping), POLS und Default wäre aber für mich dass die Adresse vom WAN genommen wird und nichts anderes. Vielleicht kannst du/könnt ihr das ja als Idee/Feature Request mitnehmen und drüber diskutieren, mir ist es nur massiv aufgefallen, dass seit 18.1 ich jetzt schon insg. ein ganzes Dutzend Anfragen - hier im Forum, per PN, von Kunden - hatte, warum sich plötzlich das externe NAT so seltsam verhält. Verstanden hat es keiner. Somit scheine ich immerhin nicht so allein mit meiner Verwunderung zu sein :D

Hoffe das in Form von positiver Kritik ordentlich verpackt zu haben ;)

Grüße
Jens

[JeGr]

Kurzes Addon und deshalb extra Post:

Wie verhält sich das, wenn ich bspw. eine externe echte Adresse auf dem Interface habe (123.123.123.123) UND ich klebe als VIP noch eine private Adresse drauf, weil ich auf dem WAN bspw. ein Providermodem noch ansprechen muss? Das würde doch nach neuer Logik bedeuten, dass beim RR der IPs plötzlich mal versucht wird, statt mit einer sauberen 123er Adresse mit einer 10.0.0.1 nach draußen zu gehen (was dann scheitern wird) und ich dann Fehlersuche habe, weil seltsamerweise 40-50% der Verbindungen nach außen plötzlich scheitern?

Natürlich kann man sagen, dass in dem Fall eh schon eine eweiterte Nutzung vorliegt und dann sollte man vielleicht auch die NAT händisch konfigurieren, aber wenn es vorher alles sauber funktioniert hat und plötzlich dann schief geht, ist das eben nicht mehr POLS (Prinzip der kleinsten Überraschung), sondern ein Major "Bug", der u.a. dann bei mir von den Kunden auf den Tisch trudelt ;)
Dieses Verhalten sollte m.E. ein Upgrade nicht ändern außer es gibt ne etwas größere Errata und Doku dazu, dass jedem auch klar ist, was da passiert/passieren wird. Und selbst dann - siehe oben - sehe ich den Use Case von VIPs und Alias IPs immer noch eher bei Service IPs für Dienste / 1:1 Mapping auf Hosts etc. und könnte aus dem Stehgreif niemand benennen, der abgehend NAT round-robin nutzen würde :)

Grüße nochmal :)

[franco]

Vielleicht geht es mit "(em1:0)" wie vorher, aber ich hab das Setup leider nicht. Bin nur der Übermittler bei dem Thema...

Eine echte Problematik fällt mir aus theoretischer Netzwerksicht nicht ein, ausser dass die Erwartung dies widerlegt. Hmm, aber warum? Da fehlt mir die Wissenslücke?

Wenn du dies jüngst erlebt hast wäre auch gut zu wissen: wer macht was mit seinen multiplen virtuellen WAN IPs und wie kommen dort unterschiedliche Erwartungen zu Tage?


Danke,
Franco

[franco]

Wie verhält sich das, wenn ich bspw. eine externe echte Adresse auf dem Interface habe (123.123.123.123) UND ich klebe als VIP noch eine private Adresse drauf, weil ich auf dem WAN bspw. ein Providermodem noch ansprechen muss?

Danke, die Info hat mir gefehlt. In der Tat nicht schön. Aber damit kann ich mich kümmern. :)

[JeGr]

> Bin nur der Übermittler bei dem Thema...
Kein Problem, wie gesagt, ist nur als Feedback zu verstehen und kein Rant ;)

> Wenn du dies jüngst erlebt hast wäre auch gut zu wissen: wer macht was mit seinen multiplen virtuellen WAN IPs und wie kommen dort unterschiedliche Erwartungen zu Tage?
Die allermeisten Fälle nutzen hier /28 oder /29er Netze und haben diese aus den Gründen:
- NAT Mapping auf interne/DMZ Services - meist weil die Netze nicht geroutet wurden, sondern mit eigenem Gateway des ISP aufgelegt
- Services auf der Firewall separieren: Bspw. eigene IP für VPN Tunnel, eigene IP für Proxy o.ä.
- CARP Setups
- Loadbalancing (wobei das wieder unter Services fällt)

Ich habe schon bei ein paar größeren ISPs gearbeitet und mir wäre nirgends im Kopf, dass da jemand multiple externe IPs für abgehendes NAT RoundRobin genutzt hat. Und da waren auch Konzerne mit >1000 Mann dabei :)

> Eine echte Problematik fällt mir aus theoretischer Netzwerksicht nicht ein
Nuja die Problematik ist die, dass bei vielen Kunden durch die unterschiedlichen externen Adressen bspw. bei Shops oder IP sensitiven Anwendungen du die Sessions verlierst und Logins so durcheinander bringst oder Warenkörbe "vernichtest" :)
Andere haben das Problem dass es die WAN IP ganz gezielt nur für outbound Client Traffic vom LAN sein soll, DMZ Server wie bspw. MXe eben ihre 1:1 IP behalten sollen. Gerade bei Mail ist IP <-> DNS ja durchaus ein Thema wegen Reputation und Score sowie Blacklisting und da will man ganz sicher nicht, dass mit der IP plötzlich vielleicht ein infizierter LAN Client nach außen die IP des Mailservers auf eine Blocklist haut.
Wieder andere haben bei Diensten IP Freischaltungen hinterlegt, die meist genau auf ihre NAT Adresse konfiguriert waren.

Meiner Ansicht nach liegt das "Problem" eher bei: Das Feature ist prinzipiell fein, aber niemand den ich kenne nutzt das. Vielleicht hat jemand anderes andere Erfahrungen, aber der einzige Nutzen der mir einfallen würde wäre: "Mir gehen die IP/Port Kombinationen abgehend für NATting aus". Ich habe also mehr als 65535 Verbindungen nach draußen und die outbound NAT kann keine Zuweisung mehr machen. Das ist mir aber in 20 Jahren noch nie passiert, dass ich das gesehen habe, denn wenn die Bude so groß ist, dass die so viele Clients haben, dass das ein Thema sein _könnte_ haben die meist eh eigene VLANs für Verwaltungsbereiche, Teams o.ä. und mappen dann diese eh schon abgehend auf unterschiedliche Adressen damit man da genauer bestimmen kann, was von wo kam, oder nutzen dann einen Proxy/Cluster der dann durch Caching das wieder reduziert und bündelt.

Viele Grüße :)

[franco]

https://github.com/opnsense/core/commit/7a823c56

Warenkörbe... ok, das Argument der Anonymisierung hilft hier wohl nichts. ;)

Als Test ob dies prinzipiell einzuschränken ist wie bisher:

# opnsense-patch 7a823c56

Lokal hier läuft es, aber ich kann wie gesagt den VIP-Part nicht abdecken.

Falls das funktioniert können wir überlegen wie wir dies für 18.1.5 einsetzen. 18.1.4 ist leider schon gebaut.


Danke,
Franco

[JeGr]

> Warenkörbe... ok, das Argument der Anonymisierung hilft hier wohl nichts. ;)

Jep ;) Zumal Anonymisierung bei einem meist recht kleinen Adressraum relativ unspektakulär ist - da die Adressen meist auch per WHOIS oder zumindest auf Nachfrage dann klar zugewiesen sind :)

Ich komme zum Patch Test auch leider erst nächste Woche, heute und morgen schon zu viele Termine... :o

[franco]

Okay, danke dir schon einmal. Habe den Patch noch an ein paar anderen Stelle angebracht für Feedback. :)


Grüsse
Franco

[JeGr]

OK ich habe bei uns mal kurz eine Testumgebung aufgebaut und reingehauen:

* VM gebaut
* VM mit einzelner externer Adresse ausgestattet
* Ping nach extern auf Test-Receiver -> Ping kommt vom WAN

* Subnetz mit /29 auf die VM geroutet
* zusätzliche IP als Alias eingerichtet
* Ping nach extern vom LAN aus (damit NAT greift) -> Ping kommt RR von WAN und Alias IP

dann

* Patch eingespielt
* erstmal keine Änderung
* Bei Outbound NAT nochmal auf automatic + save gegangen, damit Regeln neu geschrieben werden
* nochmal Ping Test -> Ping kommt nur noch von WAN Adresse an

* zusätzlich mit diversen anderen IP Varianten getestet (Alias, CARP)
* bleibt konsistent nach Speichern auf vmx0:0 -> primäre WAN IP (bislang).


Also im Moment sieht es so aus, als würde es das tun, was es soll :)
Ich hatte bspw. im Testcase genau sowas, dass nur eingehende Verbindungen für eine bestimmte IP erlaubt sind (weil: ankommende HTTPS Verbindung die auf Server reingereicht wird). Die IP ist zwar extern eingehend erlaubt, auf die Sense gebunden weil hier der HAProxy die Backends verteilt, ABER: Die IP ist abgehend nicht erlaubt.
Sprich: In genau so einem Fall (IP wird mit CARP oder Alias auf der Sense definiert für eingehenden Service) beißt das alte RR Verhalten böse, denn plötzlich hat man die Hälfte der Verbindungen abgehend die nicht mehr gehen (war auch im Test so, bei einem Klick ging die Verbindung, beim nächsten nicht, wie ein Blinker :)))

[franco]

Hallo Jens,

Danke für das Testen! Ist das ein Absatz zwischen "Also im Moment sieht es so aus, als würde es das tun, was es soll" und dem folgenden Text?

Falls ja, dann würde ich ein Commit vorbereiten.  :)


Danke
Franco

[JeGr]

Ja da wurde ein Enter verschluckt. Ich kann zwar momentan nicht sagen ob es irgendwo sonst noch Seitenwirkungen gibt, aber zumindest einmal muss man manuell noch neu speichern drücken in der NAT Maske, damit die <IF> in <IF>:0 umgeschrieben werden, dann siehts aus als würde es konsistent bleiben. :)

[franco]

Ja, genau, braucht einen Firewall-Reload. Ist verpackt und das Sticky Setting wieder entfernt da es nun nichts mehr bringt:

https://github.com/opnsense/core/commit/d823cc7193

Termin für den Merge wäre 18.1.6. Kurz danach wird es auch neue Images geben (vielleicht auch 18.1.7, schwer zu sagen).


Grüsse
Franco