Best practices/Standards für Heimnetzwerk

[fabian]

Und zwar zu dem transparenten Proxy: Dieser dient ja dem durchreichen von Datenpaketen und der gleichzeitigen Filterung auf "gefährliche" Inhalte. Habe ich es richtig verstanden, dass ich dieses Feature garnicht nutzen kann, da meine Appliance lediglich mit einer 8GB SD Karte läuft (und es Probleme geben wird mit den Disk writes bei einer SD Karte)?

Oder hab ich das falsch verstanden und das gilt nur für den Caching Proxy?

Für die Analyse muss nichts niedergeschrieben werden, das kann im RAM passieren - wenn genug da ist, git das auch für dien Cache. Ich habe eine Vollinstallation auf einer SD-Karte und diese funktioniert auch sehr gut - man sollte nur nicht zu viele Dienste aktivieren, die häufig auf die Karte schreiben - für solche Dinge muss man dann auf eine RAM-Disk ausweichen.

Wenn die Analyse (zusätzlich) auf einem anderen Host passieren soll, kann dafür ICAP verwendet werden (Virenscanner etc.).

[guest15032]

Hi Dirk,

grundsätzlich sollte man bei einer SD-Installation eines der Nano-Images verwenden (VGA/seriell).
Die Nano-Images sind speziell für CF-, SD-Karten und minimieren die Schreibzugriffe auf die Karten. Man kann natürlich auch eine Vollinstallation auf SD-Karte machen. Wie lange die SD-Karte dann durchhält???

Jap, ich habe ein Nano Image installiert.

Den Webbroxy kannst Du unabhängig vom verwendeten Installationsimage der OPNSense benutzen. Das Caching des Proxy kannst Du in der Proxykonfiguration aktivieren/deaktivieren. Beim Nano-Image läuft das Caching dann halt im RAM (RAM-Disk). Siehe dazu hier: https://forum.opnsense.org/index.php?topic=4227.0
Standardmäßig ist das Caching beim Proxy deaktiviert (beim Nano-Image).

Ok, Danke. Du hast dem Thread nach auch eine Karten Installation laufen? Bist damit insgesamt zufrieden? Ooder hast Du irgendwelche "Bottlenecks", in Punkto Performance, gefunden?

Hi fabian,

Für die Analyse muss nichts niedergeschrieben werden, das kann im RAM passieren - wenn genug da ist, git das auch für dien Cache. Ich habe eine Vollinstallation auf einer SD-Karte und diese funktioniert auch sehr gut - man sollte nur nicht zu viele Dienste aktivieren, die häufig auf die Karte schreiben - für solche Dinge muss man dann auf eine RAM-Disk ausweichen.

Danke.

Also mein System hat 2GB RAM, davon sind knapp 10% genutzt.  Reicht der Rest für ein gutes Caching?

Wann werden denn eigentlich /tmp und /var genutzt bei der Installation? Die haben bei mir jeweils 1,5GB und sind fast komplett ungenutzt.


Mal was ganz anderes:

Fällt nur mir das auf, dass heute Seitenaufrufe teilweise sehr lange dauern? ich dachte, es hätte was mit dem Netzwerk in der Arbeit zu tun, aber auch zu Hause lahmt alles irgendwie...

Gruß
Chris

[Oxygen61]

@ne0h
Weil du vorhin gefragt hattest hier nochmal zur Vollständigkeit meine Antwort.
Diese hijacked Webseiten, werden als .txt Liste voller IPs in die Firewall eingehämmert.
Da gibt es zum einen die DROP Liste von Spamhaus, die "Spammer/Spambots" jedoch ausschließt
und wirklich nur übernommene, Bot-Rechner und gehackte Server usw. blockt.
Die EDROP Liste ist sozusagen noch ein Zusatz für die zurzeit bekannten Spambots.
Diese Listen sollte man täglich updaten.

Alles weitere zur Einrichtung und Tipps dazu findest du hier:
https://docs.opnsense.org/manual/how-tos/edrop.html

In deinem Fall musst du diese Listen also outbound (Destination: diese Listen als Alias)
in deine LAN und WLAN Regeln mit einfließen.
Ggf. noch auf dem WAN Interface inbound (Source: Alias), so wie ich das gemacht hatte.
(Ist aber wie gesagt nur notwendig, wenn du mal vorhast einen Server aus deinem internen Netz öffentlich zugänglich zu machen.)

Zum SD Karten Thema kann ich leider nix beisteuern. :P

[guest15032]

@Oxy,

Danke für die Erklärung.

Ich habe jetzt endlich mein Basis Ruleset angelegt, im Prinzip also alles, was ihr empfohlen habt. Ich habe auch mal getestet und bisher scheinen alle Basisdienste zu laufen, alle Websites, Messenger, etc. funktionieren.

Hab die Regeln als Anhang hier dran.

Dazu würde ich gerne wissen:

Was ist denn der Unterschied zwischen den Aliasen "WLAN net" und "WLAN address"?  Ich habe ja direkt mit dem Subnetz gearbeitet, aber bei monstermania hatte ich gesehen, dass da z.B. für das interne DNS von Source Bridge net nach Source Bridge address die Regeln erstellt sind.

Außerdem habe ich jetzt erst mal immer Destination ANY für die Basisdienste eingetragen. Aber würde z.B. bei HTTP/HTTPS als Destination nicht auch WAN (bzw. genauer WAN net/WAN address) sicherer sein? Denn bedeutet das im Moment nicht auch, dass ein WLAN Client über Port 80 oder 443 auch auf mein LAN zugreifen kann (also auf z.B. meine NAS auf Port 443) ?

Ich denke da an sowas:

HTTP/HTTPS -> Source: 192.168.0.1/24 -> Destination: 192.168.192.65/32

192.168.192.65/32 ist ja die statische WAN Interface IP.

Oder wird das nicht funktionieren?

Gibt es auch eine genauere Erklärung für die ganzen Destination Aliase? Z.B. was "This Firewall" genau sein soll?

Gruß
Chris

[Oxygen61]

Ein paar Sachen kann ich vielleicht noch erklären. Den Rest macht dann sicher monstermania morgen. :)
"WLAN Net" ist das WLAN Subnetz was am WLAN Interface der Firewall hängt.
Also (wahrscheinlich) ist WLAN Net in deinem Fall einfach nur dein WLAN Netz 192.168.1.0/24.
WLAN address hingegen ist die IP des WLAN Interfaces an deiner Firewall.
An dieser Stelle hast du sozusagen "Glück",
dass das WLAN Interface logischerweise Teil deines WLAN Subnetzes ist,
weshalb NTP und DNS funktionieren.
Besser wäre es jedoch die Destination auf die WLAN Interface IP zu beschränken...
also: <hier IP eingeben>/32 oder WLAN address.

