Messages

Seconded here. Was hitting a monitoring alert because 2 certs that are in use with Caddy were over there set up renewal timeframe. As I'm already using the new "tlsserver" profile that only has ~45days certs manually refreshing multiple certificates is tedious. It's only the cron that fails though, manually refreshing is fine, but somehow the --cron stuff isn't running correctly.

Warum soll ich irgendeiner Shady Bude meinen kompletten Traffic (via DNS) verraten? Nur weils kostenlos ist? :)

Für business und extended setups, ok.
Aber ist da der dns im opnSense eh die richtige Lösung?

Für Heimanwender, die hängen doch meist am Tropf des ISP, der weiß eh alles. Da kann man auch dessen DNS Resolver verwenden, vorausgesetzt die funktionieren vernünftig? Mir ist bei meinem noch nichts böses aufgefallen (Filtering, Ausfälle und co).

Das hat ja jetzt nicht direkt was mit Business oder Extended Setups zu tun, oder? Ich sehe nur selbst hier und anderswo ständig Private/HomeLab Builds, die dann zum Ende hin alles via VPN %irgendwo% hin schicken damit ja alles verschlüsselt ist. Aber bringt es was, dem VPN Anbieter dann alle Daten - plus ggf. noch Geld - in den Rachen zu werfen? Das hängt eben ganz vom Schutzbedürfnis ab. Und wenn das nicht irgendwo bei "mission critical" bis "Ich bin Edward Snowden" liegt, dann ist der Provider für dich noch die Kleinste Hürde. DER ist nämlich zumindest aktuell und noch an die DSGvO und andere Spielregeln im Land gebunden und muss deinen Kram bzw. die IP Zuordnung wieder löschen. %HochObenSicherVPN% muss das nicht. Oder dir zumindest nicht verraten. Und sitzt meist auch nichtmal in Ländern, wo du sie irgendwo behelligen kannst.

Das ist der eine Knackpunkt. Der andere ist: DNS irgendwo hin zu packen, wo du keine Kontrolle drüber hast. Also 1.1.1.1, 8.8.8.8 und Co. Die mögen schnell sein, aber die können halt morgen Filtern, zensieren, etc. Nutzt du Unbound als Resolver und den Weg über die Roots wird Zensur schwerer. Klar, dein ISP könnte reingrätschen und Port 53 intercepten und umleiten. Das könnte man dann aber erkennen und entsprechen Gegenmaßnahmen ergreifen. Solange die aber - siehe oben - an geltendes Recht gebunden sind, wäre das eine verdammt heikle Sache, sich bei sowas erwischen zu lassen.

Das ist aber der Grund, warum ich DoT/DoH kritisch sehe. DoT kann man genauso einfach blocken wie normales DNS. DoH/DoQ löst kein wirkliches Problem außer den Provider auszuhebeln. Wenn wir aber RogueISP haben, dann kann der einfach die bekannten DoH/DoQ Gegenstellen blocken. Klar kann man dann einen suchen der geht aber dann sind wir auf einem Level, wo wie ich schon weiter oben beschrieben hatte eher dann ein Konstrukt wie DoHoT sinnvoll wäre. Also DoH (DNS via HTTPS) und das via TOR um im Traffic vom TOR Netz unter zu gehen. Dann ist nicht mehr einfach erkennbar, dass das DNS Calls sind. Aber da sind wir dann schon weitaus weiter oben auf der Gefährdungsskala als "ich brauche schnelles DNS" :)

Wenn man selbst die volle Kontrolle möchte, ist es eh am Sinnvollsten, sich intern und extern nen DNS aufzubauen mit Blocklistings und Co (also AGH oder PiHole hinstellen). Und vom externen kann man dann auch wieder via Unbound brav DNS Resolving machen. Den kann man dann auf der Sense als Fallback Forwarder angeben und notfalls auch nen VPN dahin tunneln wenn einem der ISP suspekte Sachen macht. Immer noch besser als gratis oder für 1,39€/mtl den ganzen Kram via Cloudflare, Alphabet oder sonstwen zu jockeln :)

Cheers

Cheers

