OPNsense Forum
International Forums => German - Deutsch => Topic started by: schnauz on February 26, 2018, 11:34:33 am
-
Hi zusammen
18.1.2 auf guter Hardware. Standard config /WAN/DMZ/LAN) mit Portforwarding und OpenVPN, gemäss Anleitung.
Ich habe ein 8er Subnetz Beispielnetz 123.123.123.210/29 . 1 IP auf WAN gelegt und 3 als Virtual IPs (IP Alias). LAN normales DHCP, alles Standard. Mit Auto Rules Out.
Wenn ich nun ausm LAN in der Welt herumsurfe, wechselt die Absender IP (WAN) ständig. OPNSense verwendet rotierend alle vier IPs, die als WAN und die als Virtual IPs zugewiesen sind und zwar je Session. Dh. ein zugriff auf einen IP basierte ACL- Ressource funktioniert nur dann, wenn grad die richtig IP genutzt wird. Ich habe keine Idee, wie ich nur immer die WAN IP nutzen kann (ausser ich lösche die IP Aliases). Für Hinweise wäre ich froh.
Aufbau:
WAN / Internet
:
: Provider
:
.-----+-----.
| Gateway | (Bridge)
'-----+-----'
|
WAN | 123.123.123.210/29 WAN, Virtual IPs (211 212 213)
|
.-----+------. private DMZ .------------.
| OPNsense +--------------------+ DMZ-Server |
'-----+------' 192.168.222.0/24 '------------'
|
LAN | 192.168.57.0/24
|
-
Hallo,
vom Bauch raus würde ich sagen, dass sollte über Firewall > Rules > Floating einzustellen sein.
Einfach hinterlegen, welche Dienste (z.B. HTTP/HTTPS) über welche IP-Adresse rausgehen sollen.
-
Nein, Floating Regeln haben damit nichts zu tun. Das kann im Gegenteil eher fatal nach hinten losgehen, denn in Floating Regeln kann wesentlich mehr eingestellt werden als an Interface Regeln und sollte hier nur mit Vorsicht gebraucht werden wenn man weiß was man tut, um keine Löcher aufzumachen.
Was du suchst wird sich eher unter NAT / Outbound verstecken. Hier ist per default automatisch aktiv, das kannst du auf "manuell" umstellen und dort dann bei den ausgehenden Regeln auswählen, was er beim Umsetzen ins Netz für eine IP zu Grunde legt. Eigentlich sollte das meinem Verständnis nach gar nicht rotieren (Bug?) aber hier kannst du ggf. Wan Adresse oder auch eine der Aliase definieren und angeben, die verwendet werden soll.
Gruß
-
Hallo
Ich konntes es nachvollziehen, in der Tat rotiert es mit den Auto Rules Outbound (siehe Bild wie default).
Mit hybrid rules mit einem manuellen Eintrag (Bild) funzt es, nun wird immer die richtige IP und eine WAN angezeigt. Gehe ich wieder zurück auf Auto, gleiches Verhalten wie beschrieben. Könnte ein Bug sein.
Gruss
-oliver
-
Kein Bug. Ist seit 18.1 der Standard für den automatischen Modus.
Grüsse
Franco
-
Danke Franco. Ich erachte dies wichtig, explizit in der Doku anzugeben und darauf hinzuweisen.
Denn wer wie ich davon ausgeht (von 17.7 her kommend und auf 18.1 upgegradet), dass mit einem Subnetz auf WAN Seite die outgoing Adresse der Sessions eineindeutig der gesetzten einzelnen WAN-Adresse entspricht, kommt nie auf die Idee, dass alle virtual IPs des WAN Subnetzes session rotierend verwendet werden. Ich habe auf zig Servern einen Fehler gesucht, weil Ip-basierte Zugriffslisten nicht funzten, bis ich das in einem Logfile entdeckte, dass der Kern woanders hinkommt.
Gruss -oliver
-
Hi Oliver,
Ist in den Release Notes. Leider post-mortem, wird aber beim GUI Update von 17.7 auf 18.1 angezeigt:
https://github.com/opnsense/changelog/commit/79852185ad
Die Sticky-Option machen wir für die nächsten Images zum Standard.
https://github.com/opnsense/core/commit/912dd0d
Grüsse
Franco
-
Ich habe das glatt überlesen. Alles klar. Sticky-Option per default macht Sinn (wenn auch nicht jeder ein v4 Subnetz auf WAN Seite hat).
Danke für OPNSense.
-oliver
-
:)
-
@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?
Kein Blame dafür jetzt, aber mich interessiert, warum das überhaupt aufgenommen wurde :)
Gruß Jens
-
Das ist bei mir auch so, und ich hätte es auch gerne über die eigentliche WAN-Adresse als über die Virtuellen IPs.
Ich trau mich aber jetzt nicht ohne Beispiel die NAT-Konfiguration um zuwerfen. Da ich im Notfall dann zur Firewall fahren muss.
-
@almo: dein Beispiel siehst du oben bei schnauz' Post: https://forum.opnsense.org/index.php?topic=7438.msg33668#msg33668
-
Also mit LAN, DMZ, OpenVPN dann wohl so
Siehe Bild:
-
Bis auf die Tatsache, dass die 127er Regeln für Localhost etc. fehlt - ja, dann sieht es gut aus. :)
-
Finaly :)
Bei einem IP-Check ist es jetzt auch die WAN-Adresse.
-
@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
-
> Ü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
-
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 :)
-
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
-
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. :)
-
> 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 :)
-
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
-
> 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
-
Okay, danke dir schon einmal. Habe den Patch noch an ein paar anderen Stelle angebracht für Feedback. :)
Grüsse
Franco
-
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 :)))
-
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
-
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. :)
-
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