Ich hatte ja schon mal erklärt, dass die Clients im Netz alle Informationen über NTP, DNS und Gateway von dem DHCP Server kriegen,
welcher auf dem WLAN Interface läuft.
Demnach ist es wie gesagt völlig ausreichend wenn die DNS und NTP Verbindungen "nur" bis zum WLAN Interface reichen für die Clients, denn nur dahin sollen die Clients kommunizieren dürfen um mit dem DNS oder NTP Dienst sprechen zu können.

Wegen deiner WAN Idee:
Die Server die du ansprechen möchtest stehen ja nicht innerhalb deines WAN Subnetzes, dass ist ja sozusagen noch Teil deines privaten Netzes. Das ist anders nicht umsetzbar. Deshalb muss man bevor man diese PERMIT HTTP ANY Rule am Ende setzt vorher überlegen inwieweit man diese einschränken kann, wie z.b. durch diese Spamhaus Listen usw.

Denn bedeutet das im Moment nicht auch, dass ein WLAN Client über Port 80 oder 443 auch auf mein LAN zugreifen kann (also auf z.B. meine NAS auf Port 443) ?

Genau das bedeutet es. Deshalb blockt man sämtliche Verbindung vom WLAN Netz ins LAN Netz und andersherum und überlegt sich dann, welche Geräte sollen denn miteinander kommunizieren dürfen?
Dann fängst du an z.B. eine Regel zu schreiben die einem bestimmten Gerät aus dem WLAN Netz über 443 die Kommunikation mit dem NAS im LAN Netz erlaubt.
So wie du jetzt die Regeln formuliert hast, hättest du auch bei der Bridge Idee bleiben können. :D

Diese Regeln die du da geschrieben hast, kannst du "so" in der Art nur so frei formulieren, weil monstermania keine Trennung zwischen den beiden Interface Subnetzen gemacht hatte.
Bei ihm bedeutet die HTTP Freischaltung nach ANY halt tatsächlich die Freischaltung ins Internet.

Was bedeutet das also:
Du musst noch vor dieser Rule aber sagen:
DENY Source: WLAN Net Destination: LAN Net Prot: ANY
Auf der LAN Seite natürlich andersherum.
Dadurch hast du sichergestellt, dass diese DENY Regel vor der HTTP Freischaltung greift.
Fängst du vor dieser DENY Regel jetzt an spezielle Kommunikationen zwischen deinen beiden Subnetzen zuzulassen,
greifen diese immer zu erst, noch bevor am Ende dann HTTP nach ANY (also auch ins Internet) erlaubt wird.
Also:
Die Reihenfolge ist super wichtig damit du nicht ausersehen zu viel erlaubst.
1) spezielle Regeln -> z.b. Gerät A im WLAN Netz darf mit dem NAS im Lan Netz reden auf Port 443
2) Deny Regel die sämtlichen anderen Traffic vom WLAN Netz ins LAN Netz blockiert
3) andere Block Regeln die sinnvoll sein könnten
4) Dann erst die sehr "offen" formulierte "erlaube HTTP Traffic nach ANY" Regel

HTTP/HTTPS -> Source: 192.168.0.1/24 -> Destination: 192.168.192.65/32
192.168.192.65/32 ist ja die statische WAN Interface IP.
Oder wird das nicht funktionieren?

Mir hilft es immer wenn ich die regeln laut ausspreche und mir überlege, was ich damit denn überhaupt aussagen will. Was diese Regel nun sagt ist, dass innerhalb des 192.168.0.1/24 Subnetzes über HTTP und HTTPS auf dein WAN Interface zugegriffen werden kann und somit die GUI Einlogg Oberfläche einsehbar ist.
Nicht mehr und nicht weniger. :)

"This Firewall" würd ich auch gern mal wissen, was da dahinter steckt. :-/

[fabian]

Danke.

Also mein System hat 2GB RAM, davon sind knapp 10% genutzt.  Reicht der Rest für ein gutes Caching?

Wann werden denn eigentlich /tmp und /var genutzt bei der Installation? Die haben bei mir jeweils 1,5GB und sind fast komplett ungenutzt.

Ich habe bei mir den Cache im RAM - 1/2 GB reicht da für den Betrieb daheim aus und ich habe 4GB. Das Meiste ist auch bei mir frei. Du solltest nur vorsichtig sein, wenn du auch die IDS nutzen willst. Die braucht einiges an RAM.

[guest15032]

Guten morgen,

"WLAN Net" ist das WLAN Subnetz was am WLAN Interface der Firewall hängt.
Also (wahrscheinlich) ist WLAN Net in deinem Fall einfach nur dein WLAN Netz 192.168.1.0/24.
WLAN address hingegen ist die IP des WLAN Interfaces an deiner Firewall.
An dieser Stelle hast du sozusagen "Glück",
dass das WLAN Interface logischerweise Teil deines WLAN Subnetzes ist,
weshalb NTP und DNS funktionieren.
Besser wäre es jedoch die Destination auf die WLAN Interface IP zu beschränken...
also: <hier IP eingeben>/32 oder WLAN address.

Sowas in der Art dachte ich mir auch schon. Werde das ändern.

Genau das bedeutet es. Deshalb blockt man sämtliche Verbindung vom WLAN Netz ins LAN Netz und andersherum und überlegt sich dann, welche Geräte sollen denn miteinander kommunizieren dürfen?
Dann fängst du an z.B. eine Regel zu schreiben die einem bestimmten Gerät aus dem WLAN Netz über 443 die Kommunikation mit dem NAS im LAN Netz erlaubt.
So wie du jetzt die Regeln formuliert hast, hättest du auch bei der Bridge Idee bleiben können. :D

Diese Regeln die du da geschrieben hast, kannst du "so" in der Art nur so frei formulieren, weil monstermania keine Trennung zwischen den beiden Interface Subnetzen gemacht hatte.
Bei ihm bedeutet die HTTP Freischaltung nach ANY halt tatsächlich die Freischaltung ins Internet.

Was bedeutet das also:
Du musst noch vor dieser Rule aber sagen:
DENY Source: WLAN Net Destination: LAN Net Prot: ANY
Auf der LAN Seite natürlich andersherum.
Dadurch hast du sichergestellt, dass diese DENY Regel vor der HTTP Freischaltung greift.
Fängst du vor dieser DENY Regel jetzt an spezielle Kommunikationen zwischen deinen beiden Subnetzen zuzulassen,
greifen diese immer zu erst, noch bevor am Ende dann HTTP nach ANY (also auch ins Internet) erlaubt wird.
Also:
Die Reihenfolge ist super wichtig damit du nicht ausersehen zu viel erlaubst.
1) spezielle Regeln -> z.b. Gerät A im WLAN Netz darf mit dem NAS im Lan Netz reden auf Port 443
2) Deny Regel die sämtlichen anderen Traffic vom WLAN Netz ins LAN Netz blockiert
3) andere Block Regeln die sinnvoll sein könnten
4) Dann erst die sehr "offen" formulierte "erlaube HTTP Traffic nach ANY" Regel

