Verständnisfrage zur Filterung von IPs auf Loopbackinterfaces

[Layer8]

Hallo alle,


wir haben auf unserer Sense ein WAN-Interface an dem das Internet hängt. Diesem ist ein ISP-Router vorgeschaltet. Der ISP-Router routet ein paar public IPs auf unsere Sense (Ziel ist die if WAN .2 Addresse).

Die Public IPs die wir auf die Sense geroutet bekommen sind auf der Sense alle als Virtual IP auf lo1 konfirugiert.


--------------
|ISP-Router |
--------------
   | if ISP .1
   |
   |
   | if WAN .2
 --------
|Sense |---if lo1 (mit public IPs als Virtual IPs)
 --------


Meine Frage bezieht sich auf die Firewallregeln.

Ich bin mir in folgendem Punkt nicht ganz sicher: Wird ein Paket, was einmal über ein physisches Interface in die Sense gelangt ist, dann nochmal am lo1 gefiltert?

Klar ist: Auf dem if WAN muss eine eingehende Regel erstellt werden, die den Traffic für die Public IPs zulässt. 

Aber muss oder kann ich auf dem Loopback-Interface auch nochmal Regeln erstellen, oder wird das nicht mehr gefiltert? Denn: Ein Loopbackinterface kann ja niemals von einem angeschlossenen "Kabel" erreicht werden, ein Loopback-Interface ist ja immer am Betriebssystem angeschlossen.

Es gibt mehrere Gründe, wieso ich die Public IPs gerne auf ein Loopbackinteface konfigurieren will:

1. Ich kann für jeden Kunden ein eigenes lo1 Interface anlegen. Das erleichtert die Konfiguratio und Übersicht von Regeln.

2. Bei Routern und L3-Switches anderer Hersteller ist es ratsam, IPs auf Loopback-Interfaces zu konfigurieren. Der Grund ist: Geht ein physikalisches Interface mal down, z.B. weil das Kabel gezogen wurde, sind dann oft auch alle virtuellen IPs, die auf dieses Interface konfiguriert wurden, nicht mehr erreichbar. In dem Punkt weiß ich aber nicht, wie sicht die Sense verhält. Daher die Frage:

Wie verhält sich die Sense hier? Welchen Unterschied macht es, ob die Virtual IPs auf ein physikalisches Interface oder ein Loopback konfiguriert sind?

Wie macht ihr das? Wo filtert ihr Adressen die auf einem Loopback hängen?

[Patrick M. Hausen]

Ich kann dir nur einen Teil beantworten:

Wie verhält sich die Sense hier? Welchen Unterschied macht es, ob die Virtual IPs auf ein physikalisches Interface oder ein Loopback konfiguriert sind?

IP-Adressen eines phys. Interfaces sind "weg", wenn das Interface "down" ist. Ebenso alle darüber konfigurierten Routen.

Wie macht ihr das? Wo filtert ihr Adressen die auf einem Loopback hängen?

Ich mache seit 30 Jahren in Netzwerken, habe n Zertifizierungen, ein eigenes RZ, und ich habe in einem Firewall-Setup noch nie IP-Adressen an ein Loopback-Interface gebunden. Daher: gar nicht. 

In deinem konkreten Fall: für "das Loopback", also lo0, 127.0.0.1 existieren automatische Regeln, die fast alles erlauben. Siehe Screenshot.

Wenn du weitere Interfaces hinzufügst, musst du mal gucken, ob die abhängig vom Interface-Typ auch alle diese Regeln bekommen oder ob OPNsense das nur für lo0 macht.

Weshalb reicht es nicht, einfach die eingehenden Pakete auf dem WAN-Interface zu filtern?

Gruß
Patrick

[franco]

> |Sense |---if lo1 (mit public IPs als Virtual IPs)

Weiss nicht ob public wirklich sinnvoll ist (ggf. als /32 bzw. /128) aber private Adressen aus einem nicht verwendetem Segment empfehlen wir hier gern zur Konfiguration. Das ist wohl so nen Cisco-Ding


