OPNsense Forum

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

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 ;)

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?

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

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.

Quote4. 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?

Quote from: bread on June 23, 2024, 12:46:39 PM
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.

QuoteDeshalb 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.

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.

QuoteAlso 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.

QuoteWobei 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?

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.

QuoteWenn 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.

QuoteWarum 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.

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.

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.

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.

Quotetcpdump 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.

QuoteRegeln 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?

Wenn outbound auf automatic steht, dann wird ausgehend zum Internet für alle lokal angeschlossenen Netze geNATed. Meist ist das das, was man will.

Hat man noch eine interne Leitung zu einem anderen Standort oder aus anderen Gründen (Layer 3 Switch o.ä.) interne Routen, werden diese statisch gerouteten Netze nicht automatisch geNATed. Dann muss man hybrid oder manual verwenden.

Normalerweise brauchst du daran nichts zu ändern.

Also wenn du vom LAN aus ein "ping AP" absetzt, dann solltest du doch auf dem LAN der OPNsense die Pakete herein kommen sehen? Und dann guckst du, ob sie auch auf wLAN raus gehen. Und ob Antworten zum wLAN rein kommen? Und ob diese zum LAN wieder raus gehen?

Schön Stück für Stück.

Danke fürs Dranbleiben  :D

Ich glaub, ich bin mächtig verwähnt von ipfire.
Irgendwie war da wirklich ALLES anders.

Ich habe in der Zwischenzeit was Seltsames festgestellt. Ich glaube irgendwas stimmt mit der Konfiguration der Interfaces nicht. Ich kann von LAN den 10er und zwei 192er Interfaces pingen (also das NIC selber quasi) aber nicht den 172er Bereich.

An sich habe ich sie alle gleich eingerichtet:
enable
prevent removal
static IPv4
none IPv6
172.16.63.1/24 (z.B. WLAN)

Wahrscheinlich müsste ich beim 10er /8 beim 172er /12 und beim 192er /16 machen, ist es relevant?
Es ist bei allen /24 als Standard gelassen und meines Wissens nach passt das auch. Suffixe ist allerdings so ne Sache... die ich nicht ganz checke.

Was mich noch sehr wundert.
Wenn ich für den AP mal testweise einen anderen Port nehme, dann bekommt der AP nur an dem WLAN-Port eine IP per DHCP, andere vergeben nichts. Alle Ports sind statisch eingerichtet. Von wo aus wird per DHCP auf dem WLAN-Port die IP an den angeschlossenen AP vergeben? Und das ist genau der Port, der nicht anpingbar ist.

Vielleicht sind es jetzt DIE Infos, die den Fehler aufzeigen  :o

/Edit:
Ok, ich Depp hab vergessen, dass ich extra bei WLAN DHCP-Bereich einegrichtet habe (macht ja Sinn). Es gibt ja dafür einen extra Einstellungsbereich.

Und BINGO mache ich bei einem anderen Port DHCP an und verbinden den AP, dann kann ich pingen UND erreiche das Ding endlich über WEB GUI. Also stimmt irgendwas mit den Einstellungen des WLAN-Ports nicht.

Was ich allerdings NICHT verstehe, warum ich den AP an einem anderen Port ohne eine FW-Regel erreichen kann!
Es ist die Floating-Regel (siehe oben im Bild): any --> ! private networks. Diese Regel erlaubt wohl nicht nur den Zugang zum Internet, sondern bricht alle verbote zwischen den Interfaces.

OK, ist habe @bimbar nicht verstanden:

QuoteIch 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.

Jetzt habe ich meine Floating_Regel angepasst:
Private_NetworkDevices (alle, die ins Internet dürfen) --> ! Private_Networks (interne Netze)

Jetzt komm ich ins Internet, erreiche aber die anderen Interfaces nicht. So, wie es sein soll.
Verstehen tue ich diese Regel allerdings nicht. Ah... vielleicht dreht das ! die Logik so um, dass es heißt "Überall, aber NICHT in die Private_Networks"??

Jetzt habe ich die besagte Regel fürs andere Interface erstellt (LAN net --> Anderes Netz net) und ich kann den AP per Web GUI erreichen!

Es bleibt das Problem mit dem seltsamen WLAN Port  ;D Da stimmt etwas mit dem Port nicht.