Mh... Ja, macht Sinn.

Ich formuliere das mal eben in meinen Worten um zu sehen, ob ich das verstanden habe:

Wie ich ja inzwischen weiß ^^, steht am Ende immer die DENY ANY ANY Regel. Also ist damit ja die Kommunikation zwischen den Subnetzen, sofern noch keine andere Regel das vorher aufhebt, blockiert. Jetzt habe ich mit meinem HTTP/HTTPS -> any diese immer greifende DENY ANY ANY Blockierung zwischen den Subnetzen auf Port 80 und 443 aufgehoben, weil ich damit ja sage, jedes Gerät kann aus meinem WLAN Subnetz (Source: WLAN net) in jedes andere Netz (Destination: any) über Port 80/443.

Da ich aber als erstes möchte, dass die WLAN Clients nur ins Internet kommen und nicht in mein LAN Subnetz, muss ich vor der HTTP/HTTPS -> any Regel explizit die Kommunikation von Subnetz zu Subnetz blockieren.

Sprich, vereinfacht sieht das so aus:

1. DENY source:WLAN net -> destination: LAN net -> port: any
2. PASS source:WLAN net -> destination: any -> port: HTTP/HTTPS

Korrekt?


Jetzt kommt der Teil, den ich noch nicht ganz verstehe, der sich aber daraus ja logisch ableiten muss:

Die Firewall evaluiert die Regeln ja nach dem "First Match" Prinzip. Die erste Regel, die zutrifft, wird auch ausgeführt. Das bedeutet also, die Firewall geht die Regeln von oben nach unten durch. Dann trifft sie auf die Regel Nr. 1 und blockiert jegliche Kommunikation (also jeden Port) vom WLAN Subnetz ins LAN Subnetz (das tat sie zwar auch schon vorher, durch die immer letzte DENY ANY ANY Regel aber es geht ja glecih noch weiter).

Darauf folgt dann die Regel Nr. 2, die Firewall lässt die Kommunikation vom WLAN Netz über Port 80 und 443 in ALLE Netze zu (destination: any, damit der Datenverkehr ins Internet durchgelassen werden kann), aber die vorherige Regel wird damit nicht wieder aufgehoben. Korrekt soweit?

Hier nämlich liegt grade mein Denkfehler, ich schaue momentan nur auf die formulierte Regel und habe die Reihenfolgen ausser acht gelassen. Die Firewall "merkt" sich also alles, was sie vorher evaluiert hat und baut das Regelwerk stufenweise darauf auf. Was zuvor blockiert wurde, kann und wird danach nicht durch eine allgemeine Freischaltung aufgehoben.

Hier Frage ich mich aber, warum kann so ein Prozess nicht deutlich einfacher gestaltet werden?

Die DENY ANY ANY Regel am Schluss verbietet doch erst mal alles. Wieso kann man nicht eine einzige Regel schreiben, die ausschließlich den Traffic von WLAN Subnetz ins Internet (destination: internet) erlaubt auf Port 80/443 und fertig? Oder andersrum gefragt, warum gibt es als Destination kein "internet" oder wie auch immer man es nennen würde?

Everything that isn't explicitly passed is blocked by default.

Man müsste sich doch garnicht erst um das Blockieren daer Subnetze untereinander bemühen, um danach den Traffic auf "any" zu erlauben. Man müsste doch nur noch den Traffic ganz spezifisch erlauben und der Rest wird eh geblockt.

Denke ich hier wieder falsch rum?

Und was ich mich auch noch frage, ist: Wenn ich momentan durch meine Regeln alles  erlaube, wearum kommt dann ein Ping von meinem WLAN Netz am LAN Interface nicht an? Ich habe am LAN Interface momentan noch eine ALLOW ANY ANY Regel, um das schrittweise zu machen und um zu testen,  ob die Kommunikation von WLAN ins LAN problemlos geht (ich will mir das einfacher dadurch machen und erst mal das WLAN sauber konfigurieren und dann das LAN).

Sollte daher ein Ping vom WLAN Subnetz ans LAN Interface nicht schon funktionieren?

Gruß
Chris

[guest15032]

Ich habe bei mir den Cache im RAM - 1/2 GB reicht da für den Betrieb daheim aus und ich habe 4GB. Das Meiste ist auch bei mir frei. Du solltest nur vorsichtig sein, wenn du auch die IDS nutzen willst. Die braucht einiges an RAM.

Alles klar. :)

[Oxygen61]

Sprich, vereinfacht sieht das so aus:

1. DENY source:WLAN net -> destination: LAN net -> port: any
2. PASS source:WLAN net -> destination: any -> port: HTTP/HTTPS

Korrekt?

Genau. :) Die Firewall vergleicht Source und Destination IP im ankommenden Paket und sieht das du z.b. auf Port 443 zugreifen möchtest. Dadurch, dass du vor der Destination ANY Regel aber diese durch die Regel davor eingegrenzt hast, würde diese DANN nicht greifen WENN im Destination Feld eine IP aus dem LAN Netz steht.

Darauf folgt dann die Regel Nr. 2, die Firewall lässt die Kommunikation vom WLAN Netz über Port 80 und 443 in ALLE Netze zu (destination: any, damit der Datenverkehr ins Internet durchgelassen werden kann), aber die vorherige Regel wird damit nicht wieder aufgehoben. Korrekt soweit?

Regeln werden nicht "aufgehoben". Entweder sie "matchen" oder eben nicht. Falls die DENY WLAN Subnetz --> LAN Subnetz nicht matched, weil im Destination Feld keine IP aus dem LAN Netz steht, greift diese auch nicht und die Regel danach, die Destination: ANY Regel erlaubt dann die Verbindung zu jeder anderen IP auf Port 80 oder 443 die du in diesem Moment angewählt hattest.

...wird danach nicht durch eine allgemeine Freischaltung aufgehoben.

Richtig. Wenn eine Regel gematched hat, ist die Suche vorbei und alle anderen Regeln werden nicht mehr betrachtet.

Die DENY ANY ANY Regel am Schluss verbietet doch erst mal alles. Wieso kann man nicht eine einzige Regel schreiben, die ausschließlich den Traffic von WLAN Subnetz ins Internet (destination: internet) erlaubt auf Port 80/443 und fertig? Oder andersrum gefragt, warum gibt es als Destination kein "internet" oder wie auch immer man es nennen würde?

