Verzweifle an einer Regel: Client zu Internet

[bread]

Hi,

ich bin heute von ipfire zu OPNsense umgestiegen und ich verzweifle schon seit Stunden und fühle mich wie ein völliger Anfänger!

Bei ipfire hat man Client als Source und red (WAN) als Destination ausgewähl und war mehr oder weniger fertig.

Hier habe ich schon mehrere Möglichkeiten gelesen und verstehe sie einfach nicht.
Die meisten Beispiele erlauben dem Client bzw. dem Netzwerk einfach any. Das ist irgendwie ein völliger Unsinn.
Ich will, dass ein Client im LAN einfach ins Internet kann, ein anderer dafür nicht.
Oder von mir aus, dass LAN ins Internet kann, aber nicht ins wLAN oder auf den Server im anderen Subnet etc.

Wenn ich als Source den Client auswähle (habe ich schon als Host angelegt) und als Destination WAN address, dann komm ich nicht raus. Bei WAN net, komme ich wenigstens auf den ISP Router, der am WAN hängt, aber nicht weiter (was wegen "net" halbwegs verständlich ist). Hat dann diese WAN-Lösung als Source gar keine Möglichkeit den Client ins Internet zu schicken? Für was ist sie dann gedacht?

Ich kann den Client als Destination nehmen, any als Source und dann umkehren. Dann komm ich schon ins Internet, aber dann komm ich doch auch sonst überall im privaten Netzwerk hin, oder? Dann muss ich also eine explizite Blockregel für alle private Netzwerke für diesen Client erstellen UND eine andere Regel zum Erlauben einzelner Kontakte (z.B. interner DNS server). Ist es nur so umständlich lösbar?

Danke schon mal für jegliche Erleuchtung!
Brot

[Patrick M. Hausen]

Wohin verbindet denn dein Client, wenn er "ins Internet" geht? Doch zu beliebigen Adressen. Und das erste Paket, das der Client sendet, kommt zum LAN-Interface rein.

Also

Interface: LAN
Direction: IN
Source: Client X (Gruppen anlegen hilft, die Sache zu vereinfachen)
Destination: *
Action: allow

Wenn du demselben Client den Zugang zum Internet aber z.B. nicht zu irgendwelchem IoT-Geraffen in einem anderen Netz geben willst, dann brauchst du zwei Regeln oder ein "destination invert".

Also

Regel 1
Interface: LAN
Direction: IN
Source: Client X (Gruppen anlegen hilft, die Sache zu vereinfachen)
Destination: IoT-Netzwerk
Action: deny

Regel 2
Interface: LAN
Direction: IN
Source: Client X (Gruppen anlegen hilft, die Sache zu vereinfachen)
Destination: *
Action: allow

oder

Interface: LAN
Direction: IN
Source: Client X (Gruppen anlegen hilft, die Sache zu vereinfachen)
Destination: ! IoT-Netzwerk (das Ausrufezeichen für "nicht" ist das "destination invert" im Menü)
Action: allow

OPNsense kann keine Regeln auf Basis von Zonen/Interfaces (also z.B. wie die Sidewinder "von LAN nach WAN") sondern nur auf Basis von IP-Adressen oder ähnlichen Objekten.

"WAN net" z.B. ist das direkt am WAN angeschlossene Netz - also die Summe von den direkt dort liegenden IP-Adressen. Meist also dein externes Interface der Sense und der ISP-Router und sonst nicht viel. Oder in einem Business-Kontext vielleicht ein externes /29 oder /28.

Deshalb kommst du bei "source: LAN net, destination: WAN net" dann eben nur bis zum ISP-Router ;)

[bread]

Sehr schön! Danke!
Klare Beschreibung!

Ok, da muss ich also umdenken, weil OPNsense quasi ausschließlich mit Adressen arbeitet und nicht mit Schnittstellen. Zumindest in diesem Kontext.

Die Reihenfolge ist immer zuerst spezielle Deny, dann allgemeine Allow bzw. spezielle Allow, dann allgemeine Deny?

