Messages

Naja über "/ui/interfaces/assignment" könnte man wenigstens eine sinnvolle Description angeben.

Mir persönlich hilft das auf der Weboberfläche schon sehr, die Interfaces zu unterscheiden.

Die tatsächliche Bezeichnung (opt..) sehe ich kaum, die nervt mich eher auf der Console.

Kurze Info:

Das Netz 192.168.178.x ist das Default-Netz jeder Fritzbox.
Daher ist es nicht ratsam genau dieses "extern" zu verwenden.

ich würde das Lan-Netz des Draytec als Transfer-Netz betrachten.
Die Draytec Lan-Adresse solltest Du als Gateway fürs WAN eintragen, dann gelten die Standard-Regeln für NAT und Routing.
Wenn Du dem LAN der Sense dann ein entsprechendes Subnetz verpasst zb 192.168.100.x/24, hast Du eine simple Routing Instanz.
Regeln würde ich mit permit any any Regeln beginnen die erstmal alles erlauben, die kannst Du dann schrittweise verschärfen.
Wenn Du diese Regeln auf logging stellst, kannst Du im Livelog gut verfolgen was passiert - gibst Du den Regeln passende Beschreibungen, so kannst Du gut verfolgen, welche gerade greift.
Bedenke, dass Regeln allgemein vom benannten Inferface eingehend gelten.
DHCP kann Kea für Dich übernehmen (findest Du unter Services).
DNS macht die Sense ebenfalls recht gut, wenn man einen externen DNS angibt (zb google 8.8.8.8) - Du kannst aber auch den vom Provider nehmen.

Damit solltest Du starten können...
Gibt hier auch einen Guide für Fritz-Umsteiger, der ist recht gut.

Für mein Verständnis müsste doch da reichen, wenn ich unter Generel use V4 only oder wie das heißt aktiviere, oder?!

Wenn Du irgendwas davor hängen hast (Router vom Provider), dann solltest Du mit IPv4 erst mal gut klar kommen.

Dann Stück für Stück Richtung aktuelle Version - alles auf ein Mal zu erneuern ist zwar löblich, aber unübersichtlich und evtl auch sehr viel Arbeit. 

Dann zieh doch erst mal in Ruhe um, bevor Du noch eine Baustelle aufmachst..

Dann würde evtl versuchen eine aktuelle Sense aufzusetzen und nicht alten Ballast mit zu schleppen.

ICS ist längst abgekündigt - wird Dir also nur Probleme machen.

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

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.

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!

lass mich raten, deine Netzwerkkarten kommen auch noch von Realtek?

Grundsätzlich gibt es zu wenige Infos von Dir, was du da gebaut hast.
Außerdem würde ich jede Legacy Einstellung hinterfragen, denn sonst fällst du beim nächsten Update auf die Nase, wenn aus legacy deprecated wird.

Ob es an Cron liegt kann man ja recht simpel nachprüfen:

Baue Dir einen Zeitnahen zusätzlichen Job der zb. Unbound neu startet und schau ob der läuft?

Wenn der läuft liegt es schonmal nicht am Cron.

Ist auch immer einen Blick in die Logs wert ;)

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.

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.

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.

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.
 

Hätte eh keine Ahnung wie ich sonst v6 einrichte um ehrlich zu sein...

Na dann würde ich erst mal Release-Notes lesen, bevor ich anfange zu meckern?

https://forum.opnsense.org/index.php?board=11.0

DHCP hat wenig mit dem Interface zu tun, das ist ein eigener Service..

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

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.

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.

Vielleicht das Interface selbst mal aus dem Legacy-Mode holen?

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.

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

Die Basis-Frage konnte ich mir bislang nicht beantworten: Was genau möchtest Du bezwecken?

Möchtest Du "Angriffe" aus gewissen Regionen verhindern?

Dann lass Dir gesagt sein, dass das so nicht wirklich funktioniert, denn Angriffe erfolgen heute nicht mehr aus dem bösen Land X, sondern über den gehackten Router in Land Y. Das kann man in der Presse auch ganz einfach nachlesen.
Kaum ein echter Hacker wird seine ISP-Adresse direkt für einen Angriff verwenden.

Effizienter sind Dynamische echte Blocklists (zB OSID), die regelmäßig aktualisiert werden und deine DNS filtern.
So kann ein gehackter Client seinen Control-Server nicht mehr erreichen.

Gibt diverse Tutorials zu dem Thema ... frag Morpheus ;)