Schon bescheuert, da nutzt man freie unabhängige Software und doch tritt einem MS in den Arsch ;(

Naja bei vielen ist eben leider immer noch nicht angekommen, dass "Github = Microsoft" ist und sich der ganze Moloch dank Bruchpilot und Co in Zukunft nicht großartig verbessern, sondern eher verschlechtern (#enshitification) wird. Und nachdem die ursprünglichen Gründer/Betreiber jetzt von Bord und die Sparte ins Cloud/AI Gebimsel integriert wurde, wird das nur noch eine Frage der Zeit, bis wir das nächste "SourceForge" haben.

Ich habe zwar mit Dnsmasq, AGH und Unbound geliebäugelt, entnehme aber den Beiträgen, dass diese Variante nicht optimal ist!?

Was du im Einzelfall nutzt ist im Prinzip völlig wurscht. Das ist lediglich ein "Komplexitätsding" mit "wie viele Dienste will man verschachteln". DNSmasq kann jetzt DHCP+DNS also wird's von OPNsense als default gerollt, weil es halt nur ein laufender Service ist. OK fein. Vorher war es eben ISC DHCP und Unbound oder DNSmasq als DNS. Das Gleiche kannst du jetzt wieder haben eben mit Kea als DHCP und Unbound (immer noch) für DNS. Das ist das erste Level der Entscheidung.

Dazu kommt allerdings: DNSmasq ist nur ein Forwarder - kein Resolver. Du brauchst also zwingend noch irgendwas wohin da DNS geballert wird. Viele nehmen public DNSe - ich persönlich mags gar nicht. Warum soll ich irgendeiner Shady Bude meinen kompletten Traffic (via DNS) verraten? Nur weils kostenlos ist? :)
Unbound ist ein Resolver, löst also über die DNS Roots auf. Es kann zwar im Forward Mode arbeiten, primär ists aber ein Resolver. DAS ist der große Unterschied zwischen Setups mit DNSmasq und Unbound. Forward vs Resolve. Resolver - hab ich an mehreren Stellen schon ausführlicher beschrieben - ist im Normalfall eben resilienter gegen Ausfälle an zentralen Stellen. Oh der Google DNS ist tot? Meh. Cloudflare mal wieder weg? Meh. Quad9 muss irgendwelche Seiten aus dem DNS werfen? Meh. Egal. Wenn du über die DNS Roots auflöst fragt dein Unbound immer die entsprechenden DNS Server der Domain direkt nach den Einträgen. Keine großen zentralen Brocken, die dann ggf. falsche/keine Antworten liefern (dürfen). Daher resilienter weil Ausfälle nicht so ins Gewicht fallen.

Und dann kommt eben noch das Filtering Thema dazu. Wie Cedrik schon sagt kann das Unbound in der Sense mit Blocklisten auch selbst, dann aber eben nicht so schön mit Log und einfachem entblocken und Zip und Zap wie eben ein Tool mit hübscher GUI wie nen AdGuard Home (oder PiHole bspw.). Wenn simples Blocking reicht -> Unbound + DNSBLs und gut. Wenns mehr sein darf + Statistiken und GUI und Co -> AGH.

Wenn die Entscheidungen durch sind, ist es nur noch ein Zusammmenstecken der Komponenten. Je nach Konfiguration kannst du dann AGH auf internem Interface auf 53 lauschen lassen, Unbound auf 5353 umziehen und dem AGH als Forward dann localhost:5353 verpassen damit er das an den internen Unbound weitergibt. Der macht dann die Endauflösung via Roots und Resolving. Wenns DNSmasq ist, gleiches Spiel. Das was die Clients bekommen/erreichen sollen, sollte auf Por 53 laufen, den Rest packt man auf andere Ports und forwarded da hin.

Kea ist da eigentlich DHCP-technisch völlig simpel und annähernd gleich mit ISC zu konfigurieren. Außer du hast große Sonderlocken mit irgendwelchen DHCP Optionen und Co., das könnte dann problematischer werden, aber für Standard run-of-the-mill normalen DHCP gibts da gar nicht viel zu failen.

DoT, DoH und Co. halt ich persönlich zwar für quark, aber das darf jeder für sich entscheiden :) Aber statische IP/mac/Namen sind in Kea jetzt keine RocketScience anzulegen.

Cheers :)

Was man auch berücksichtigen sollte ist, ob man die beiden Sensen die miteinander quatschen dann irgendwie miteinander verknoten will im Sinne von "da werden Dienste von benötigt". Also muss Kiste A auf Kiste B direkt was senden.

Wenn ja (bspw. gerade bei DNS) ist das so ne Sache mit Standard IPsec (nicht routed), weil dann zwischen den Boxen kein direkt ansprechbares Netz herrscht. Ist doof, wenn man die eine Sense zur anderen verweisen möchte (Domain overrides bspw.) bzw. man muss dann wieder den ein oder anderen Zusatzkniff auspacken.
Sowas ist dann leichter mit IPsec VTI (routed), OpenVPN oder Wireguard wenn das VPN Verbindungsstück zwischen den Nodes wirklich ne echte IP hat auf die man weiterleiten kann. Damit funktionieren dann auch andere Shenannigans wie Policy Routing und Co einfacher.

