Messages

Dazu kommt doch, dass wir uns in dieser Runde hier gerade innerhalb von Deutschland unterhalten, jedenfalls meistens. Hier ist immer noch ein Rechtsstaat und es gilt die DSGVO. Von welchen ISPs reden wir denn bitte schön?

Was glaubst du wie die Kacke am Dampfen ist, wenn Telekom oder Vodafone dabei erwischt werden, wie sie shady Zeug mit dem Verkehr ihrer ISP-Kunden machen ...

Korrekt :)

Haben die nicht mal Malware-Filter eingebaut, ohne zu fragen, und das gab einen ziemlichen Shitstorm? Jedenfalls ist "Security on net" bei der Telekom heute erhältlich und optional. Kann ja jedes halten wie sie möchten.

Jein. Der eine der beiden hatte mal "versucht" DNS zu filtern und hat dafür eine ziemliche Klage als Brett aufs Maul bekommen. Der ANDERE der beiden war "so frei" und hat Kunden bei "DNS nicht gefunden" (NXDOMAIN) einfach seine eigene DrecksSuchmaschine untergejubelt und damit die DNS Antwort von "nicht vorhanden" auf "gibts -> bitte hier lang" verfälscht, was DNS Poisoning ist und noch dazu abgreifen von Daten (was hat mein Kunde da gesucht/eingegeben) etc. etc. - wofür sie auch aufs Brett und ne Klage bekommen haben.

Also gerade WEIL sie das schon versucht haben und krachend gescheitert sind, weiß man, dass aktuell bei uns wenigstens noch halbwegs unsere DSGvO und Rechtssprechung greift. Auch wenns diverse Kandidaten immer wieder aufs Neue versuchen (siehe Vorratsdatenspeicher, aber-denk-doch-wer-an-die-Kinder DNS Sperren und Co).

[AdGuard]

Ich kann da wie Patrick auf meine Kommentare zu diesem Thread verweisen:

https://forum.opnsense.org/index.php?topic=50075.msg274087#msg274087
und
https://forum.opnsense.org/index.php?topic=50075.msg274498#msg274498

Dazu das DoHoT Projekt von Alec Muffett, der das ganze Thema DoH, DoT, DoQ und Co mal auseinander genommen hat und zum Schluß kam: wenn du WIRKLICH superverschlüsselt, hochsicher, DNS machen willst, dann gehts nur via DoH+Tor, damit sich die DoH Requests wie TOR HTTPS Traffic in der Masse tarnen können. Und das ist für die meisten absoluter Overkill. Was aber dabei interessant rauskam: das ganze Rat-Race mit "ich hab die schnellsten ms Auflösung in DNS" ist quark und du spürst davon in der Praxis kaum was. Ob jetzt dein Browser beim Webseiten-Aufruf 1x von 10x ein wenig länger braucht (ca. 500-600ms) und danach durch den Unbound Cache der Rummel dann in <1ms läuft merkst du in der Praxis kaum. Einzig bei selten aufgerufenem Kram mag das vllt mal spürbar sein, aber das geht in der Load unter.

Dann noch ein kleines Wort zu Patricks Empfehlung wegen AdGuard:

AdGuard (Home) und PiHole mögen die OldSchoolers sein, was DNS Blocking angeht, aber sie machen ihren Job absolut hocheffizient mittels dnsmasq (oder Fork davon) im Unterbau! Ich habe mal in einer unserer Freitagsrunden an denen wenig los war und kaum jemand Zeit hatte mit den 2-3 Leuts die da waren ein Experiment gemacht: Mein aktuelles PiHole Setup mit allen Blocklisten auf eine der gehypten anderen DNS Lösungen versucht zu portieren. Auch auf Unbound selbst:

Das war ernüchternd! Egal ob Unbound roh, Technitium, Blocky, CoreDNS und wie die ganzen hippen DNS Tools alle heißen: die meisten, die ich auf die schnelle mal durchspielen konnte, sind einfach an meinen Blocklisten verzweifelt im Sinne von "haben so viel RAM gefressen bis sie gestorben sind". Warum ist das relevant? Weil AdGuard und PiHole bspw. mit <1GB RAM problemlos klar kommen, da DNSmasq die Blocklisten einliest und (ich kann jetzt nur praktisch von PiHole sprechen) hasht und in schnell-durchsuchbaren Indexbäumen speichert (gravityDB). AdGuard macht da m.W. was sehr ähnliches. Dadurch können die Tools Millionen! Einträge an Domains in ein paar MB RAM abrufen. Die anderen neuen hippen DNS Tools, die alle mit so-viel-toller-Featuritis daher kommen, versuchen die ganzen Listen in den RAM zu laden und (wenn meine TestVM zu klein ist) scheitern dann und der Prozess stirbt. War gerade bei Unbound, Blocky & Technitium sehr deutlich sichtbar mit Ladekurve, RAM steil hoch, BÄM, tot, OOM-Killer.

TL;DR: wenn du ordentlich GROSSE Blocklisten hast (-> bspw. Gerds HaGeZi Pro(++) o.ä.) kommst du schnell auf 10-20Mio Domains die da auf deiner Blockliste stehen und da säuft dir entweder deine Firewall Hardware RAM wie nix Gutes weg, oder du nimmst dafür ein Tool, was den Kram in ein paar Hundert Megabyte abfrüstückt. Daher AdGuard (als Plugin auf der Sense selbst) oder intern eben einen PiHole/Adguard vorschalten (als kleinen Container o.ä. irgendwo draufgepackt) und den per DHCP dann als DNS announcen und dort dann als Upstream den Unbound der Firewall eintragen, damit dort dann das saubere Resolving läuft (statt das einfach alles zu forwarden zu irgendjemandes(TM) DNS Server).

Vorteil: Resilienz! Ich hab bei sauber laufendem Konstrukt aus PiHole + Unbound(resolver) selten irgendwelche DNS Calls die fehlschlagen oder Zensur anzeigen.

Cheers :)

Und wo ist da ne Regel für ICMP? Ich seh nur UDP und TCP?
In dem Firewall / Rules (new) Screenshot ist ein Haufen Geraffel drin, aber keine einzige Regel mit Protokoll "*" oder ICMP.
Wie soll dann Ping/ICMP funktionieren? :)

Cheers

Ich würde generell mal die DNS Sleeptime auf 150-300s stellen. 180 genügt normalerweise.

Grund: acme.sh versucht bei Werten von (ich meine) <120 DoH zu machen um DNS TXT Einträge zu verifizieren. Hat man DoH geblockt, die IPs, die DNSe oder irgendwas davon - klappt die Verifikation nicht. Hat man einen Provider, dessen DNSe etwas langsam aktualisieren - klappt die Verifikation nicht. Daher stell ich bei den meisten Systemen inzwischen auf 180s ein. Das ist u.a. auch im Wiki/Doku von acme.sh so dokumentiert, dass bei kleinen Werten das Skript DoH versucht, bei großen Wartezeiten wird dagegen dann klassisch ein normaler DNS Call gemacht.

Cheers

Checked again today, still "broken":

Certificate is picked up by cron to be renewed but is listed as "validation failed" in "Last ACME status". If you renew it manually it works, just cron is borked. Anything we can do to debug that further? With reduced certificate runtime that now gets tedious to check and confirm every few days!

Cheers
Jens

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! :)