Genau das is das Problem. Wie würdest du denn "Internet" definieren? Eine Firewall is doof wie Stulle.... die hat zwei IP (Source und Destination), hat zwei Ports (Source und Destination Port) und weiß ob outbound oder inbound. Anhand dieser Dinge entscheidet sie JA oder NEIN. Deine Aufgabe als Netzwerk Admin ist es nun durch clevere Regelformulierungen der Firewall "Intelligenz" beizubringen.
Besser gesagt.. welche IPs hat denn "Internet"?
Woher soll die Firewall wissen, welche IPs nicht das Internet sein sollen?

Man müsste sich doch gar nicht erst um das Blockieren der Subnetze untereinander bemühen, um danach den Traffic auf "any" zu erlauben. Man müsste doch nur noch den Traffic ganz spezifisch erlauben und der Rest wird eh geblockt.

Genau... aber das Internet ist eben nicht Spezifisch.. es gibt ja keine "Internet-IP" ;)
Sobald du keine "PERMIT Source:irgendwas --> Destination: ANY" schreibst, brauchst du dir auch weniger Gedanken um das Blocken machen.
Außerdem musst du auch immer davon ausgehen, dass Firewalls in Firmen uuuunzählige IPs/Subnetze und Dienste zu laufen haben. Dementsprechend müssen die Regeln einfach von Hause aus offener formuliert werden um nicht 1000 Regel-Einträge zu haben. Um dann aber trotzdem die Freischaltungen eingrenzen zu können, blockt man so "großflächig" wie es geht... Subnetz zu Subnetz...... Inbound gar kein Traffic usw...

Sollte daher ein Ping vom WLAN Subnetz ans LAN Interface nicht schon funktionieren?

Wie war nochmal deine Regel formuliert?
Permit -> ICMP -> Source: WLAN Net -> Destination: LAN Net ??

[guest15032]

Hi Oxy,

Richtig. Wenn eine Regel gematched hat, ist die Suche vorbei und alle anderen Regeln werden nicht mehr betrachtet.

Ja, das habe ich im Nachhinein auch so verstanden. Ich hatte einen Denkfehler, ich habe die Daten als "Stream" gesehen (was sie prinzipiell auch sind) und angenommen, dass die Firewall jedes Datenpaket nacheinander durchgeht und die Regeln anwendet und zwar jede Regel die möglich ist.

Es ist aber ja so, dass die Firewall jedes Pakte einzeln betrachtet und ganz stumpf schaut: passt die Regel? Wenn Ja, mach was in der Regel steht. Ende. Wenn Nein, schau in die nächste Regel.

Einfacher gesagt: Ich hatte angenommen, dass jedes Datenpaket den kompletten Regelsatz durchwandert, auch wenn  eine Regel bereits gematcht hat. Blöde Annahme, anders macht es natürlich Sinn.  ;D

Genau das is das Problem. Wie würdest du denn "Internet" definieren? Eine Firewall is doof wie Stulle.... die hat zwei IP (Source und Destination), hat zwei Ports (Source und Destination Port) und weiß ob outbound oder inbound. Anhand dieser Dinge entscheidet sie JA oder NEIN. Deine Aufgabe als Netzwerk Admin ist es nun durch clevere Regelformulierungen der Firewall "Intelligenz" beizubringen.
Besser gesagt.. welche IPs hat denn "Internet"?
Woher soll die Firewall wissen, welche IPs nicht das Internet sein sollen?

Bei längerem Nachdenken, ist das durchaus etwas, das problematisch ist, ja. Mir ist klar, dass ich nicht der erste bin, der sich solche Fragen stellt und dutzende schlaue Leute haben Firewalls gerade deswegen so implementiert, wie sie heute sind. ;) Aber ich gehe an sowas einfach gerne etwas naiver ran, weil ich so selbst mein Verständnis langsam verbessern kann. Simple Fragen um die Grundlagen zu verstehen.... ;)

Ich habe z.B. gedacht, dass eine Firewall dann an letzter Stelle, also am Interface, an dem es raus ins Internet geht, eine Art Indextabelle (Lookup table) führt, die auf Basis der package inspection und der Details pro Paket entscheiden kann, ist das ein Datenpaket für das interne Netz (IP Bereich, Subnetzmaske, etc.) oder   geht es raus in ein "anderes" Netz. Aber das wird schon seinen Grund haben, warum das nicht geht.

Genau... aber das Internet ist eben nicht Spezifisch.. es gibt ja keine "Internet-IP" ;)
Sobald du keine "PERMIT Source:irgendwas --> Destination: ANY" schreibst, brauchst du dir auch weniger Gedanken um das Blocken machen.

Jau. Ich werde mir das angewöhnen, so spezifisch wie möglich zu sein bei den Regeldefinitionen und dann (wie Du geschrieben hast), nach unten hin die "lockeren" Regeln zu schieben.

Wie war nochmal deine Regel formuliert?
Permit -> ICMP -> Source: WLAN Net -> Destination: LAN Net ??

Ja, das war blöd. :D Ich hatte mir das gestern Abend noch mal angesehen und dann entsprechend ICMP vom WLAN ins LAN freigegeben. Und siehe da, ich kann pingen. ^^

Ich hatte auch die DNS und NTP Regeln angepasst, und diese auf die IP des WLAN interface gebunden.

Was mir wieder Kopfzerbrechen bereitet, ist mein nächster Task.