1. Wenn ich mehreren Geräten aus verschiedenen Subnetzen Zutritt ins Internet gewähren will. Dann mache ich eine Gruppe "Devices" und erstelle die Regel bei Floating. Unter Interfaces alle betreffenden Interfaces auswählen. Unter source die erstellte Gruppe "Devices" und bei destination any. Danach erstelle ich im jeweiligen Subnet bzw. am jeweiligen Interface eine bzw. mehrere Deny-Regeln für entsprechende Geräte, die nicht auf andere Subnetze zugreifen sollen. Korrekt?

2. Bei Floating kann ich auch z.B. ICMP und DNS in allen privaten Netzen erlauben, indem ich als Source und Destination "Private Networks" (zuvor erstellte Gruppe) auswähle und dann ICMP als Protokoll bzw. DNS als Port wähle. Korrekt?

3. Danach kann ich bei einem internen DNS server wie PiHole die Regel klonen und als Destination any nehmen und die Regel blocken. Dann unterbinde ich einen externen DNS leak. Korrekt?

4. Wenn ich jetzt aber ein Laptop habe, der sowohl über LAN, wie auch über wLAN laufen soll (verschiedene Subnetze) und ich nicht will, dass wLAN Zugriff zum LAN hat. Muss ich als Host LaptopLAN und LaptopWLAN anlegen um dann entsprechend wegen dem zuvor beim Floating eingestellten "allow any" als Destination jeweils dem Einen das Andere sperren. Korrekt?

ODER ich lasse das Laptop mit zwei IPs gruppiert und blocke danach LAN net zu WLAN net. Ich vermute, das wäre die elegantere Lösung. Korrekt? Muss ich es dann auch andersherum blocken? Also auch WLAN net zu LAN net?

[bimbar]

Ich mache mir ein Alias "netgroup_internet_inverted", wo alles drin ist, was nicht internet ist (interne netze bei mir), dann eine Floating Regel accessgroup_internet -> ! netgroup_internet_inverted allow. In accessgroup internet ist alles drin, was ins internet können soll.
Ich würde auch lieber ein Zielobjekt Internet oder ein Destination Interface Internet haben, gibts aber nicht, und so gehts auch.

Zu den Fragen:

1. Ich mache nur Floating Regeln, ich filtere nicht gern nach Interfaces, daher steht da bei mir in der Regel "any" drin. Du kannst nur 1 (In-) Interface in einer Regel auswählen. Ebenso verzichte ich komplett auf "deny" Regeln. Bei mir wird erlaubt, was darf, der Rest geht in den default drop. Damit ist dann auch die Reihenfolge der Regeln egal und eine wichtige Fehlerquelle damit ausgeschlossen. Zugegebenermaßen gibt es Fälle, wo das nicht praktikabel ist.

2. ja

3. Wenn ich die Frage verstehe, dann ja.

4. Würde ich als "Allow LAN to WLAN" machen und den Rest einfach nicht erlauben. Deswegen bin ich auch kein Freund der Regelschematik:

- Deny Sachen die nicht sollen
- Allow den Rest, wg. Internetzugang

Lieber direkt

- Allow private to !private

[bread]

habe ebenfalls eine "private_networks" Gruppe und bisher eine "devices" Gruppe für die Geräte, die Internet haben sollen. Die Floatingsregel ist bei mir dann: Source: "Devices", Destination: "any". Dann dürfte es ja klappen. "any" ist dann in dem Fall "Internet" oder nicht?

Mit Umkehrung habe ich zuvor gearbeitet, aber das ist ja an sich unnötig oder was hat es für Vorteile?

Ich dachte nur bisher, dass "any" auch den Eintritt in andere Subnetze erlaubt, aber so wie ichs jetzt verstanden habe, geht es um den Zugriff Richtung Internet, aber nicht zu den anderen Subnetzen, der per default geblockt ist.

4. Würde ich als "Allow LAN to WLAN" machen und den Rest einfach nicht erlauben. Deswegen bin ich auch kein Freund der Regelschematik:

Also eine Grundsätzliche Regel, die den Kontakt von LAN zu WLAN erlaubt? Ist es nicht besser die Netze getrennt zu handhaben? Oder habe ich da einen Denkfehler?

[Patrick M. Hausen]

Ich dachte nur bisher, dass "any" auch den Eintritt in andere Subnetze erlaubt, aber so wie ichs jetzt verstanden habe, geht es um den Zugriff Richtung Internet, aber nicht zu den anderen Subnetzen, der per default geblockt ist.

"any" als Destination erlaubt den Zugriff ins Internet und in alle anderen lokal verbundenen oder gerouteten Netze.

Es gibt aber kein Objekt in OPNsense das bedeutet "nur Internet und sonst nichts".

Deshalb kann man z.B. eine Gruppe aller lokalen Netze anlegen und dann ! lokale_Gruppe als Ziel verwenden, wenn man wirklich nur Internet erlauben will aber nichts über lokale Netzgrenzen hinweg.

Wie du das machst und was genau du willst, ist dir überlassen.

Mein LAN darf überall hin. Da ist ja mein Rechner drin, von dem aus ich arbeite und alle anderen vertrauenswürdigen Geräte. Mein Netz für die öffentlich erreichbaren Dienste darf nur ins Internet und nicht ins LAN. Etc. pp.

[bread]

Deshalb kann man z.B. eine Gruppe aller lokalen Netze anlegen und dann ! lokale_Gruppe als Ziel verwenden, wenn man wirklich nur Internet erlauben will aber nichts über lokale Netzgrenzen hinweg.

Ah, verstehe! Danke!
Hab ich so gemacht. Da hat man mehr Kontrolle.

Ok... und wie zum geier sdchaffe ich es LAN ins WLAN zu erlauben?
Ich habs punktuell von Device zu Device mit Floating versucht:
Interface: WLAN
Source: Client im LAN
Destination: AP im WLAN

Ich habs direkt flächig auf dem WLAN Interface versucht:
Source: LAN net
Destination: WLAN net

Kein Erfolg.

[Patrick M. Hausen]

Also System im LAN initiiert Verbindung zu System im WLAN? Und das sind getrennte Interfaces oder VLANs?

Wenn ja:

Interface: LAN
Direction: IN
Source: LAN net
Destination WLAN net
Action: allow

Wobei ich nicht ganz verstehe, wieso man einen Unterschied zw. kabelgebundenen und drahtlosen Systemen macht. Mein Laptop am Schreibtisch (Kabel), mein Laptop auf dem Balkon (WiFi), mein Telefon, mein Tablett, ... sind alle gleich vertrauenswürdig. Der Accesspoint hängt als Bridge im LAN und gut ist, DHCP, DNS, RA, ... macht die Sense.

[bread]

Also System im LAN initiiert Verbindung zu System im WLAN? Und das sind getrennte Interfaces oder VLANs?

Yes. Sind getrennte Interfaces.

Also habe ich beim Floating gemacht:
Interface: LAN
Direction: IN
Source: LAN net
Destination WLAN net
Action: allow
mit IPv4 und IPv6

Und ich bekomm weiterhin keine Verbindung.

Ich hab ja den AP mal an den ISP Router gehängt um zu checken, ob die Verbindung grundsätzlich funktioniert... und ja, dort bekommt das Ding per DHCP ne IP und ich kann mich über die WEB GUI damit verbinden. Hier bekommts auch ne IP, ich sehe sie in der ARP Tabellte und bekomm keine Verbindung.

Wobei ich nicht ganz verstehe, wieso man einen Unterschied zw. kabelgebundenen und drahtlosen Systemen macht.

Naja, das Ding funkt ja bis vor die Tür bzw. zu den Nachbarn rüber. Deswegen dachte ich, dass es sinniger wäre, den WLAN auszusperren. Oder gibts da nen Denkfehler?

[Patrick M. Hausen]

Wenn dein WLAN ein 30stelliges zufälliges Passwort hat, und nur vertrauenswürdige Geräte drin sind, mache ich mir zumindest dahingehend keine Sorgen.