Edit2:
Mittlerweile (wie du im englischen Post wahrscheinlich gesehen hast) habe ich die Einstellungen auf einen anderen Port übertragen und der Fehler ist mitgewandert. Also liegts nicht am Port, sondern an den Einstellungen dafür.

Quote from: bread on June 23, 2024, 10:18:02 PM
Danke fürs Dranbleiben  :D

Oh ... viel aufzudröseln :)

Quote from: bread on June 23, 2024, 10:18:02 PM
Ich glaub, ich bin mächtig verwähnt von ipfire.
Irgendwie war da wirklich ALLES anders.

Was ist denn der Grund zum Wechseln? Ich meine, wenn es funktioniert und du damit klar kamst?

Quote from: bread on June 23, 2024, 10:18:02 PM
Wahrscheinlich müsste ich beim 10er /8 beim 172er /12 und beim 192er /16 machen, ist es relevant?
Es ist bei allen /24 als Standard gelassen und meines Wissens nach passt das auch. Suffixe ist allerdings so ne Sache... die ich nicht ganz checke.

Nein, nein, nein ... kommst du mit Netzmasken klar?

/24 ist nur eine neumodische Art, 255.255.255.0 zu schreiben. Sonst nichts.
/8 --> 255.0.0.0
etc.

Deine lokal angeschlossenen Netze sind in der Größe /24 schon ganz passend für die meisten Anwendungsfälle. Das heißt, du kannst rund 250 Geräte in jedes Netz hängen. Manchmal nimmt man auch /16 - da gehen dann rund 65000 Geräte, wobei so viele Systeme in einem flachen Ethernet nicht gesund sind. Aber vielleicht hat man eine Konferenz mit 1000 Teilnehmern, jeder bringt mindestens einen Laptop und ein Telefon ... /24 ist zu klein, und bevor man lang rummacht, nimmt mal halt /16. Mehr als eine handvoll Tausend an Geräten sind trotzdem nicht gut.

Quote from: bread on June 23, 2024, 10:18:02 PM
Wenn ich für den AP mal testweise einen anderen Port nehme, dann bekommt der AP nur an dem WLAN-Port eine IP per DHCP, andere vergeben nichts. Alle Ports sind statisch eingerichtet. Von wo aus wird per DHCP auf dem WLAN-Port die IP an den angeschlossenen AP vergeben? Und das ist genau der Port, der nicht anpingbar ist.

Der DHCP-Dienst ist natürlich nur für LAN ab Werk eingerichtet, und wenn du neue Interfaces hinzufügst, musst du auch für jedes DHCP einschalten und konfigurieren. Wie soll das sonst gehen?

Quote from: bread on June 23, 2024, 10:18:02 PM
Es ist die Floating-Regel (siehe oben im Bild): any --> ! private networks. Diese Regel erlaubt wohl nicht nur den Zugang zum Internet, sondern bricht alle verbote zwischen den Interfaces.

Nö. Quelle: any - Ziel: ! private networks bedeuted genau das. Die Regel gilt für jedes Quell-System, als Ziel sind aber nur Adressen erlaubt, die *nicht* in private_networks drin sind.

Dein Denkfehler ist womöglich, dass diese Regel für alle Pakete, die nicht auf diese Specs matchen, eben nicht gilt.

Also "any --> ! private_networks" heißt nicht, dass man die privaten Netze nicht erreichen kann. Es bedeutet, dass diese spezifische "allow" Regel auf alle Pakete angewandt wird, die von "any" in "etwas anderes als private_networks" gehen.

Pakete, auf die das nicht zutrifft, werden nicht automatisch geblockt, sondern es wird nun die nächste Regel in der Reihenfolge angeguckt, ob die vielleicht passt.

Regeln sind "was für Pakete genau? Quelle, Ziel, UDP/TCP, Gedöns?" und wenn diese Kriterien passen, dann "Aktion", meistens "allow", weil am Ende ja sowieso alles andere verboten wird. Passt die Regel nicht, ist das aber kein "deny", sondern es wird einfach die nächste Regel in der Liste angeguckt, ob die passt.

Guck dir deine Regeln noch mal in der Hinsicht an. Speziell, überleg dir mal, du willst von deinem PC z.B. auf den AP zugreifen per TCP auf Port 443 (ich rate jetzt mal, dass da das Web UI ist).

