Aktuelles Szenario:
Mehrere OpenVpn-Tunnel, die als DNS den Tunnel-Server mitgeben Bsp: 192.168.200.0/24 Tunnelnetz und GW/DNS/NTP ist die .200.1.
Damit Unbound funktioniert, sind as Interfaces "alle" angegeben.
Nun möchte ich aber auf dem WAN den DNS abschalten - klar könnte man das auch per Regel blocken, das ist nur ein Workaround. Macht man bei den Regeln einen Fehler, ist wieder alles offen.
Bei den Interfaces kann man nur physische Interfaces angeben - die Logischen für die OpenVpn-Instanzen kann man hier, warum auch immer, nicht angeben. Dabei würde das aus meiner Sicht so viel mehr Sinn ergeben.
>>Möchte meinen VPN-lern die internen Servernamen mitgeben, die den Rest der Welt nichts angehen!
Kann ich Unbound auf den VPN-Servern betreiben, ohne das auch auf WAN preiszugeben (wo sie vermutlich dran hängen)?
Quote from: trixter on May 15, 2026, 09:16:38 PMNun möchte ich aber auf dem WAN den DNS abschalten - klar könnte man das auch per Regel blocken, das ist nur ein Workaround. Macht man bei den Regeln einen Fehler, ist wieder alles offen.
Ich denke, da hast die eine falsche Sichtweise. Natürlich sind Regeln hier das geeignet Mittel, um Zugriffe zu beschränken.
Die Interfaces, die man in Unbound auswählt, sind lediglich jene, auf welche Unbound lauscht. Ihn auf die Interface IP lauschen zu lassen ist komfortabel in Verbindung mit einem DHCP Server, weil dieser die Interface IP automatisch auch gleich an die Clients als DNS verteilt. Als Zugriffsbeschränkung ist das aber gar nicht geeignet.
Clients am LAN könnten eben so gut ihre DNS-Anfragen an die Management-IP richten. Wenn da ein DNS läuft und die Firewall-Regen den Zugriff erlauben, werden sie eine Antwort erhalten.
Das gilt natürlich auch für alle anderen Services, die auf OPNsense laufen.
Firewall-Regeln sind also in jedem Fall das Werkzeug der Wahl, um unerwünschte Zugriffe zu unterbinden.
Quote from: trixter on May 15, 2026, 09:16:38 PM>>Möchte meinen VPN-lern die internen Servernamen mitgeben, die den Rest der Welt nichts angehen!
In der OpenVPN Server-Konfiguration musst du ohnehin einen DNS-Server eintragen. Das kann dann auch die LAN-IP oder sonst eine sein, auf der Unbound lauscht. Wenn die Clients nur die Hostnamen, nicht den gesamten FQDN, auflösen können sollen, musst du die lokale Domäne auch als Suchdomänen pushen.
Erlaube den Zugriff ggf. noch mit einer Regel, dann sollten die Clients Namen auflösen können.
Quote from: viragomann on May 16, 2026, 09:13:20 PMDie Interfaces, die man in Unbound auswählt, sind lediglich jene, auf welche Unbound lauscht. Ihn auf die Interface IP lauschen zu lassen ist komfortabel in Verbindung mit einem DHCP Server, weil dieser die Interface IP automatisch auch gleich an die Clients als DNS verteilt. Als Zugriffsbeschränkung ist das aber gar nicht geeignet.
Das ist mir schon klar - wollte bloß keinen Roman schreiben den eh keiner lesen will.
Kernfgrage : Auf welchem Interface laufen die Unbound-Anfragen für OpenVPN - meine Vermutung ist, dass das WAN hierfür verwendet wird.
Wenn man nun DNS für die VPN-User braucht, unbound aber nicht auf WAN veröffentlichen möchte (aus genannten Gründen)... Was ist die eleganteste Methode?
Quote from: trixter on May 26, 2026, 11:14:23 AMKernfgrage : Auf welchem Interface laufen die Unbound-Anfragen für OpenVPN - meine Vermutung ist, dass das WAN hierfür verwendet wird.
Das OpenVPN-Interface, naheliegenderweise. Das hat doch eine IP-Adresse im Infrastruktur-Modus.
Quote from: Patrick M. Hausen on May 26, 2026, 11:45:00 AMDas OpenVPN-Interface, naheliegenderweise.
Das setzt aber voraus, dass Unbound auf allen Interfaces lauscht.
Möchte man das nicht, und die OpenVPN Server IP als DNS bereitstellen, muss der Instanz ein explizites Interface zugewiesen werden, damit es in Unbound auswählbar ist.
Aber den VPN Clients ist es egal, ob sie ihre Anfragen auf die Server IP oder sonst eine richten. D.h. es könnte auch jede beliebige andere Interface IP sein. Sie müsste nur den Clients über die OpenVPN Option gepusht und der Zugriff erlaubt werden.
Ich verwende jedenfalls eine andere Interface-IP.
Quote from: trixter on May 26, 2026, 11:14:23 AMKernfgrage : Auf welchem Interface laufen die Unbound-Anfragen für OpenVPN - meine Vermutung ist, dass das WAN hierfür verwendet wird.
Nein, wie kommst du darauf?
In der OpenVPN Server Konfiguration gibt es die Option "DNS Servers", mit welche angegeben wird, welchen DNS die verbunden Clients nutzen sollen.
Dieser Server wird dann am Client der virtuellen VPN Schnittstelle zugewiesen.
Steht da nichts, nutzen sie ihren Standard-Server, glaube ich jedenfalls. Ich denke nicht, dass der OpenVPN Server die eigene Interface-IP an die Clients verteilt, wenn hier kein DNS eingetragen ist.
Quote from: trixter on May 26, 2026, 11:14:23 AMWenn man nun DNS für die VPN-User braucht, unbound aber nicht auf WAN veröffentlichen möchte (aus genannten Gründen)... Was ist die eleganteste Methode?
Keine Firewall Regel am WAN hinzufügen, die DNS erlauben würde.
Quote from: viragomann on May 26, 2026, 12:58:45 PMNein, wie kommst du darauf?
Naja, einfach, auf welchem Interface läuft der Anmelde-Dienst?
Hintergrund: ich möchte auf WAN nicht unbound, sondern Adguard antworten lassen, um Inhalte auch für Clients zu blocken, die nicht hinter der FW sitzen.
Dazu muss unbound auf WAN allerdings die Klappe halten.
Die VPN-Client nutzen die WAN IP nur für die VPN, nicht für andere Services, solange das nicht auf den Client ausdrücklich so konfiguriert wird.
Ich nehme an, du routest sämtlichen Traffic der Clients über die VPN, um diesen zu filtern?
Dann sollte auch ein DNS-Server gepusht werden, wie schon erwähnt. Ansonsten, würden sie bspw. einen öffentlichen DNS nutzen, würde dieser natürlich auch über die VPN und zum WAN raus geroutet werden. Ist das, was du meinst?
Dann hast du von ausgehenden DNS-Verbindungen gesprochen und ich habe an eingehende gedacht.
Wenn du das DNS der Client in den Griff bekommen möchtest, bedenke auch, dass diese DoH nutzen könnten. Da braucht es also auch Firewall-Regeln, die das unterbinden.
Ahoi zusammen,
habe das ganze jetzt selbst gelöst - wie es scheint:
Man kann unter Interfaces die VPNs als Virtuelles interface "assign"-en, damit werden sie dann behandelt wie physische Interfaces.
Somit tauchen diese dann auch in der Unbound-Liste auf und können eigenständig an und abgewählt werden.
Also habe ich alle Interfaces, bis auf WAN angeharkt und die Welt ist wieder rund.
Ich habe allerdings keine Ahnung welche Seiteneffekte das mit sich bringt - werde berichten, wenn ich soetwas entdecke.
Quote from: trixter on May 28, 2026, 07:22:00 PMhabe das ganze jetzt selbst gelöst - wie es scheint:
Man kann unter Interfaces die VPNs als Virtuelles interface "assign"-en, damit werden sie dann behandelt wie physische Interfaces.
Somit tauchen diese dann auch in der Unbound-Liste auf und können eigenständig an und abgewählt werden.
Dann hast anscheinend nicht die Antworten hier gelesen. Dass diese Option besteht, habe ich unter https://forum.opnsense.org/index.php?msg=267607 im 2. Satz geschrieben.
Weil ich das aber für diesen Zweck nicht für nötig erachte, habe ich es nicht hochgejubelt.
Quote from: trixter on May 28, 2026, 07:22:00 PMIch habe allerdings keine Ahnung welche Seiteneffekte das mit sich bringt
Keine.
Abgesehen davon, dass du auch die Möglichkeit erhältst, explizit auf diesen Interfaces gesonderte Firewall- und NAT-Regeln zu erstellen.
Quote from: viragomann on May 28, 2026, 07:38:39 PMDann hast anscheinend nicht die Antworten hier gelesen. Dass diese Option besteht, habe ich unter https://forum.opnsense.org/index.php?msg=267607 im 2. Satz geschrieben.
"Möchte man das nicht, und die OpenVPN Server IP als DNS bereitstellen, muss der Instanz ein explizites Interface zugewiesen werden, damit es in Unbound auswählbar ist."
Das war leider so cryptisch, dass ich das nicht verstanden habe, sorry dafür ;)
Wenn man eine OpenVPN Instanz baut, ist in der kompletten Maske keine Möglichkeit ein Interface damit zu verknüpfen.
OpenVpn wird auch ohne diese bestens funktionieren. Auch die OpenVPN-Server-IP ist vorher schon nutzbar, wenn Unbound "alle" Interfaces bedient.
Man KANN unter Interfaces eine OpenVPN Instanz assignen und damit daraus ein eigenes Interface machen, welches andere Dienste wie Unbound dann wiederum sehen.
Ideal wäre gewesen, wenn einer Instanz bei ihrer Erstellung direkt eine Interface-ID zugewiesen würde.
Quote from: trixter on May 28, 2026, 07:55:45 PMWenn man das so cryptisch schreibt, muss man sich nicht wundern, wenn man nicht verstanden wird ;)
:-) Das war an Patrick gerichtet, und er hat es wohl verstanden.
Aber dass es die Möglichkeit gibt, das Interface in Unbound verfügbar zu machen, hätte jeder rauslesen können. Bei Interesse hätte man ja nachfragen können.
Quote from: trixter on May 28, 2026, 07:55:45 PMIdeal wäre gewesen, wenn einer Instanz bei ihrer Erstellung direkt eine Interface-ID zugewiesen würde.
Die Nachfrage nach dieser Option ist wohl geringer als du denkst.
Man braucht das nur unter bestimmten Voraussetzungen, bspw. um auf das VPN Gateway zu routen.
Die Möglichkeit, das Interface in Unbound auswählen zu können, gehört wohl auch dazu, ist aber nicht wirklich interessant, wie in diesem Thread schon ausführlich diskutiert.
Quote from: viragomann on May 28, 2026, 08:10:37 PMDie Möglichkeit, das Interface in Unbound auswählen zu können, gehört wohl auch dazu, ist aber nicht wirklich interessant, wie in diesem Thread schon ausführlich diskutiert.
Genau. Es gibt einen guten Grund für das "recommended" in "All (recommended)". Fummel daran herum und alle daraus resultierenden Probleme sind erst mal dein Bier.
Quote from: viragomann on May 28, 2026, 08:10:37 PMDie Nachfrage nach dieser Option ist wohl geringer als du denkst.
Dennoch kann man ein gutes Produkt noch besser machen ;)
Da hast Du wohl leider recht, die meisten interessieren sich nicht, solange es funktioniert - das ist bei IT leider fast immer so, dass andere Abteilungen sich nen Sch** interessieren, so lange ich SAP-Mist läuft ..
Quote from: Patrick M. Hausen on May 28, 2026, 08:18:04 PMGenau. Es gibt einen guten Grund für das "recommended" in "All (recommended)". Fummel daran herum und alle daraus resultierenden Probleme sind erst mal dein Bier.
Klar sollte man nicht an allem herumfummeln, aber wenn man sich an Best-Praktice halten soll/will ist das manchmal nicht anders möglich.
Thema Bier .. naja wird Gründe haben warum der Absatz stagniert.
"recommended" fand ich schon immer spannend nach dem "Warum" zu fragen. Führt zu spannenden Ergebnissen, bei denen man viel lernen kann.
Best practice ist "All (recommended)" aus Gründen, die ich schon ein Dutzend mal in diesem Forum erklärt habe. Wenn du einen Dienst an ein Interface bindest und das Interface flappt, ist der Socket danach weg und kommt ohne Neustart des Dienstes auch nicht wieder. Mit "All" bindet der Dienst an INADDR_ANY - das ist stabil.
Auf WAN greift am Ende die "deny all" Firewall-Regel. Daher ist es überhaupt kein Problem, wenn Unbound da lauscht.
Quote from: trixter on May 29, 2026, 09:02:03 AMDennoch kann man ein gutes Produkt noch besser machen ;)
Du meinst ernsthaft, OPNsense mit dieser Einstellung besser zu machen? Tatsächlich bringt es so gut wie nichts, könnte auf der anderen Seite aber Probleme bereiten.
Warum es nichts bringt, habe ich gleich anfangs in meinem ersten Post (https://forum.opnsense.org/index.php?msg=267121) erklärt.
Ich zitiere nochmals den wesentlichen Satz darau;
QuoteClients am LAN könnten eben so gut ihre DNS-Anfragen an die Management-IP richten. Wenn da ein DNS läuft und die Firewall-Regen den Zugriff erlauben, werden sie eine Antwort erhalten.
Das war ein Beispiel und gilt ebenso für alle anderen Interfaces, auch für WAN.
D.h. in der Praxis, geht eine Anfrage für einen Dienst am WAN ein, die die LAN IP zum Ziel hat, auf welcher der Dienst lauscht und wird diese von der Firewall erlaubt, wird der Dienst normalerweise auch eine Antwort liefern.
Ja, deine LAN IP ist wahrscheinlich privat und du argumentierst nun, sie wird im Internet nicht geroutet. Realisierbar ist das aber bspw. auf ISP-Seite, wenn sich da ein neugieriger, gelangweilter Admin einen statische Route für private Subnetze auf deine WAN-IP setzt.
Das kannst du gerne in einer Testumgebung nachstellen.
Im Fall von Unbound gibt es dafür allerdings noch eine zusätzlich Hürde: Access Lists. Die Anfrage müsste also auch von einer Quell-IP kommen, die in den ACLs enthalten ist, damit sie beantwortet wird.
Deine internen Subnetze sind da standardmäßig enthalten. So lässt sich auch diese Hürde bei einem gezielten Angriff umgehen.
Letzten Endes bleibt dir aber allgemeinen als Sicherheit nur die Firewall, und davon sprechen wir hier seit Beginn.
Quote from: viragomann on May 29, 2026, 12:06:56 PMClients am LAN könnten eben so gut ihre DNS-Anfragen an die Management-IP richten. Wenn da ein DNS läuft und die Firewall-Regen den Zugriff erlauben, werden sie eine Antwort erhalten.
Sowas würde ich schon aus Prinzip nicht machen - Lan-Traffic hat am Management-Interface per se nichts zu suchen!
Da könnte ich mir das seperate Interface ja gleich sparen.
Und ich bleibe dabei, dass man Produkte stetig verbessern sollte.
Quote from: viragomann on May 29, 2026, 12:06:56 PMDu meinst ernsthaft, OPNsense mit dieser Einstellung besser zu machen? Tatsächlich bringt es so gut wie nichts, könnte auf der anderen Seite aber Probleme bereiten.
Wenn man das sauber dokumentiert, sehe ich da ehrlich gesagt mehr Nutzen als Schaden - das ist natürlich subjektiv.
Warum sollte ich etwas per ACL oder auch FW Regel beschränken, was ich auch einem Interface nicht anbieten und daher auch komplett ausschalten kann?
Worin nun der Vorteil besteht etwas komplizierter und damit fehleranfälliger zu machen als nötig, erschließt sich mir nicht.
Systeme verständlicher für alle zu machen sehe ich halt als Verbesserung des Produkts.
Quote from: trixter on June 03, 2026, 11:06:51 AMWarum sollte ich etwas per ACL oder auch FW Regel beschränken, was ich auch einem Interface nicht anbieten und daher auch komplett ausschalten kann?
Weil deine Vorstellung von "auf einem Interface anbieten oder nicht" nicht der Realität entspricht.
Wenn du von z.B. LAN aus DNS-Requests an "any" oder "this firewall" erlaubst, dann kannst du von LAN aus jede IP-Adresse der Firewall ansprechen und dort deine Requests hin schicken. Die sind alle lokal aus Sicht der Firewall und werden in der Hinsicht identisch behandelt. Die Firewall interessiert, zu was für einem Interface die Anfrage hereinkommt, nicht, welche IP-Adresse verwendet wird.
Deshalb ist der Vorschlag die Management-IP-Adresse zu benutzen auch nicht abwegig. Damit kommt man nicht ins Managagement-Netz. Damit kann man genau vom LAN eine DNS-Anfrage an die Firewall schicken und sonst nichts. Die IP-Adresse ist wie gesagt völlig wurst, so lange sie eine lokale der Firewall ist.
So funktioniert das nunmal.
Quote from: trixter on June 03, 2026, 11:06:51 AMQuoteClients am LAN könnten eben so gut ihre DNS-Anfragen an die Management-IP richten. Wenn da ein DNS läuft und die Firewall-Regen den Zugriff erlauben, werden sie eine Antwort erhalten.
Sowas würde ich schon aus Prinzip nicht machen - Lan-Traffic hat am Management-Interface per se nichts zu suchen!
Aufs Manangement-Interface würde der Traffic auch nicht kommen, davon war nicht die Rede.
Aber ein Gerät im LAN spricht einen Service-Port der Management-IP an. Erlauben die Firewall am LAN den Zugriff, so wird er auch erfolgreich sein.
Dazu muss das Paket gar nicht das Management-Interface passieren. Und eben darum kommen die Regeln auf diesem für den Zugriff aus dem LAN auch nicht zum Tragen. Dass du da bspw. den Zugriff auf die Quelle MM Netz eingeschränkt hat, hilft also nicht, wenn der Zugriff über ein anderes Interface reinkommt.
D.h. die den Interfaces zugewiesenen IPs sind allem voran der OPNsense zugewiesen und die darauf betriebenen Services lauschen auf all diesen und scheren sich normalerweise nicht, durch welches Interface ein Zugriff rein kommt. Das gilt auch für Unbound.
Also nochmals:
Wenn eine Regel, die auf einem Interface definiert ist, den Zugriff auf eine IP der OPNsense erlaubt, so ist von dem jeweiligen Interface Zugriff auch möglich.Deshalb solltest du dir deine Regeln genau ansehen, anstatt dich auf Service-IPs zu verlassen. Da wiegst du dich in falscher Sicherheit.
Hast du eine Pass-Regel mit Ziel "any", so erlaubt sie den Zugriff auf alle Interface-IPs. Ist das Ziel "RFC 1918", ist der Zugriff wahrscheinlich auf die meisten deiner IPs erlaubt.
Grundsätzlich lauschen Services auf allen IPs, die der OPNsense zugewiesen sind, egal welchem Interface, es sei denn, der Service ist explizit für bestimmte IPs konfiguriert. Letzteres ist das, was du mit der Interface-Auswahl in Unbound machst.
Ist hier WAN nicht dabei, wäre dennoch ein Zugriff aus dem WAN auf bspw. die DMZ-IP möglich, wenn es die Regeln erlauben.
Die Management-IP war als Extrem-Beispiel gedacht, weil diese oft als heilige Kuh angesehen wird und man diese streng schützen möchte. Im Grunde ist sie nichts weiter als jede beliebige andere IP, die OPNsense zugewiesen ist. Zur heiligen Kuh machen sie erst die Firewall-Regeln, jedoch alle zusammen, auch jene auf anderen Interfaces.
Ebenso kann die OPNsense GUI nur mit Firewall-Regeln vor unerwünschten Zugriffen geschützt werden. Was du in
System: Settings: Administration: Listen Interfaces an Interfaces auswählst, sind lediglich die IPs, auf denen sie erreichbar ist.
Hier hast du wahrscheinlich Management ausgewählt. Hast du auf einem anderen Interface eine Regel die alles auf any oder RFC 1918 erlaubt, und keine entsprechende Block-Regel davor gesetzt, kann man von da aus auch auf die Weboberfläche zugreifen. Das könntest du rasch testen.
Quote from: viragomann on June 03, 2026, 08:26:19 PMQuoteQuoteClients am LAN könnten eben so gut ihre DNS-Anfragen an die Management-IP richten. Wenn da ein DNS läuft und die Firewall-Regen den Zugriff erlauben, werden sie eine Antwort erhalten.
Sowas würde ich schon aus Prinzip nicht machen - Lan-Traffic hat am Management-Interface per se nichts zu suchen!
Aufs Manangement-Interface würde der Traffic auch nicht kommen, davon war nicht die Rede.
Sorry, ich finde Du wiedersprichst Dir immer wieder.
Regeln machen hier keinen Sinn, weil ich den Port 53 für Adguard nutzen will, da wäre mir unbound schlicht im Weg!
Da hilft auich das werfen mit RFCs wenig, es sei denn man wolle sich hinter einem Ausdruck davon verstecken?
Eine Lösung ist gefunden und damit sollten wir das vielleicht auch abschließen!
Quote from: Patrick M. Hausen on June 03, 2026, 11:34:11 AMSo funktioniert das nunmal.
Lieber Patrick, das mag für die Sense zutreffen, aber hier sollte man doch etwas lernen - im Idealfall wie man das richtig macht?
Sonst haben wir bald da draußen nur noch Pfusch und Leute die daran verzweifeln, wenn sie dann doch mal eine Palo-Alto/Fortigate/Firepower etc konfigurieren sollen.
Wenn du damit auf eine Firewall triffst die saubere Stages hat, greifst du mit "ich lang da mal eben quer durch die Firewall" sowas von ins Leere - da wird der Begriff Firewall dann harte Realität.
Das trifft auf jede Firewall zu, die auf einem Standard BSD oder Linux aufsetzt und keine FIB pro Interface verwendet. Damit sind best practices vielleicht nicht immer 1:1 übertragbar?