Heutzutage ist allerdings gerade zwischen zwei OpnSensen Wireguard ohnehin der De-Facto-Standard.

Das würde ich hart anfechten. Mag für viele zutreffen, wir haben aber schon genug Gegenbeispiele mit Problemen durch Wireguard wenn beide Seiten bspw. DynIPs hatten etc. Als Standard empfinde ich das nicht. Alternative, klar. Man nimmt was im Einzelfall passt.
Und je nachdem was da an HW verbaut ist und unterstützt und ob dynamische IPs im Spiel sind, ist OpenVPN da sinnvoller gerade wenn bspw. noch Failover WANs mit im Spiel sind und Co :)

Cheers

Name: wird nich mehr geaendert, wer opnCentral mit opnSentral (fuer mich eine Zusammensetzung von opn/Sense/Central) verwechselt, hat andere Probleme.

Sprich's doch einfach mal aus. Wo soll ich denn beim Hören dann wissen, ob der jetzt "Central" oder "Sentral" gemeint hat? Den Leuten damit dann "andere Probleme" zu unterstellen ist ziemlich engstirnig. Sorry. Wenn mir das im Call jemand sagt und ich nachfragen muss, ist das doch klar, dass das überlappt.

Aber hey, solang das OPNsense/Deciso nicht juckt, you do you. Mehr als drauf aufmerksam machen, dass es vllt. ungünstig sein könnte, kann man nicht. :)

Cheers

Naja, das kann man ja über DDNS übergehen, das läuft ja selbst für Lite-Anschlüsse mitlerweile brauchbar.

Wenn du bei IPv6 mit DDNS anfängst, kannst dus auch gleich sein lassen. Der effektive Sinn des Ganzen war gerade das NAT-Gemurkse und Co NICHT mehr zu brauchen.
Zudem hilft dir DDNS rein gar nichts, wenn sich dein Prefix ständig ändert (bei jeder Neueinwahl als mit Glück alle 24h...) und du dann Geräte hast, die entsprechend lange brauchen ein neues Prefix, das announced wurde auch zu übernehmen. Heißt das ist nicht mehr nur mal so kurz 15s bei der Neueinwahl wie bei IPv4, sondern kann sich im Dümmsten Fall auch mal ne Stunde hin ziehen, bis alle Geräte mal ihren Hintern hoch bekommen haben und die IP durchrotieren. Und das ist ausgehend, da reden wir noch nicht von Erreichbarkeit von außen zwecks DDNS und Co.

Das ist einfach eine scheiß Seuche, Prefixe zu rotieren und das auch noch im dümmsten Fall alle 24h. Das läuft inzwischen schlicht unter "defekt" bei uns weil du nichts ordentlich damit anfangen kannst. Und da hilft dir weder irgendein DNS/DDNS noch sonstwas dagegen. Leider.

Cheers

Okay für mich war das eigentlich relativ logisch zwecks DNS.
Ich möchte nur, das die VPN Clients den Mullvad DNS nutzen, der Rest geht seinen regulären Weg.

Es sei dazu auch gesagt das ich echt kein Profi bin und auch noch einiges zu lernen hab.

Der Client ist so eingestellt, das der Mullvad DNS über den VPN genutzt werden soll.
Das mit der Gateway Regel muss ich mir selber noch mal anschauen, konnte die Woche über nicht daran arbeiten.

Und wie bekommen die Clients vorher ihre Einstellungen? Per DHCP? Und welcher DNS wird dort mitgeteilt? Vermutlich der der Sense oder nicht?
Du kannst dann nicht einfach den Clients wie du willst ihren DNS noch nachträglich ändern. DHCP pusht das raus und dann steht das. Zu dem Zeitpunkt könnte bspw. dein VPN gar nicht stehen, also würde dein Client im Limbo hängen. Es macht also durchaus Sinn, dass der Client nen funktionierenden DNs hat. Oder du willst eben hardcore enforcement dass diese internen IPs/Clients IMMER EGAL WAS DNS via VPN machen. Dann müsstest du für alle Clients, die du da via Mullvad pushen willst mit deiner Regel auch den Mullvad DNS als DHCP Override an den Client pushen, dass er nicht den internen DNS, sondern Mullvad nutzt.

Ansonsten hast du genau das was @virago dir die ganze Zeit schon sagt: dein Client will die Sense nach DNS fragen, deine Policy Regel pusht aber ALLES via VPN weg, auch Traffic den die Sense behalten "könnte" weil die PBR alles andere sticht. Und dann hast du kein DNS.

Cheers :)