Cheers,
Franco

[Layer8]

Danke fürs Feedback.

pmhausen:

Dass die IP-Adresse weg sind sobald das Interface down ist, bestärkt mich schon mal darin, dass ich die IPs nicht auf das WAN-Interface packen will. Denn es greifen dann nicht nur Clients aus dem WAN/Internet auf die Public IP zu, sondern auch aus dem internen Netz.

Link zum ISP-Router weg? IPs weg. Tanceiver kaputt, Kabel gezogen, etc.? IPs weg. Threatprobleme und man will mal das WAN Interface administrative down nehmen? IPs weg.

Ich mache seit 30 Jahren in Netzwerken, habe n Zertifizierungen, ein eigenes RZ, und ich habe in einem Firewall-Setup noch nie IP-Adressen an ein Loopback-Interface gebunden. Daher: gar nicht. 

Das ist ja Geschmackssache. Hab ich auch lange Zeit nicht gemacht, aber es hat so seine Vorteile. Und letztendlich ist die Sense ja nicht nur Firewall, sondern in erster Linie ein Router.

Achtung: lo0 mit der 127.0.0.x und den entsprechenden Default Regeln hat nix mit einem selbst angelegten lo1, lo2, etc. zu tun, auf das z.B. 12.23.34.45/32 konfiguriert ist. So ein selbst angelegtes Loopback Interface hat erstmal keine Regeln, wie jedes andere selbst erstelte Interface auch.

Warum ich die Regeln gerne auf das lo1 legen würde ist einfach ein Thema der Übersicht und Ordnung. Ein vollgeballertes WAN-Interface auf dem Regeln für unterschiedliche Kunden/Projekte liegen ist halt nicht so übersichtlich wie wenn die Regeln auf dem Interface sind, wo auch die IPs hängen.

franco:

Was spricht denn gegen public IPs auf dem lo1?

Warum wir die IPs auf der Sense brauchen: Weil wir dort Loadbalancing, ACME und weitere Dienste betreiben. Und dafür bietet sich ein stabiles Loopbackinterface an.

Und ja, wir würden jede public IP dann immer als /32 auf das lo1 konfigurieren.




Zu meiner eingehende Frage hab ich mir folgende Überlegung angesellt:

Wahrscheinlich kann man an dem Loopbackinterface nicht mehr filtern, wenn das Paket einmal durch ein anderes Interface in die Sense gelangt ist. Das geht ja auch nicht, wenn ich über ifX in die Sense gehe und auf die Gatewayadresse oder eine virtuelle IP von ifY pingen will. Sobald die Regel auf ifX da ist, die das Paket rein lässt, kommt es auf ifY an. Daher vermute ich, dass man wirklich nur an if1 filtern kann, aber gesicherte Erkenntnis ist das nicht.

Was ich mir noch vorstellen kann: Vielleicht klappt es mit einer "out"-Regel auf ifY ?

[Patrick M. Hausen]

> |Sense |---if lo1 (mit public IPs als Virtual IPs)

Weiss nicht ob public wirklich sinnvoll ist (ggf. als /32 bzw. /128) aber private Adressen aus einem nicht verwendetem Segment empfehlen wir hier gern zur Konfiguration. Das ist wohl so nen Cisco-Ding

Natürlich - Loopback als Router-ID für OSPF and friends und auch für die Control-Plane ist Standard. Adressen für irgendwelche Dienste hinter den Systemen hab ich aber immer an die Interfaces gebunden, zu denen die Requests reinkommen. Immer so weit "draußen" wie möglich.

[Layer8]

In dem Fall laufen die Dienste aber nicht hinter der Sense, sondern auf der sense.

Loadbalance (nginx, haproxy) oder acme zur Zertifikatsverwaltung sind nur zwei Beispiele.

[Patrick M. Hausen]

In dem Fall laufen die Dienste aber nicht hinter der Sense, sondern auf der sense.

Loadbalance (nginx, haproxy) oder acme zur Zertifikatsverwaltung sind nur zwei Beispiele.

