Alias XY_address bei Alias IPs

[JeGr]

Hi,

da das Thema in den letzten Wochen gefühlt häufiger bei uns aufgeschlagen ist, wollte ich nicht bis zur nächsten Usergroup warten und das hier reinpacken, damit es ggf. auch in der Suche aufschlägt.

Es ging länger auch an mir vorbei, dass bereits Ende 2018 das Format der exportierten pf.conf geändert wurde und sich dabei das Verhalten der integrierten Interface Addresse Aliasen (bspw. WAN address) geändert hat:

https://github.com/opnsense/core/issues/2457

Warum es den Change von "wir schreiben IP in pf.conf" zu (Interface) gab, ist mir nicht geläufig, aber der Fix für das Verhalten hatte dann wohl andere Probleme. Da man es dann aber nicht wieder zurück auf IP gebaut hat, sondern auf Interface belassen, verhalten sich nun alle Platzhalter der Interface Addressen (WAN address, LAN address, etc.) so, dass damit ALLE IPs auf diesem Interface enthalten sind.

Hat man also via IP Alias und Co mehrere IPs auf einem Interface ist "XY Address" nicht mehr eindeutig! Gerade in größeren Szenarien, in denen man bspw. mehrere IPs auf einem WAN Interface hat (/29 öffentliches Netz) und man diese IPs nicht auf sein WAN geroutet bekommt, sondern selbst auf dem WAN als Aliase konfigurieren muss, kann das fatal sein. Warum? Weil der Name des Platzhalters impliziert, dass es sich um eine Adresse - die Haupt IP, die ich beim Interface konfiguriere, handelt. Und man sehr häufig diese (einzelne) IP dann mit Regeln ausstaffiert. Nutzt man dazu aber bspw. "WAN Address" als Alias und legt später zusätzliche IPs auf, werden diese automatisch! auch freigegeben.

Noch schlechter ist das Verhalten dann bei Port Forwards: definiert man hier einen internen Host als Ziel für Destination "WAN Address" und leitet auf bspw. Webserver 1 weiter und legt danach ein zweites Forwarding für eine WAN Alias IP an, die im Dropdown ja als Auswahl auftauchen, dann wird dieser Forward nie ausgeführt weil der "WAN Address" Forward auch die zusätzlichen IPs "wegfrisst".

Somit sollte man die "XY Address" Aliase nach Möglichkeit vermeiden, um Lücken im Regelset zu entgehen. Wir hatten das gerade erst sehen können, dass bspw. ein Forward von SSH auf einen internen Server via "WAN Address" dazu führte, dass plötzlich auf allen Alias IPs dieser Forward aktiv war - auch auf IPs, die explizit eigentlich nur für Mail oder VPN Nutzung gedacht waren. Man muss die Interface IP nochmals manuell extra als Alias anlegen. Sehr unschön bei Setups, bei denen die Zuweisung dann aber dynamisch passiert bspw. per PPPoE oder DHCP. Da man hier die WAN IP nicht kennt und beeinflussen kann, kann man nur hoffen, dass es ggf. eine statische IP ist, die man dann wieder in ein Alias packen kann. Ansonsten ist man bei dynamischen IPs darauf angewiesen genau nachzusehen was man tut und was damit freigegeben ist um falsche oder unnötige Freigaben zu vermeiden.

Gerade in größeren Umgebungen mit größerem öffentlichem IP Adressraum sollte man daher nur noch mit genau spezifizierten IPs oder eigenen Aliasen arbeiten. Eine Änderung auf das eigentliche/alte Verhalten scheint bislang eher nicht angestrebt zu werden. Aber da ich alleine in den letzten Monaten hier einige Fragen gelesen hatte, warum ggf. weitere 1:1/BiNAT Sachen oder Port Forwardings oder auch Regeln nicht so funktioniert hatten wie gedacht wenn mehrere IPs im Spiel sind, wollte ich das auch für die bessere Sichtbarkeit mal hier lassen.

Cheers
\jens

[Patrick M. Hausen]

Danke, Jens! Das war wichtig!

[JeGr]

Ich muss gestehen, nachdem ich das im engl. Bereich gepostet habe und bis dato keinerlei Antwort drauf bekommen habe (dafür eine solala Antwort via Social Media) hege ich Zweifel ob diese Änderung überhaupt je breitflächig bekannt ist/wurde und ob nicht ganz viele Boxen inzwischen "undichte" oder unschöne Konfigurationen deshalb haben ohne es ggf. zu wissen. Zumal es nirgends wirklich dokumentiert ist und "WAN Address" nun auch definitiv Einzahl und nicht Mehrzahl ist.

Sehr sehr seltsam.