Ich bin klar für ein TOTP-Feld, dass immer angezeigt wird (aber bei nicht aktiver TOTP nicht gefüllt werden muss). Alle anderen Dinge - richtig implementiert - sind sicherheitstechnisch sinnvoll.

Da würde ich zustimmen. Ich hatte die Streitfrage gerade erst bei der OpenVPN Implementations-Diskussion. Dort wars ja auch lange so, dass das dann via Radius als Passwort Pre/Postfix implementiert wurde, aber eben extrem unpraktisch und für die User auch sehr ungewohnt in der UX, wo jede Applikation und whatnot mit sauberer Trennung der UX Felder arbeitet. Darum war es schön zu sehen, dass da bspw. Unterstützung in den Windows Client von OVPN gekommen ist, dass auch der Client beim Login die Nutzung von einem extra TOTP Feld unterstützt um genau das wiederzuspiegeln.

Daher wäre ich da wie du auch dabei: einfach immer anzeigen und gut.

Ich hab den dnsbunker link bei opnsense core reingemacht heute

Super danke dafür! :)

Ich finde im Web keine passende Anleitung für die 26.4.1p2 , jede anleitung wie zum Beispiel vom Thomas Krenn, passen nicht zu der Version, es scheint als würde sich manche punkte in versionen verschieden verhalten / aussehen.

Nein, die Business Version hängt einfach 3 Monate (26.4 statt 26.1) hinter der Open Source Version her, damit man dort dann "doof gesagt" schon die ganzen kleinen Fixes und Problemchen aus dem Community Release weg hat. Darum auch nur 1 Subrelease statt 10 (11?) beim regulären 26.1. Somit unterscheiden sich die Versionen nicht wirklich, du hängst einfach nur automatisch länger in der Warteschleife und bekommst dann direkt schon den zu dem Zeitpunkt finalen Stand. Auch die UI wird sich nicht unterscheiden, aber das ist eben das Problem, wenn man nicht die OPNsense Docs, sondern Fremd-Doku liest: die kann einfach out of date sein, weil die irgendwann mal zusammen gekritzelt wurde und jetzt haben wir eben Monate/Jahre später und einen neuen Stand :)

Wenn man vergleichen will bei Business also einfach die 2. Stelle der Version Minus 3 (26.1 statt 26.4 oder 26.7 statt 26.10) suchen. Alles andere sollte sich nicht signifikant unterscheiden.

Cheers

weil sie sich anscheinend nicht mehr mit HaGeZis Repo synchronisieren können.

Ja, weil der meiste Kram der Hagezi nicht direkt einbaut von dessen GitHub Repo spiegelt. Auch die JSDelivr Links sind tot, da die nur 3-5 Tage Caching von Github sind.

Das AdGuard Team soll einfach wie alle anderen auch den DNSBunker Mirror nutzen, der aktuell direkt von seinem Build System gespeißt wird und das Einzige ist, was ALLE Listen inkl. der NRDs enthält wegen size constraints bei anderen Anbietern. Er meinte schon er muss sich was anderes besorgen, weil GitHub kotzt ihn an (seine Worte), Gitlab hat Größenbeschränkungen und Codeberg Größe und Speed Limits und Verfügbarkeit (leider).

Daher sind das alles nur Mirrors von GH gewesen aber keine vollständigen. Und darum ist gerade der DNSbunker Mirror die einzig wahre Instanz.

Messaging nutzt aktuell auch nichts, da Gerd in Urlaub ist und Patrick, seine Rechte Hand, gerade den Mirror hochgezogen hat, damit überhaupt das Build System irgendwo hin deployen kann, was nicht in 5min kaputt ist ;)

Ich versuche auch ihn nach dem Urlaub direkt mal zu erwischen ob wir vllt. was mit besserem Hosting von Git und so ausbaldovern können, damit das GH Drama endlich Ruhe findet :)

Cheers

1. Also ist das normal, dass man nur eine Subdomain anlegt?
Z.B.:
IP - Hostname -> FQDN
192.168.10.68 -> pihole -> pihole.alexanderb.de

Es macht also keinen Sinn intern und extern zu trennen, indem ich für intern sowas mache:
IP - Hostname -> FQDN
192.168.10.68 -> pihole -> pihole.home.alexanderb.de

Doof gesagt: normal ist was du draus machst.

Ich habe für intern eine interne Domain (via Subdomains) und für extern entweder die Hauptdomain selbst oder ne spezifische externe Domain. Das ist auch eine Frage der Planung sowie Software. Habe ich bspw. was wie einen Home Assistant, der mit Intern/Extern umgehen kann oder nur eine App die eine single FQDN frisst - daran entscheidet sich dann schon der erste Kram. Der zweite Punkt kommt dann dazu, wenn man gar nicht direkt mit dem Dienst, sondern bspw. via Proxy damit redet (weil der Dienst bspw. im Container und dann auf nem Highport läuft, man aber sauberes HTTPS haben will was zentral gemanaged wird).