Dann werden die Regeln in der Reihenfolge

- Floating
- Interface Groups
- Interface

Und da einfach von oben nach unten angeguckt, bis eine gefunden wird, bei der die Kriterien matchen. Und dann, wenn diese gefunden ist, wird die konfigurierte Aktion ausgelöst: allow/deny.

Wird gar keine gefunden, fällt das Regelwerk durch bis zum Ende, wo immer ein Default "deny all" wartet, und das Paket wird geblockt.

Keine Ahnung wie IPfire das macht, aber glaub mir, jeder Packetfilter, mit dem ich in den letzten 30 Jahren zu tun hatte, macht das genau so.

QuoteWas ist denn der Grund zum Wechseln? Ich meine, wenn es funktioniert und du damit klar kamst?

Ich wollte eine potentere FW und mehr Flexibilität, da habe ich mir die Protectli VP4630 geholt mit 6 Ports und ipfire unterstützt nur 4 Zonen, also 4 NICS, die anderen müssen als VLAN implementiert werden. Und ich habe bisher nichts mit VLAN zu tun gehabt und ehrlich gesagt... will ich auch nicht... ich will Kabel anfassen und in die Ports einstecken  :D

QuoteNein, nein, nein ... kommst du mit Netzmasken klar?

mittelmäßig  8)

/24 bedeutet, dass nur die letzte Stelle, also von 1 bis 250 (warum eigentlich nicht 255?) genutzt werden kann. So war das glaub ich. Je weniger die Zahl, desto mehr IPs können genutzt werden. Obwohl ich das dann nicht verstehe, weil sich ja Subnet ändert. Aber das müssen wir hier nicht klären, sonst wirds zu unübersichtlich im Thread. Da muss ich mich bei Gelegenheit einlesen.

Also lasse ich alle bei /24

Was mir einfällt. Als ich Private_Networks gemacht habe. Sind es folgende geworden: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 Muss ich sie auch dort alle auf 24 setzen? Ich vermute stark.

QuoteDer DHCP-Dienst ist natürlich nur für LAN ab Werk eingerichtet, und wenn du neue Interfaces hinzufügst, musst du auch für jedes DHCP einschalten und konfigurieren. Wie soll das sonst gehen?

Habs vergessen, dass ich selbst für WLAN DHCP eingerichtet habe  :D
Bei ipfire ist die DHCP-Einrichtung direkt beim Interface, hier ist es in einem Extra Menüpunkt. Das ist verwirrend (zumindest für mich).

QuoteAlso "any --> ! private_networks" heißt nicht, dass man die privaten Netze nicht erreichen kann. Es bedeutet, dass diese spezifische "allow" Regel auf alle Pakete angewandt wird, die von "any" in "etwas anderes als private_networks" gehen.

Aber warum war dann bei der Einstellung der Zugang von privaten Netzen untereinander möglich?

Jetzt habe ich ja
PrivateDevices (die ins Internet sollen, Subnetz-übergreifend) --> ! PrivateNetworks
Und ich komm damit ins Internet, aber nicht in die anderen Subnetze (wie es sein soll).
Dann verstehe ich den ! so, dass es wie ein "NEIN" wirkt. PrivateDevices sollen überall hin nur NICHT in die PrivateNetworks, korrekt?

Die Sache ist, dass das Scheitern vom Zugriff auf WLAN definitiv nicht mit den FW Regeln zu tun hat.
Es ist etwas an den Interface-Einstellungen vermute ich.
Es hat alles funktioniert als ich am anderen Port (192er) das Ganze ausprobiert habe. 172er klappt nicht, auch nicht, wenn ich ihn auf den zuvor funktionierenden 192er migriere (also dort einen 172er draus mache).

Quote from: bread on June 24, 2024, 12:02:03 AM
Was mir einfällt. Als ich Private_Networks gemacht habe. Sind es folgende geworden: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 Muss ich sie auch dort alle auf 24 setzen? Ich vermute stark.

Nein, musst du nicht. Das sind einfach alle privaten (RFC 1918) Netze, die es überhaupt gibt. Daher ist es sinnvoll. in einer Regel zu sagen:

von: diesem Interface
nach: überall hin, aber nicht in irgendeines dieser privaten Netze