Jetzt hab ich es auch begriffen 

Wir lösen das mit den vielen Regeln auf WAN durch entsprechende Benennung und Kategorien. Da kann man im UI dann ja recht nett filtern.

Und im RZ sind Interfaces nicht down.  Alles Multi-Chassis-LACP und darauf VLANs. Hier im Büro laufen keine Dienste, die von intern über außen erreichbar sein müssten, wenn das Telekom-Modem weg ist. Ohne Uplink kann man sowieso alle nachhause ins Homeoffice schicken ... RZ ist wie gesagt eine ganz andere Nummer bei uns.

Interessanter Ansatz, den du da hast ...

[chemlud]

In dem Fall laufen die Dienste aber nicht hinter der Sense, sondern auf der sense.

Loadbalance (nginx, haproxy) oder acme zur Zertifikatsverwaltung sind nur zwei Beispiele.

Die Frage, was läuft hinter/auf/neben der Sense ist ein interessantes Thema und viel zu wenig beleuchtet imho...

[Layer8]

In dem Fall laufen die Dienste aber nicht hinter der Sense, sondern auf der sense.

Loadbalance (nginx, haproxy) oder acme zur Zertifikatsverwaltung sind nur zwei Beispiele.

Jetzt hab ich es auch begriffen 

Wir lösen das mit den vielen Regeln auf WAN durch entsprechende Benennung und Kategorien. Da kann man im UI dann ja recht nett filtern.

Und im RZ sind Interfaces nicht down.  Alles Multi-Chassis-LACP und darauf VLANs. Hier im Büro laufen keine Dienste, die von intern über außen erreichbar sein müssten, wenn das Telekom-Modem weg ist. Ohne Uplink kann man sowieso alle nachhause ins Homeoffice schicken ... RZ ist wie gesagt eine ganz andere Nummer bei uns.

Interessanter Ansatz, den du da hast ...

Wir haben hier Projektnetze, in die eigentlich kein Client eine direkte IP-Verbindung aufbauen können soll. Als Zugriff auf diese Netze haben wir Remote Desktop Gateways (Apache Guacamole), die dann den Nutzern einen Zugriff über RDP/SSH auf die Maschinen in diesen Projektnetzen erlauben, aber eben alles Webbased.

Wenn bei uns Internet weg ist, können die Leute dann zwar nicht mehr surfen, aber immernoch über den Loadbalance auf Guacamole zugreifen und zumindest dort was tun, wenn sie nicht grad zu Hause hocken.

Der Vorteil die IPs dann auf de lo1 zu haben ist aber, dass, falls mal kurz ein phys. Interface down sein sollte, die IP (und damit auch der Socket) noch da ist und dann der Dienst (z.B. nginx und haproxy) nicht crashed.

[Layer8]

In dem Fall laufen die Dienste aber nicht hinter der Sense, sondern auf der sense.

Loadbalance (nginx, haproxy) oder acme zur Zertifikatsverwaltung sind nur zwei Beispiele.

Die Frage, was läuft hinter/auf/neben der Sense ist ein interessantes Thema und viel zu wenig beleuchtet imho...

Ich kann mir vorstellen worauf du hinaus willst.

Es ist nicht so, dass wir auf *einer* Firewall alle möglichen Dienste drauf haben. Das obige Bild ist nur eine stark vereinfachte Version worum es geht.

Tatsächlich haben wir mehrere Sensen laufen. Die eine routet und segmentiert  und filter viel (also macht das, was eine FW so tun soll), die andere kümmet sich nur um Zertifikate, die nächste macht Loadbalancing.

Wenn eine Firewall Dienste nicht sicher anbieten kann, dann ist die Frage, warum das ein nicht gehärteter Host können soll. ;-)

[franco]

Was spricht denn gegen public IPs auf dem lo1?

Wenn es geht ja ok, aber ich bin da prinzipiell Patricks Meinung. Die VIP muss ja angelegt werden. Dann halt auch gleich auf dem WAN wenn es "public" ist.


Grüsse
Franco