Ich möchte meine Sonos Netzwerk Boxen wieder ansprechbar machen. Ich nutze ein Setup, in dem eine "Wireless Bridge" (http://www.sonos.com/de-de/shop/boost.html) sozusagen ein eigenes internes Netz zu den Boxen aufspannt (aber natürlich nutzen die Boxen auch das bereits vorhandene WLAN, das ganze wäre auch ohne die Bridge lauffähig. Die Bridge kann einfach, bei schlechtem WLAN, selbst als Access Point für die Boxen fungieren). Diese Bridge hängt per LAN an meinem LAN Interface, oder um es noch genauer zu formulieren (damit es keine Missverständnisse gibt), am Switch, der wiederum am LAN Port des LAN Interfaces hängt. .

Zuvor war es so, dass ich das Gerät an meinem ehemaligen Router angeschlossen hatte. Als ich vor kurzem die Bridge (hier meine ich die Bridge in der Firewall! Also als ich LAN und WLAN zusammengefasst hatte) noch eingerichtet hatte, war das Gerät sowie die Sonos Boxen - wie auch im alten Zustand mit dem normalen Router - im ganzen Netzwerk sichtbar.

Jetzt muss ich ja dafür sorgen. dass ich zum einen von meinem WLAN Subnetz aus zu der Sonos Bridge kommunizieren kann und zum anderen, dass die Sonos Geräte nach draußen (ins Internet) kommunizieren können, um die Musik zu streamen.

Da ich ja noch  die ALLOW ANY ANY Regel in meinem LAN Subnetz habe (ja, die wird bald raus fliegen, keine Sorge! ;) ), gehe ich davon aus, dass die Sonos Bridge komplett nach außen kommunizieren kann.  Dass ich die Sonos Bridge in meinem WLAN Netzwerk nicht sehen kann, ist klar, da ich hier (https://sonos.custhelp.com/app/answers/detail/a_id/692/~/configuring-your-firewall-to-work-with-sonos) gelesen habe, welche Ports die Sonos Geräte nutzen.

Dort steht, dass ich für den Sonos Controller (also die App auf meinem Smartphone) Port 3500 benötige (unter Android).

Ich hatte also mal testweise an meinem WLAN Interface eine Regel geschrieben:

PASS source: any -> destination: WLAN subnetz -> Port: 3500

Source any würde ich im zweiten Schritt in Seource: LAN subnetz ändern, ich möchte es grade einfach halten.

Auf meinem Smartphone kann ich mit einer App, die meine Netzwerkverbindungen überwacht, sehen, dass mein Smartphone auf Port 3500 "lauscht" und auf eine verbindung wartet. Wenn ich die Sonso Controller App öffne, dann sucht diese ein paar Sekunden lang, findet aber kein Sonos System.

Das wird (hoffentlich) an den ganzen anderen Ports liegen, die ich noch nicht geöffnet habe (und auch nicht alle öffnen will und werde). Aber wie aus dem Link ersichtlich ist, werden z.B. auch die Ports

1900 (UPnP events and device detection)
1901 (UPnP responses)

benötigt.

Kann es sein, dass darin auch der Grund liegt, dass ich die Boxen (die ja, entgegen der Sonos Bridge, die in meinem LAN Subnetz ist) nicht im WLAN sehe? Den die müssten ja da sein, die Boxen haben immer eine Verbindung zu meinem normalen WLAN im Haus.

Außerdem schließen sich daran noch zwei weitere Punkte an:

1. Gibt es in der Firewall irgendeine Übersicht über alle Clients, die in einem Subnetz eine Adresse zugewiesen bekommen haben? Denn ich sehe ja aktuell noch keines der anderen Geräte im LAN. Wenn ich z.B. mit einer simplen App das Netzwerk scanne (mit meinem Smartphone) oder z.B. mit nmap von meinem Rechner aus, dann sehe ich ja nur die Geräte im WLAN Subnetz. Klar, wenn ich meinen Rechner per LAN Kabel an den Switch schalten würde, würde ich dort alle Geräte sehen. Aber das möchte ich ja nicht jedes Mal tun, es müsste dafür doch einen Punkt im Interface der Firewall geben, oder?

2. Mache ich mir das Leben nicht erheblich einfacher (so gern ich an der Firewall auch konfiguriere und lerne), wenn ich diese Sonos Bridge einfach vom LAN Switch an den WLAN Access Point stöpsel? Dann wäre das Gerät ja im selben Subnetz und ich hätte erheblich weniger Aufwand, weil ich keine Regeln von LAN Subnetz zu WLAN Subnetz erstellen müsste. Zumal ich überlege, welchen Vorteil ich davon habe, die Sonos Bridge im LAN Subnetz zu lassen? Die jeweiligen Ports kann ich ja aus jedem Subnetz heraus erlauben und auch blocken.

Gibt es hierzu auch eine "Best Practice", warum ich die Sonos Bridge im LAN Subnetz lassen sollte/könnte/müsste?

Für mich hat diese Geschichte so einen kleinen Sonderstatus, was die Einteilung in ein Subnetz betrifft. Denn der Sinn ist ja eben, ein Musikstreaming per Funknetz zu haben. Darum wäre es für mich auch die einzige Ausnahme, was das Anschließen des Gerätes per LAN Kabel am WLAN Access Point betrifft.

Wie seht/scannt/findet ihr denn alle eure Geräte, die in unterschiedlichen Subnetzen unterwegs sind?

Gruß
Chris

[fabian]

1. Gibt es in der Firewall irgendeine Übersicht über alle Clients, die in einem Subnetz eine Adresse zugewiesen bekommen haben? Denn ich sehe ja aktuell noch keines der anderen Geräte im LAN. Wenn ich z.B. mit einer simplen App das Netzwerk scanne (mit meinem Smartphone) oder z.B. mit nmap von meinem Rechner aus, dann sehe ich ja nur die Geräte im WLAN Subnetz. Klar, wenn ich meinen Rechner per LAN Kabel an den Switch schalten würde, würde ich dort alle Geräte sehen. Aber das möchte ich ja nicht jedes Mal tun, es müsste dafür doch einen Punkt im Interface der Firewall geben, oder?

Am einfachsten ist es, den ARP- und NDP-Cache der Firewall zu lesen. Dazu muss unter umständen zuerst versucht werden, mit allen Computern eine Verbindung aufzubauen. Alternativ kann man ja auch nmap nmap auf OPNsense starten.

[Oxygen61]

Ich habe z.B. gedacht, dass eine Firewall dann an letzter Stelle, also am Interface, an dem es raus ins Internet geht, eine Art Indextabelle (Lookup table) führt, die auf Basis der package inspection und der Details pro Paket entscheiden kann, ist das ein Datenpaket für das interne Netz (IP Bereich, Subnetzmaske, etc.) oder   geht es raus in ein "anderes" Netz. Aber das wird schon seinen Grund haben, warum das nicht geht.

Natürlich geht das. Du musst bloß deine Regeln dementsprechend formulieren...
Die "Lookup Tabelle" ist ja genau dein ausformuliertes Regelwerk.
ANY heißt halt nun mal ALLES...
Nich böse gemeint, aber wenn du selber nicht weißt wie dein Traffic ins interne Subnetz soll, woher soll die Firewall das dann wissen? Wenn du sagst "erlaube alles nach HTTP", kann die Firewall doch nich Gedanken lesen und "erahnen" was du wirklich meintest. :D
Deshalb sind die Formulierungen der Regeln ja auch mit das Schwerste und Wichtigste an einer Firewall. :)

Willst du noch mehr Kontrolle und tatsächlich in JEDES Datenpaket schauen um JEDEN Dateninhalt auszulesen, musst du dir eine Firewall suchen, die ein sogenanntes "Deep Packet Inspection" betreibt.
In der Türkei wird so zurzeit verhindert, dass Leute VPN Server oder Tor Services ansprechen können.
Ziemlich mächtiges Tool, mit der Einschränkung, dass du als Administrator so einer Firewall dann natürlich 24/7 arbeiten musst, um saubere Regeln zu formulieren. ;)
Völlig sinnfrei also für ein Home Netzwerk. :) SPI ist schon das sinnvollste was man zurzeit machen kann.
Weiteres zum Nachlesen hier: http://www.itwissen.info/definition/lexikon/DPI-deep-packet-inspection.html