Du könntest ja in Zukunft weitere Interfaces hinzufügen.

192.168.0.0/16 enthält einfach alle möglichen Netze von 192.168.0.0/24, 192.168.1.0/24, ... bis 192.168.255.0/24 - 256 Stück.

Mit diesem "Subnetz-Kram" solltest du dich ein bisschen mehr befassen, der ist wichtig.

Zu der Frage "weshalb nur 250" - ich hatte "rund 250" geschrieben und "rund 65000". :)

Tatsächlich hat ein /24 eine Größe von 256 Adressen. x.y.z.0 bis x.y.z.255.

Davon sind die 0 und die 255 definiert durch das Protokoll, 255 ist die Broadcast-Adresse, so ein Paket geht an alle angeschlossenen Systeme. Bleiben als 254 von 256 nutzbar für deine Hosts. Und von den 254 wird eine die Firewall brauchen, oder was auch immer für ein Gerät der Router in diesem Netzwerk ist, bleiben 253 für Hosts/Clients.

So weit ins Detail wollte ich aber in dem Moment nicht gehen.

Bei einem /16 sind es 65536 Adressen und nach denselben Überlegungen 65533 für Clients, wobei wie schon gesagt mehr als ein paar Tausend keinen Sinn machen.

Quote from: bread on June 24, 2024, 12:02:03 AM

QuoteAlso "any --> ! private_networks" heißt nicht, dass man die privaten Netze nicht erreichen kann. Es bedeutet, dass diese spezifische "allow" Regel auf alle Pakete angewandt wird, die von "any" in "etwas anderes als private_networks" gehen.

Aber warum war dann bei der Einstellung der Zugang von privaten Netzen untereinander möglich?

Weil diese Regel ja nicht gegriffen hat. Das Paket ging ja nicht von "any" nach "! private_networks"  - offensichtlich gab es weiter unten in der Reihenfolge eine Regel, die das erlaubt hat.

Quote from: bread on June 24, 2024, 12:02:03 AM
Jetzt habe ich ja
PrivateDevices (die ins Internet sollen, Subnetz-übergreifend) --> ! PrivateNetworks
Und ich komm damit ins Internet, aber nicht in die anderen Subnetze (wie es sein soll).
Dann verstehe ich den ! so, dass es wie ein "NEIN" wirkt. PrivateDevices sollen überall hin nur NICHT in die PrivateNetworks, korrekt?

Das "!" ist ein "nein", korrekt. Aber lies dir meinen letzten Beitrag nochmal durch. Diese Regel bedeutet nicht, "Verbindungen in private_networks sind verboten".

Sie bedeutet "diese Regel gilt für alle Pakete, bei denen die Quelle any und das Ziel nicht private_networks ist".

Kommt nun ein Paket mit einer beliebigen Quelle und dem Ziel private_networks, dann greift die natürlich nicht. Dann greift irgendeine der nachfolgenden Regeln.

Was du in der Regel angibst, sagt, für welche Pakete die "Action" gilt. Wenn die Regel nicht "matcht", passiert überhaupt nichts, sondern es werden alle folgenden Regeln abgeklappert, bis es eine gibt, die matcht.

Erst wenn gar keine zutrifft, landen wir beim "deny".

Danke für die Subnetzerklärung, ja, da werde ich noch mehr eintauchen müssen.
Habe jetzt mal statt den IPs für Subnetze die Interfaces genommen. Funktioniert auch.

QuoteWeil diese Regel ja nicht gegriffen hat. Das Paket ging ja nicht von "any" nach "! private_networks"  - offensichtlich gab es weiter unten in der Reihenfolge eine Regel, die das erlaubt hat.

Es gab aber keine.

QuoteSie bedeutet "diese Regel gilt für alle Pakete, bei denen die Quelle any und das Ziel nicht private_networks ist".

Ah! verstanden... aber da muss man ja bei OPNsense eine völlig eigene Logik lernen... puh  :D wie ne Fachsprache.
Oder ist es bei anderen FWs ebenfalls gängig und nur ipfire ist etwas für 'consumer'?

Mein WLAN-Problem verstehe ich allerdings weiterhin nicht.

Quote from: bread on June 24, 2024, 12:21:52 AM

QuoteSie bedeutet "diese Regel gilt für alle Pakete, bei denen die Quelle any und das Ziel nicht private_networks ist".

