Messages

In AGH habe ich dann eine Blocklist für DoH-Server abonniert. Da DoH immer erst mal ein konventioneller Lookup vorausgeht, ist das das Beste, was man m.E. tun kann.

Zur Ergänzung, wenn man noch eins drauf setzen möchte (auch aus meiner Sicht, sollte bereits das Blocken auf Domain-Ebene reichen): Es gibt zusätzlich zu den Blocklisten der DoH-Domains auch Listen mit IP-Adressen dieser Server (z.B. von HaGeZi oder DibDot aus dem OpenWRT-Umfeld).

Diese kann man dann einfach als Alias abonnieren und in den Firewall-Regeln verwenden.
Ein denkbares Problem wäre, dass auf den Servern auch noch andere Dienste laufen, welche man dann natürlich nicht mehr erreichen könnte. Aber in der Regel sind diese Server DoH-only.

Es gibt IoT Geräte, die haben eine DNS IP fix eingebrannt. Erreichen sie diese nicht, versagen sie den Dienst.

Ich weiß, solche Geräte hat man nicht, aber man weiß das erst nach dem vermeintlich günstigen Kauf und dann möchte man ein Lösung.

Du könntest noch anstatt DNS-Anfragen, welche nicht an deinen eigenen DNS-Dienst gehen, zu blocken diese Anfragen stattdessen umschreiben.
Sprich: Jegliches Paket aus dem LAN auf Port 53 was nicht an deinen Adblock-DNS-Server gerichtet ist, umleiten auf eben diesen.
Die Clients erhalten dann die Antwort nicht von dem Server den sie im Sinn hatten.
Aber Anfragen Richtung z.b. 8.8.8.8 kommen mit einer Antwort zurück.
Auf die Art erreichen die Clients ihren gewünschten Server scheinbar und sollten zufrieden sein, solange sie nicht die Authentizität des Servers anderweitig prüfen.

Dein Ansatz mit dem ungültigen Gateway fand ich auch clever und hab das gleich mal versucht.
Wollte dort 0.0.0.0 eingeben in der Hoffnung, dass sinnlose Pakete nicht erst das Gerät verlassen aber die Einstellungen der OpnSense meckerten da, dass das Gateway nicht im Subnetz des Client liegt.
Ist ja korrekt - hier aber eben doch so gewünscht.

Anstatt jetzt was anderes einzutragen, wie z.b. die IP-Adresse des Gerätes selbst, bin ich stattdessen über die config.yml gegangen und hab es direkt dort eingetragen.
Scheint bislang das zu tun was es soll.
Vielleicht als Tipp für jemanden der auch mal darüber stolpert.

Besten Dank.

Ich bin tatsächlich davon ausgegangen, dass der MAC-Alias nicht funktioniert, da man in die Regel selbst keine MAC-Adresse eintragen kann.

Ich hätte es tatsächlich stattdessen einfach mal probieren sollen anstatt hier einen Thread zu eröffnen.
Aber meine Frage ist damit super beantwortet - danke!

Blockieren kannst Du mittels der MAC

Exakt darum geht es mir ja hier: Wie?
Wie ich bereits schrieb habe ich bisher diesen Teil verpasst bei OpnSense.

Ich habe nur in einem alten Feature-Request gelesen, dass MAC-Adressen zur Filterung nicht untersützt werden.
Das hätte mich aber gewundert daher hier meine Nachfrage.
Bei den Alias hab ich das zwar schon gesehen aber da man keine MAC direkt in eine Regel schreiben kann bin ich davon ausgegangen, dass ein Alias dafür einzutragen nichts bringen würde - offensichtlich war meine Vermutung da falsch?

Das wäre das LAN.
IPv6 im LAN komplett zu verbieten sehe ich durchaus als Problem wenn es lediglich darum geht einzelnen Geräten den Zugriff aufs Internet zu blockieren.