Jau. Ich werde mir das angewöhnen, so spezifisch wie möglich zu sein bei den Regeldefinitionen und dann (wie Du geschrieben hast), nach unten hin die "lockeren" Regeln zu schieben.

Genau. Die Chance, dass man dann was übersehen hat ist halt eingegrenzt. :)
Wichtig ist am Ende immer eine Art Testprotokoll zu führen. Du schließt also Geräte an die jeweiligen Subnetze an und versuchst deine eigenen Regeln auszutricksen/zu testen und schaust ob das erwartete Ergebnis rauskommt.
Falls nicht versuchst du deine Regeln so umzuformulieren, dass es passt.
(Diese Stelle hasse ich immer :D)

Zu Sonos kann ich dir leider gar nichts sagen, da ich da keine Erfahrungen mit machen konnte.
Kann dir also nich sagen was man da machen kann oder sogar sollte.
Wegen den Regeln würde ich erst einmal alle hinschreiben, probieren ob alles funktioniert und dann Regel für Regel deaktivieren und schauen, ob es immer noch funktioniert. :)

Gibt es in der Firewall irgendeine Übersicht über alle Clients, die in einem Subnetz eine Adresse zugewiesen bekommen haben?

Ich bin mal ganz frech und sage "na klar" ;)
Das meintest du wahrscheinlich nicht, aber du kannst dir ja bei "Services > DHCP > Leases" die ausgegebenen IPs anzeigen lassen. Da müssten dann auch deine gemappten Einträge zu sehen sein z.B. :)

Wie seht/scannt/findet ihr denn alle eure Geräte, die in unterschiedlichen Subnetzen unterwegs sind?

Stichwort: Network Monitoring, bzw. Systembetriebs Überwachung.

Dafür gibt es zich Lösungen die eingesetzt werden um irgendeine Art "Übersicht" zu behalten.
Du könntest einen Syslog Server in dein Netz hängen, der alle Logs sammelt und verarbeitet.
In der Art weißt du zu mindestens etwas über deine Switche, Router und deine OPNsense Firewall.
OPNsense kannst du nämlich hier: "Services > SNMP" so konfigurieren,
dass es Nachrichten für deinen Syslog Server erstellt.

Dann gibt es noch Nagios (sehr wahrscheinlich viel zu umständlich für ein Home Netzwerk), mit welchem du echt ALLES bewerkstelligen kannst, wenns um Überwachung geht.
Eine einfachere Alternative wäre hier: Check_MK | siehe: https://mathias-kettner.de/check_mk.html

In Firmen kommt oft eine CMDB (Configuration Management Database) zum Einsatz:
"Ziele des Configuration Management sind:
Auskunft über alle IT-Komponenten und -Konfigurationen innerhalb des Unternehmens und seiner Services zu geben."
Auch das finde ich völlig sinn frei für ein Home Office, aber "möglich" wäre es. :)

Wie gesagt zum Rest kann ich nich viel sagen. Sorry! :(

Schöne Grüße
Oxy

[guest15032]

Moin zusammen,

Am einfachsten ist es, den ARP- und NDP-Cache der Firewall zu lesen. Dazu muss unter umständen zuerst versucht werden, mit allen Computern eine Verbindung aufzubauen. Alternativ kann man ja auch nmap nmap auf OPNsense starten.

Ich bin mal ganz frech und sage "na klar" ;)
Das meintest du wahrscheinlich nicht, aber du kannst dir ja bei "Services > DHCP > Leases" die ausgegebenen IPs anzeigen lassen. Da müssten dann auch deine gemappten Einträge zu sehen sein z.B. :)

Genau das mit den Leases meinte ich. Danke. Die Übersicht habe ich gesucht. Da konnte ich dann auch schnell alle Leases statisch mappen (was natürlich auch über die DHCP Einstellungenen am jeweiligen Interface geht).

Aber nmap direkt auf der OPNsense laufen lassen, ist natürlich auch ne gute Möglichkeit. :)

Natürlich geht das. Du musst bloß deine Regeln dementsprechend formulieren...
Die "Lookup Tabelle" ist ja genau dein ausformuliertes Regelwerk.
ANY heißt halt nun mal ALLES...
Nich böse gemeint, aber wenn du selber nicht weißt wie dein Traffic ins interne Subnetz soll, woher soll die Firewall das dann wissen? Wenn du sagst "erlaube alles nach HTTP", kann die Firewall doch nich Gedanken lesen und "erahnen" was du wirklich meintest. :D
Deshalb sind die Formulierungen der Regeln ja auch mit das Schwerste und Wichtigste an einer Firewall. :)

Ich meinte das noch etwas anders. ;) Auf einer anderen "Ebene" , ich hab das aus Entwicklersicht gedacht. Aber im Prinzip hast Du natürlich recht. So einfach ist es dann doch nicht.

Willst du noch mehr Kontrolle und tatsächlich in JEDES Datenpaket schauen um JEDEN Dateninhalt auszulesen, musst du dir eine Firewall suchen, die ein sogenanntes "Deep Packet Inspection" betreibt.
In der Türkei wird so zurzeit verhindert, dass Leute VPN Server oder Tor Services ansprechen können.
Ziemlich mächtiges Tool, mit der Einschränkung, dass du als Administrator so einer Firewall dann natürlich 24/7 arbeiten musst, um saubere Regeln zu formulieren. ;)
Völlig sinnfrei also für ein Home Netzwerk. :) SPI ist schon das sinnvollste was man zurzeit machen kann.

Jap, das ist mir ein bekannter Begriff. Natürlich völliger Overkill, aber spannende Thematik.

Zu Sonos kann ich dir leider gar nichts sagen, da ich da keine Erfahrungen mit machen konnte.
Kann dir also nich sagen was man da machen kann oder sogar sollte.
Wegen den Regeln würde ich erst einmal alle hinschreiben, probieren ob alles funktioniert und dann Regel für Regel deaktivieren und schauen, ob es immer noch funktioniert. :)

Also, ich habe diese Sonos Bridge jetzt einfach an meinen Access Point gehängt. Der ist dafür ja da und je mehr ich darüber nachgedacht habe, desto mehr Sinn machte es für mich. Das Musiksystem hat für mich nichts in meinem LAN verloren, ich kontrolliere die Boxen nur über Wireless Geräte und außer dem Streaming aus dem Internet soll das ganze nichts anderes machen. Ich streame z.B. keine Musik von einem lokalen Medienserver aus meinem LAN oder ähnliches. Von daher finde ich die Lösung genau richtig.

Nach dem Umstöpseln an den AP waren auch die Sonos Bridge und die  Boxen direkt sichtbar. Ich habe statische Leases vergeben und zu meinem Erstauenen brauchte ich auch keinerlei andere Ports freischalten für das Streaming.  Was mich ein wenig gewundert hat, da ja auf der Supportseite von Sonos die Portlisten stehen, die man freischalten soll.