Ah! verstanden... aber da muss man ja bei OPNsense eine völlig eigene Logik lernen... puh  :D wie ne Fachsprache.
Oder ist es bei anderen FWs ebenfalls gängig und nur ipfire ist etwas für 'consumer'?

Alle Packetfilter funktionieren genau so.

Cisco IOS
Juniper JunOS
Livingston Portmaster
Linux IPchains
FreeBSD/OPNsense pf
FreeBSD IPFW
...

Keine Ahnung, was IPfire da tut.

Firewall-Regeln bestehen aus:

- einer Sammlung von Kriterien für Netzwerkpakete, die abgeprüft werden
- einer Aktion, die durchgeführt wird, wenn die Prüfung erfolgreich ist

Damit plus mit der generellen Angabe, dass die Regeln von oben nach unten abgearbeitet werden, bis irgendeine greift, kann man jede gewünschte Policy implementieren.

QuoteAlle Packetfilter funktionieren genau so.

Dachte ichs mir schon. Ja, ipfire scheint da einen eigenen Weg zu gehen. Wohl eher schlichter, mit einer einfacheren Logik. Dafür aber wohl nicht so umfangreich, eher was für home Anwender.

Soll ich für das seltsame WLAN-Port-Problem nen eigenen Topic aufmachen?
Im Grunde ist es ein anderes Thema. Ins Internet komme ich mittlerweile.

Hier gehts weiter mit dem ausgelagerten Thema:
https://forum.opnsense.org/index.php?topic=41220.0

Quote from: bread on June 23, 2024, 03:34:58 PM

QuoteWenn 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.

QuoteWarum 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.

Hier gibt es viele Möglichkeiten, das zu strukturieren, von denen nicht unbedingt eine richtig und die andere falsch ist.
Ich bin kein Fan von den Interfaceregeln, weil wenn man mal was anders routen will, dann passen die Firewallregeln alle nicht mehr (hauptsächlich ein Thema bei größeren Umgebungen).
Außerdem bin ich Astaro geprägt, wo es die Möglichkeit nicht gab, Regeln an Interfaces zu hängen.
Vielleicht sind aber Interface spezifische Regeln schneller - falls das relevant ist.

Quote from: bread on June 24, 2024, 12:21:52 AM
Danke für die Subnetzerklärung, ja, da werde ich noch mehr eintauchen müssen.
Habe jetzt mal statt den IPs für Subnetze die Interfaces genommen. Funktioniert auch.

QuoteWeil diese Regel ja nicht gegriffen hat. Das Paket ging ja nicht von "any" nach "! private_networks"  - offensichtlich gab es weiter unten in der Reihenfolge eine Regel, die das erlaubt hat.

Es gab aber keine.

QuoteSie bedeutet "diese Regel gilt für alle Pakete, bei denen die Quelle any und das Ziel nicht private_networks ist".

Ah! verstanden... aber da muss man ja bei OPNsense eine völlig eigene Logik lernen... puh  :D wie ne Fachsprache.
Oder ist es bei anderen FWs ebenfalls gängig und nur ipfire ist etwas für 'consumer'?

Mein WLAN-Problem verstehe ich allerdings weiterhin nicht.

Jede Firewall hat ihre eigene Logik, das "!" als Verneinung aber kommt aus der Programmiersprache C und wird ziemlich universal verstanden.
Ansonsten ist allen gemein, daß es im Grunde Regelmaschinen sind, die in der Form "Paket Match -> Action" funktionieren.

@bimbar: danke für die Infos!

Haste vielleicht noch Ideen zu meinem Port-Problem, welches ich mittlerweile in ein anderes Topic ausgelagert habe (siehe oben) :)

@bread lass uns das doch am Freitag angucken - irgendwann ist über ein Forum echt Schluss :)

Quote from: bread on June 24, 2024, 09:38:56 PM
@bimbar: danke für die Infos!

Haste vielleicht noch Ideen zu meinem Port-Problem, welches ich mittlerweile in ein anderes Topic ausgelagert habe (siehe oben) :)

Habe ich gelesen, da stimme ich Patrick zu, ich verstehe aus dem Post nicht, warum das nicht funktioniert, da ist wahrscheinlich irgendein Detail fehlkonfiguriert.