All das spielt IMHO in die Aussage "eine/mehrere Domains" mit rein.

2) ULA haben an mehreren Stellen Sinn:

* MultiWAN: welches v6 das du von Provider 1/2 bekommst, darfs denn sein? Oder beide? Das kann maximal verwirrend für die Devices sein (wenn sies überhaupt unterstützen zwei GUAs zu haben und das sauber hinbekommen). Eine Variante ist da, dass man intern dann ULAs vergibt und nach extern je nach WAN1/2 dann NPt (Prefix Translation) macht.
* wirklich internes v6 Netz bspw. für reine interne Loops, Hardware Kommunikation, Management, etc. was aber NICHT von extern erreicht werden soll und nur intern laufen. Dort sind LLA mitunter nicht sinnvoll/unterstützt bzw. will man für bspw. Storage Kommunikation keine Adressen, die sich ggf. verändern wenn mal die HW getauscht wird.
* Parallelbetrieb von GUA/ULA für VPNs. Da GUA ja extern erreichbar sind: was tun bei VPN mit IPv6? Die GUA durch den Tunnel routen? Oder nicht? Manch einer möchte aber via der GUA "von extern" testen können und trotzdem per VPN auf die Maschinen -> ULA parallel zur GUA auflegen mit gleichem /64 Host Prefix ist dafür sehr angenehm zu nutzen.
usw.

zu 4) hast du da die neue GUI Komponente aktiv unter Reporting/UnboundDNS? Da stand doch in der Client Spalte die IP die fragt (meine ich)?

zu 7) Sollte für RW Setup eigentlich recht einfach umsetzbar sein. Alternativ gäbe es mit Tailscale & Netbird auch 2 auf Wireguard aufsetzende Systeme. Das kann man sich für zu Hause im Free Tier eigentlich ganz angenehm konfigurieren, man ist dann aber natürlich wieder auf den DL ein wenig angewiesen, dass die Verbindung klappt (außer man hostet Headscale/Netbird selbst, aber das sprengt das Thema hier). Das nur als Alternative.

Cheers
\jens

Dann würde ich ja auch per HTTPS auf die Firewall kommen? Könnte ja auch sein das man mal unbeabsichtigt eine Regel erstellt und daran nicht denkt...

Das ist ein schlechtes Beispiel, auch wenn ich mir denken kann was du meinst, aber dieser Fall wird IMMER eintreten. Wenn du schlicht any/HTTPS erlaubst dann wird auch immer die WebUI wenn nicht auf anderen Port umgelegt mit freigegeben sein. Daran ändert auch eine Block any Regel danach nichts. Und davor bringt sie 2x nichts, denn dann würde gar nichts mehr erlaubt werden ;)

Da solltest du dir vielleicht einmal den generellen Regel-Flow anschauen, was wann wie in welcher Reihenfolge abgearbeitet wird. Prinzipiell kann man das relativ einfach zusammenfassen mit:
* alles was nicht implizit (via Regel) erlaubt ist wird geblockt
* Reihenfolge ist top down
* Regeln (Floating) gelten vor Regeln (Gruppen/Multi-Interface/[bspw.]VPNs) gelten vor Regeln auf einzelnem Interface

Cheers :)

• Interfaces > LAN > Static IPv4 address = 192.168.1.2/24

Also ich finde subjektiv ja, wer dem Gateway/Router nicht .1 oder .254 gibt, der hat psychotische Tendenzen :P aber das kann ja jeder halten wie er mag. Ich find sowas unsauber und intransparent beim Debuggen.

Wie du dein VDSL/PPPoE herstellst, das hängt vom Anbieter und nicht von irgendeinem Howto ab. Auch Telekom macht stellenweise schon Setups ohne VLAN7 (weil VLAN6/Multicast stirbt und wegfällt). Also kann sein dass es bei dir so passt.
Ob man mit dem dynamischen IPv6 Kram glücklich wird, hängt wahrscheinlich eher von den Disconnect-Timeouts ab, also wann es ne Trennung gibt. TDSL sollte ja theoretisch nur noch so grob alle 3-6 Monate eine machen - da kann das dann gut funktionieren. Wie oft sie das v6 Prefix ändern, weiß ich nicht, da gibt es auch Anbieter, die da Hardcore alle 24h nen neuen Prefix announcen und dann macht v6 wenig Spaß :/

Cheers