Ich habe dann einfach mal getestet und festgestellt, dass das System offensichtlich nur Port 80, also HTTP, benötigt. Wenn ich diese Regel deaktiviere, dann kann ich nichts mehr streamen.

Was ich hier aber vermute, ist, dass das Freischalten der ganzen Ports dann nötig ist, wenn man die Boxen standalone betreibt. Ich glaube, dass diese Sonos Bridge "intern", also in ihrem "eigenen" Netz, die Boxen über ihre eigenen Ports ansteuert und nach außen hin scheint die das alles über Port 80 zu kapseln.

Anders kann ich es mir nicht erklären, da ich ja definitv keine Regelfreischaltungen erstellt habe auf dem WLAN Interface. Da besteht der Regelsatz wie auch zuvor, also die Standardports (HTTP, HTTPS, IMAP, etc.) von WLAN  Subnetz -> any. Und die implizite letzte DENY ANY ANY Regel blockt ja alles andere. Von daher wäre es mir ein Rätsel, wie das Streaming sonst funktioniert, wenn das nicht über die Sonos Bridge gekapselt wird.

Ich hänge noch mal meine aktuellen WLAN Interface Regeln an, so wie sie aktuell sind. Fehlt da etwas "grundlegendes", das ich gerade vergesse? Ich meine wirklich nur grundlegende Regeln, die ich grade völlig vergesse/übersehe.

Dazu fallen mir auch noch zwei Fragen ein:

1. Sollte man die Anti Lockout Rule nicht noch spezifischer machen? Die war ja standardmäßig angelegt. Sollte die nicht spezifisch als Source das LAN und WLAN Subnetz haben? 

2. Du, Oxy, hattest doch mal den Hinweis gepostet, dass man die NetBIOS Ports dicht machen sollte bei Windows Maschinen.Da ich dahingehend ja keine Freischaltungen habe, sind die doch durch die letzte DENY ANY ANY Regel dicht. Da sind wir doch wieder bei der Sache, dass alles geblockt wird, was nicht explizit erlaubt ist.

Warum sollte ich da also spezifische Block Regeln schreiben?

Ich überlege auch momentan, ob es jetzt Sinn macht, dass ich im WLAN Subnetz die Kommunikation auf Clients beschränke, oder ob ich die Regeln für das ganze Subnetz erlaube (wie es momentan ja ist)? Wie findet man das eine gute Lösung? Also, wann macht es Sinn, zu sagen, statt:

Source: WLAN Subnetz -> Destination: any -> Port: HTTP/HTTPS

mache ich:

Source: WLAN Client IP -> Destination: any -> Port: HTTP/HTTPS

Feste DHCP Leases habe ich ja, aber ist das paranoid? Oder genau richtig? Klar, der Anwendungsfall, wenn ich hier Gäste habe, die ich in mein WLAN lasse, müsste ich dann immer explizit freischalten. Was logischerweise dazu führt, dass man ein Gästenetz aufspannt.

Dafür gibt es zich Lösungen die eingesetzt werden um irgendeine Art "Übersicht" zu behalten.
Du könntest einen Syslog Server in dein Netz hängen, der alle Logs sammelt und verarbeitet.
In der Art weißt du zu mindestens etwas über deine Switche, Router und deine OPNsense Firewall.
OPNsense kannst du nämlich hier: "Services > SNMP" so konfigurieren,
dass es Nachrichten für deinen Syslog Server erstellt.

Dann gibt es noch Nagios (sehr wahrscheinlich viel zu umständlich für ein Home Netzwerk), mit welchem du echt ALLES bewerkstelligen kannst, wenns um Überwachung geht.
Eine einfachere Alternative wäre hier: Check_MK | siehe: https://mathias-kettner.de/check_mk.html

In Firmen kommt oft eine CMDB (Configuration Management Database) zum Einsatz:
"Ziele des Configuration Management sind:
Auskunft über alle IT-Komponenten und -Konfigurationen innerhalb des Unternehmens und seiner Services zu geben."
Auch das finde ich völlig sinn frei für ein Home Office, aber "möglich" wäre es.

Jap, Nagios und ein paar kleinere Tools kenne ich aus der Firma, das ist natürlich völlig übertrieben für meinen Fall zu Hause. Wie gesagt, mir reicht ja jetzt erst mal auch, dass ich die Lease Übersicht habe. Und das Monitoring kann ich ja mit z.B. einem nmap bewerkstelligen, zumindest das, was ich damit erreichen möchte. ;)