Warum Floating? Die Regel gehört auf das LAN-Interface ... man braucht Floating Regeln fast gar nicht. Meine einzigen Floating Regeln siehst du im Anhang.

[bread]

Wenn dein WLAN ein 30stelliges zufälliges Passwort hat, und nur vertrauenswürdige Geräte drin sind, mache ich mir zumindest dahingehend keine Sorgen.

Klar, da kann man privat denk ich entspannt sein. Bei einem Firmennetzwerk macht es denk ich durchaus Sinn zu trennen. BYOD und Co.

Warum Floating? Die Regel gehört auf das LAN-Interface

Ich bin einfach dem Kollegen @bimbar gefolgt. Er setzt auf Floating.
Im Grunde hat man dann alle Regeln parat.
Gibt es Nachteile?

Ich denk, die Übersichtlichkeit leidet dann doch darunter. Vermutlich wäre das der Grund die Regeln doch auf dem jeweiligen Interface zu machen.

Habe die Regel im LAN erstellt. Von LAN net zu WLAN net und erreich das Ding trotzdem nicht.. hä?
Irgendwo stehe ich wohl auf dem Schlauch.

[Patrick M. Hausen]

Steht sie ganz oben? Regeln werden der Reihe nach abgearbeitet und wenn "quick" gesetzt ist (default), greift die erste, die matcht.

Firewall Live View kann helfen.

Außerdem: erst Floating, dann Interface Groups, dann Interface.

Gerade in unserem Firmennetzwerk ist das so mit LAN = WLAN. Wir haben allerdings auch eine recht strikte BYOD-Policy.

[bread]

Es gibt ja noch kaum Regeln. Das sind die einzigen bis jetzt (siehe Bild).

Live View glotze ich schon die ganze Zeit.
Da kommt nicht mal irgendeine Art verbindung zwischen dem LAN und WLAN, auch keine Drops, Blocks etc. Einfach nichts. Nicht mal der Pingversuch wird angezeigt. Logs sind an.

Wenn ich die IP des AP anzeigen lasse, dann sehe ich nur, wie das Ding fortwährend 1.1.1.1 anpingt (Connection Check).

Klar, bei strickter BYOD-Politik, am besten mit Geschäftsgeräten, ist es nochmal anders. Aber wenn dem nicht so ist, ist es denk ich sinnvoller den WLAN aus dem LAN rauszuhalten.

[Patrick M. Hausen]

tcpdump rausholen, auf dem LAN und auf dem wLAN Interface gucken, was passiert.

P.S. Übereifrige NAT-Regel vielleicht? Hast du outbound NAT auf irgendeinem Interface außer WAN aktiviert zu der Zeit als die der Paketfluss und die Regeln noch nicht ganz klar waren?

Regeln kommen auf das Interface, wo das erste Paket der Verbindung zur Firewall herein kommt.
Outbound NAT kommt auf das Interface, wo die Pakete die Firewall verlassen - meist nur richtung Internet.

[bread]

tcpdump rausholen, auf dem LAN und auf dem wLAN Interface gucken, was passiert.

ARP, Request who-has 172.16.63.1 tell 172.16.63.101, length 46
ARP, Reply 172.16.63.1 is-at 64:62:66:21:b2:57 (oui Unknown), length 28

Das bekomme ich auf dem WLAN

Ich habe gar keine NAT-Regeln gesetzt, habe nach dem Wizard an sich nicht viel gemacht. Outbound ist bei mir auf automatisch.

Regeln kommen auf das Interface, wo das erste Paket der Verbindung zur Firewall herein kommt.

Also immer dorthin, wo z.B. der Client hängt, der irgendwas dürfen soll.

Diese NAT-Umsetzung verstehe ich bei OPNsense noch gar nicht. Ipfire war wirklich schlichter.
Muss man bei OPNsense zu jeder Regel noch zusätzlich irgendwo eine NAT-Regel erstellen?
Wenn der Outbound auf automatic steht, dann wohl nicht, oder?