Ich wollte mal erfragen wie mit solchen Fällen in OpnSense umgegangen ist bzw. wie die Grundphilosophie hierbei ist:

Angenommenes Beispiel:
Ich habe diverse Geräte im lokalen Netz, welche Teil der internen Kommunikation sein sollen aber keinen Kontakt ins Internet erhalten sollen.
Oder noch plastischer: Ein Fernseher soll nicht mit dem Internet kommunizieren dürfen, da eingeblendete Werbung doof ist aber gleichzeitig soll er mit anderen Geräten kommunizieren können, da er z.B. vom NAS streamen können soll oder er über`s Smart-Home gesteuert werden soll.

Erster (evtl. naiver) Ansatz: Eine Block-Regel Richung WAN bei der die Quelle die IPv4-Adresse des Fernsehers ist.
Grundsätzlich o.k., da man diesem ja eine feste IPv4-Adresse per DHCP zuweisen kann.

Mein Verständnisproblem folgt aber nun: Was ist mit IPv6-Kommunikation? Dort gibt es für mich ersichtlich keine feste IPv6-Adresse, welche ich in der Firewall-Regel hinterlegen könnte.
DHCPv6 ist kein Muss - der Fernseher kann auch über SLAAC seine Adressen beziehen, so dass eine wirklich feste Adresse nie garantiert ist.
Des Weiteren kann er ja auch von den Privacy Extensions Gebrauch mache und würfelt sich munter neue Adressen aus.
Und obendrauf ändert sich das Präfix an meinem Anschluss eh dauernd.

In OpenWRT war das alles für mich bislang kein Problem, da ich hierfür nur eine einzige Firewall-Regel brauchte. Dort kann man als Quelle eine MAC-Adresse angeben und damit sind die Identifier auf Level 3 egal. Ziemlich simpel aber wirksam.

In OpnSense scheint die gedankliche Trennung zwischen Layer 2 und 3 jedoch stringenter behandelt zu werden.
Zumindest habe ich auf Anhieb keine Möglichkeit gefunden MAC-Adressen als Quelle der Pakete festzulegen.
Spontan sehe ich für mein Anliegen erst einmal nur folgende Möglichkeit:

• Neues Layer 2 Netz (VLAN) sowie Layer 3 Netz einrichten
• In diesem den Fernseher unterbringen - z.b. durch Anschluss an den entsprechenden Port am Switch
• Im Router neues Interface für dieses Netz einrichten und Dienste hierfür konfigurieren (DHCP, DNS etc.)
• Firewall-Regeln erzeugen, so dass aus diesem Netz kein Internet möglich ist aber zwischen LAN und diesem Netz geroutet wird (z.b. für Streaming oder Steuerbefehle)

Natürlich wäre das mit mehr Kontrolle verbunden und unerwünschte Kommunikation ist damit zuverlässiger unterbunden.
Aber ganz ehrlich: Das finde ich schon bisschen zu viel Aufwand der die Verwaltungskomplexität enorm erhöht, verglichen mit einer einzigen Firewall-Regel welche unter OpenWRT das gleiche Endziel erreicht.

Ich gehe daher davon aus, dass ich - noch neu in der OpnSense-Welt - etwas übersehen habe und frage daher wie hier mit derartigen Fällen umgegangen werden sollte.

Btw.: damit die Diskussion nicht abdriftet: MAC-Spoofing macht der Fernseher natürlich nicht - er behält seine MAC brav bei. Wäre er so garstig seine MAC zu ändern, bräuchte ich auch nicht auf Layer 3-Ebene filtern, da er seine IP noch viel einfacher ändern könnte.

Sehr schön. Daran lag es tasächlich.
Nun habe ich IPv6 sowohl auf dem LAN-Interface, als auch auf den Clients.

Mal wieder: Besten Dank! - toller und fixer "Service" hier.

So konnte es jetzt so umgehen, dass ich die IP-Einstellung zum IPv6 Tracking per SSH erledigt habe.
Damit blieb auch das WebGUI bestehen.

Leider habe ich auch damit nicht den gewünschten Erfolg erzielen können (keine IPv6-Adressen auf dem LAN-Interface als auch den dort angschlossenen Clients).

Meine aktuelle Config liegt als Screenshots im Anhang.

Ja wie in dem Thread beschrieben schon zigmal.
Das Phänomen tritt auch schon bei nahezu Werkskonfiguration auf.

Ok würde ich gerne testen aber sobald ich auf "Schnittstelle aufzeichnen" umstelle und unten das WAN-Interface als Master eintrage und diese Änderungen übernehme schmiert die Web-GUI ab und ist ab dem Zeitpunkt nicht mehr erreichbar.
Es hilft dann nur noch auf ein Backup zurückzusetzen.
Dieses bizarre Problem hatte ich bereits. Wirklich lösen konnte ich es bislang nicht.

Könnte also eine ganze Zeit dauern bis ich wieder weitermachen kann.

Ok habe nun im WAN von SLAAC auf DHCPv6 umgestellt.
Im Abschnitt "DHCPv6 Clientkonfiguration" habe ich die Präfixdelegationsgröße auf 56 gestellt.

Bislang konnte ich noch keinen Effekt auf IPv6-Adressen im LAN feststellen.
Das Interface LAN selbst hat weiterhin keine globale Adresse und die Clients im LAN ebenso nicht.

Mein Internetzugang läuft über Telekom-Glasfaser (über deren Glasfaser-Modem).
Die Verbindung per PPPoE klappt auch super, jedoch habe ich zumindest im LAN kein IPv6 bislang zum laufen bekommen.

Das WAN-Interface bekommt eine /64-er IPv6-Adresse (siehe ueberblick.png).
Das LAN hingegen nicht (nur die link-local und eine eigene ULA).
Es scheint also die Prefix-Delegation nicht zu funktionieren.
Ich setze hier in beiden Fällen auf SLAAC.
Dann hört es jedoch leider schon auf mit meinem Wissen - vor allem was ich wo noch alles dazu in opnsense einstellen muss.

Guck an - das war es!
Vielen Dank.

Eventuell zum Verständnis:
Ich möchte ja eigentlich, dass die Regel nur für Verkehr gilt, welcher von der WAN-Seite herkommt.
Ich hatte ja nun als Quelle "WAN-Netzwerk".
Das Problem hierbei ist, dass damit nur das unmittelbare WAN-Netz gemeint ist und nicht dahinter liegende - oder?
In meinem Fall ist mein WAN-Netz ein /32er sodass überhaupt keine anderen IP-Adressen hiervon gemeint wären.

Edit: Genau wie Patrick sagte

Danke für den Tipp.
Hat leider keine Änderung gebracht.
In den Logs sehe ich weiterhin, dass die Anfragen von der default rule geblockt werden.

Ich versuche eine HTTP/HTTPS-Weiterleitung auf meinen Server im LAN bei Zugriffen von außen einzurichten.
Hierzu habe ich ein alias für den Server angelegt (siehe alias.png).
Danach habe ich die Forward-Regel erzeugt (siehe pfrule.png) - sowie analog für HTTP.
Nun habe ich das ganze getestet und ich habe das Problem das der Request von der Regel Default deny / state violation rule abgefangen wird (siehe block_event.png).

Entweder meine Regel zieht nicht - dann sehe ich bislang nicht den Grund was ich falsch eingestellt habe.
Oder die Reihenfolge der Regeln ist so, dass mein Port-Forward nachher kommt - dann weiß ich aber nicht wie ich die Reihenfolge der default-rules ändern kann.

Das Interface der opnsense läuft auf einem ganz anderen Port (800), so dass dies nicht in die Quere kommen sollte.

Für Tipps hierzu bin ich sehr dankbar.