Bezüglich dem Proxy Thema (https://docs.opnsense.org/manual/proxy.html) noch mal ganz allgemein gefragt:

Nutzt ihr den Proxy?
Und wenn ja, als transparenten Proxy? Oder habt ihr alle Clients zu Hause mit Proxyeinstellungen versehen?
Und nutzt ihr den Proxy fürs Caching (egal ob RAM oder SSD) oder für die Webfilterung anhand von Sperrlisten?  Oder beides zusammen?

Schönen Sonntag zusammen!

Gruß
Chris

[Oxygen61]

Hey hey,

Fehlt da etwas "grundlegendes", das ich gerade vergesse?

Das kannst du nur herausfinden, indem du deine Regeln auf die Probe stellst.
Welche Verbindung sollte denn anhand deiner Regeln nicht mehr funktionieren?
Wenns dann doch klappt musst du dir überlegen warum.

1. Sollte man die Anti Lockout Rule nicht noch spezifischer machen? Die war ja standardmäßig angelegt. Sollte die nicht spezifisch als Source das LAN und WLAN Subnetz haben?

Die Antilockout Regel, also die Regel zum Schutz davor dich selbst auszusperren, hat nur einen Zweck.
Sie soll dafür sorgen, dass du aus deinem Management Subnetz, von welchem du auf die GUI zugreifst, immer Zugriff auf die Weboberfläche hast. Gerade am Anfang beim formulieren der Regeln, kann es schnell passieren, dass man eine Regel schreibt, die dich aussperren würde.
Im Idealfall hast du am Ende diese Regel deaktiviert und mit einer Regel ersetzt, die angemessener erscheint.

Beispiel Regel für das LAN Subnetz:
PASS --> KonfigurationsLaptop (statische IP) --> LAN Interface (WebGUI) --> Port 443 und 22
~ In diesem Fall würde dann nur noch ein Laptop aus deinem LAN Subnetz auf die Weboberfläche zugreifen können und über SSH auf die Shell.

hattest doch mal den Hinweis gepostet, dass man die NetBIOS Ports dicht machen sollte bei Windows Maschinen.

Genau. Innerhalb deines internen Netzes kann es ja gut und gerne sein, dass man die vielleicht mal braucht. Wichtig ist nur, dass diese nicht ins "äußere Netz / Internet" kommunizieren, was sie im Normalfall sonst machen.
Sind deine Regeln speziell genug formuliert hast du dieses Problem nicht.
In Firmennetzwerken schreibt man diese Regeln trotzdem hin,
einfach nur um sagen zu können: "ich hab sie hingeschrieben".

Ich überlege auch momentan, ob es jetzt Sinn macht, dass ich im WLAN Subnetz die Kommunikation auf Clients beschränke

Das ist abhängig von deiner Bequemlichkeit, davon abhängig wie oft dein Netzwerk sich ändert und ebenfalls davon abhängig wie groß dein Netz ist. Wenn es eine Regel gibt, die so oder so alle Geräte innerhalb eines Subnetzes benötigen, wäre es ja unsinnig diese eine Regel auf 20 Geräte zu verteilen.

wenn ich hier Gäste habe, die ich in mein WLAN lasse, müsste ich dann immer explizit freischalten. Was logischerweise dazu führt, dass man ein Gästenetz aufspannt.

Gäste haben in deinem WLAN nichts zu suchen. Die Frage nach Freischaltungen erübrigt sich dann.
Man macht ein Gästenetz auf, gibt ihnen einen Vouchercode und das wars. Das Gästenetz trennst du dann hart von deinen anderen Subnetzen und lässt ihnen da drinne ihren Freiraum für was auch immer.
(Um Quengeleien zu vermeiden)

Zum Thema Proxy hatte sich monstermania ja schon des öfteren zu geäußert.
Das ist abhängig davon, was du am Ende bei deinem Anwendungsfall bezwecken möchtest.
Das ist auch ein sehr OPNsense unspezifisches Thema.
Da gibt es sicher gute Pro/Contra Listen im Internet die dem Thema da kleinlichst auf die Spur gehen.
Mit nem Proxy kann man halt wieder zusätzlich viele "spaßige" Dinge machen um das Leben der Anwender "vielleicht" zu erschweren. Im Gegensatz dazu dient es als Möglichkeit der Überwachung (SSL-Proxy).
Wenn du alleine in deinem Netz bist, würde ich natürlich all das aufbauen, wozu ich Lust und Laune habe.
Mich selber Man-in-the-middle mäßig anzugreifen stört mich ja nicht.
Ob Freunde, WG Kumpels, Eltern oder wer auch immer noch in deinem Netz hängt davon so begeistert sind wage ich zu bezweifeln.

Schöne Grüße
Oxy

[guest15032]

Das kannst du nur herausfinden, indem du deine Regeln auf die Probe stellst.
Welche Verbindung sollte denn anhand deiner Regeln nicht mehr funktionieren?
Wenns dann doch klappt musst du dir überlegen warum.

Klar. ;) Es läuft alles so, wie ich es möchte. Ich dachte eher daran, ob ich was ganz gravierendes falsch ist. Aber ich meine heraus zu hören, dass da nichts "offensichtlich" falsch ist. ^^

Im Idealfall hast du am Ende diese Regel deaktiviert und mit einer Regel ersetzt, die angemessener erscheint.

Beispiel Regel für das LAN Subnetz:
PASS --> KonfigurationsLaptop (statische IP) --> LAN Interface (WebGUI) --> Port 443
~ In diesem Fall würde dann nur noch ein Laptop aus deinem LAN Subnetz auf die Weboberfläche zugreifen können.

Genau so war das gemeint. Nur noch ein Gerät mit fester IP mit Zugriff auf das Interface.

Genau. Innerhalb deines internen Netzes kann es ja gut und gerne sein, dass man die vielleicht mal braucht. Wichtig ist nur, dass diese nicht ins "äußere Netz / Internet" kommunizieren, was sie im Normalfall sonst machen.
Sind deine Regeln speziell genug formuliert hast du dieses Problem nicht.

Genau. Mit anderen Worten:

Wenn ich sie intern erlaube, achte ich darauf, sie nicht nach außen kommunizieren lassen. Und so lange ich sie nirgendes erlaube, sind sie sowieso immer geblockt.

Das ist abhängig von deiner Bequemlichkeit, davon abhängig wie oft dein Netzwerk sich ändert und ebenfalls davon abhängig wie groß dein Netz ist. Wenn es eine Regel gibt, die so oder so alle Geräte innerhalb eines Subnetzes benötigen, wäre es ja unsinnig diese eine Regel auf 20 Geräte zu verteilen.

Stimmt. Der letzte Punkt ist ein guter Hinweis. Da muss man einfach einen guten Mittelweg finden.

Gäste haben in deinem WLAN nichts zu suchen. Die Frage nach Freischaltungen erübrigt sich dann.
Man macht ein Gästenetz auf, gibt ihnen einen Vouchercode und das wars. Das Gästenetz trennst du dann hart von deinen anderen Subnetzen und lässt ihnen da drinne ihren Freiraum für was auch immer.
(Um Quengeleien zu vermeiden)

Ok, das war ja auch mein Gedanke.

Das würde ich dann machen, wie hier beschrieben:

https://docs.opnsense.org/manual/captiveportal.html
https://docs.opnsense.org/manual/how-tos/guestnet.html

Richtig?

Wenn ja, dann frage ich mich gerade ehrlich gesagt, wie ich denn ein Interface für das Gästeportal hinzufügen soll? Ich habe ja keine Interfaces mehr verfügbar. ^^ Oder ist damit irgendein "virtuelles" Interface gemeint? Ich habe ja nur drei Interfaces zur Verfügung, LAN, WLAN und WAN. Habe ich da was übersehen? :-/

Mit nem Proxy kann man halt wieder zusätzlich viele "spaßige" Dinge machen um das Leben der Anwender "vielleicht" zu erschweren. Im Gegensatz dazu dient es als Möglichkeit der Überwachung (SSL-Proxy).
Wenn du alleine in deinem Netz bist, würde ich natürlich all das aufbauen, wozu ich Lust und Laune habe.
Mich selber Man-in-the-middle mäßig anzugreifen stört mich ja nicht.
Ob Freunde, WG Kumpels, Eltern oder wer auch immer noch in deinem Netz hängt davon so begeistert sind wage ich zu bezweifeln.

Das stimmt. Ich mache das alles ja "nur" für mich. Und natürlich für die Frau im Hause. Gerade da ist es mir aber wichtig, zwar ein wenig rumspielen zu können um auszuprobieren, was ich tatsächlich brauche und was nicht und andererseits auch z.B. durch die Filterung von gefährlichen Dateien oder durch das Blocken anhand von Blacklists Sicherheit ins Netzwerk zu bekommen.

Das Caching würde ich auch nutzen, wobei das eher ein nice to have ist und nichts, was ich essentiell wichtig finde, da ich mich über die Performance hier nicht beschweren möchte. ;)

Gruß
Chris