[Sammelthread] pfSense & OPNsense (Firewall- und Routing-Appliance)

  • Ersteller Gelöschtes Mitglied 63700
  • Erstellt am
Hui das ist ein guter Tipp... tatsächlich betrifft es nicht nur die Domain, sondern alle .info Adressen. Jedenfalls die paar die mir auf die fixe einfielen.

Ich hab die Einstellung gesetzt, die "normalen" info domains gehen jetzt, die spezielle allerdings immer noch nicht, liefert aber wenigstens eine neue Fehlermeldung:
domain_insecure.jpg


Die Domain Overrides sind raus
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das ist ja interessant...
Wie sieht es bei dir aus, wenn du die Domain über Interfaces- Diagnostics - DNS Lookup

testest? Da geht es ja bei mir. Auf der Shell und am Client nicht..
dns_lookup.jpg


(zur Info: die Domain und ihre mir bekannten Subdomains (api, web, id.impfnachweis.info) lösen alle auf die gleiche IP auf)
 
Zuletzt bearbeitet:
(insbesondere) wenn Du noch die Option "don't use local DNS service ..." Aktiv hast, nutzt die Firewall selbst nicht unbound, sondern fragt direkt die eingestellten DNS Server. Deshalb dürfte das über Interfaces- Diagnostics - DNS Lookup funktionieren.

Clients nutzen dann unbound und der scheint bestimmte "insecure" TLD grds nicht auflösen zu wollen (s.o.).

Das erklärt den grundsätzlichen unterschied, aber nicht warum nur die eine Domain nicht aufgelöst wird.

Zur Sicherheit: DNS blocklisten hast Du ausgeschaltet?

Ansonsten müsstest Du ggfs Split DNS einrichten, daher anfragen an .Info direkt an upstream und alles andere an unbound.

Oder unbound in den Forward Modus schalten.
 
@Anderer67 Da läuft aber anscheinend nix drauf.
Das ist korrekt, die IPs sind tatsächlich nur über die TI VPN Infrastruktur erreichbar, das ist für das DNS Problem aber tatsächlich irrelevant.
Geht denn die client-seitige Auflösung mittels unbound bei dir?
(insbesondere) wenn Du noch die Option "don't use local DNS service ..." Aktiv hast, nutzt die Firewall selbst nicht unbound, sondern fragt direkt die eingestellten DNS Server. Deshalb dürfte das über Interfaces- Diagnostics - DNS Lookup funktionieren.
Stimmt... so erklärt ergibt das Sinn
Zur Sicherheit: DNS blocklisten hast Du ausgeschaltet?
Aktuell ja, möchte das Feature aber nutzen. Allerdings: selbst wenn die Blocklisten aktiv sind würde er die Domain ja auf 0.0.0.0 auflösen und nicht ... naja nicht.

Oder unbound in den Forward Modus schalten.

Das wäre wahrscheinlich die einfachste Variante... wobei mir das hier:
Ansonsten müsstest Du ggfs Split DNS einrichten, daher anfragen an .Info direkt an upstream und alles andere an unbound.
noch besser gefällt, da les ich mich mal ein.

Wobei es ja tatsächlich nur das Symptom, nicht aber das Problem behebt..
 
Nur um das erwähnt zu haben: Du kannst Split DNS und adblocking sehr gut und übersichtlich über adguard Home lösen, dass als Plugin für Opnsense verfügbar ist. Lokales DNS kannst Du dann an unbound weiterreichen (oder auch alles bis auf .Info, je nach Belieben).
 
Nur um das erwähnt zu haben: Du kannst Split DNS und adblocking sehr gut und übersichtlich über adguard Home lösen, dass als Plugin für Opnsense verfügbar ist. Lokales DNS kannst Du dann an unbound weiterreichen (oder auch alles bis auf .Info, je nach Belieben).
DAS war der Tipp, läuft so einwandfrei. Und AdGuard (das ist noch völlig an mir vorbei gegangen) ist mir neu gewesen, hat mir aber direkt ausnehmend gut gefallen und hat direkt meinen heimischen Pi-Hole beerbt 🙃
 
Beides vermutlich weitgehend austauschbar. Wichtig zu wissen ist, dass adguard home sich mächtig entwickelt hat das letzte Jahr - reviews aus Anfang 2020 sind also überholt.

Vorteil adguard home:
- Läuft nativ unter BSD auf der opnsense und lässt sich via community repo installieren (dann separate Web GUI für die Einstellungen). Und lässt sich via opnsense-monit überwachen.
- DNSSEC, DNS-over-TLS/HTTPS/QUIC nutzerfreundlich eingebaut
- certificate der opnsense lässt sich direkt für adguard nutzen: Bei mir liegen die in /var/etc/cert.pem bzw. /var/etc/key.pem
 
  • Danke
Reaktionen: you
Im Endeffekt habe ich keinen grossen Unterschied gemerkt, aber ich finde das Interface intuitiver und informativer
 
Mal eine andere Frage, was wäre aus eurer Sicht besser als upstream DNS für adguard Home:
- local unbound resolver (also kein forwarder) mit DNSSEC und allem, was man so einschalten kann
oder
- mehrere DNS-over-TLS/QUIC Server von quad9, adguard, nextdns o.ä.

Sowohl was
- Geschwindigkeit
- Sicherheit
- privacy
angeht.
 
@asche77 Ich favorisiere ja zweites, weil nur hier eine durchgehende Verschlüsselung gegeben ist. So zumindest bei meiner Sense.
Korrekt - allerdings mit Nachteil, dass der upstream resolver (dns.quad9.net oder wer auch immer) Zugriff auf alle Deine vollen Anfragen hat. Klar kann man mehrere upstreams machen und die Anfragen verteilen. Beim unbound resolver könnte (zB ISP) alle DNS-Anfragen belauschen, aber sonst kommt man nicht an die vollen DNS-Anfragen - und wer die mitschneiden kann, kann auch die danach angefunkten IP-Adressen direkt mitschneiden ...

... bin mir weiterhin unschlüssig. Derzeit teste ich nochmal unbound als local resolver
 
Von local Resolvern bin ich mittlerweile wieder abgerückt, ist mir zu langsam gewesen. So muss man halt anderen Upstream DNS vertrauen, wobei Quad9 doch mittlerweile zu Cisco gehört, oder ?
 
Ich fahre bei mir auch einen lokalen Unbound und kann mich bezüglich Geschwindigkeit nicht wirklich beschweren.
 
Unbound läuft bei mir mit pihole auf nem raspi 3B+ - kann jetzt auch nicht sagen, dass es langsam wäre, zumindest nicht so, als würde es mir groß auffallen
 
wobei Quad9 doch mittlerweile zu Cisco gehört, oder ?
Das verwechselst Du mit OpenDNS - die gehören zu Cisco. Quad9 ist eine unabhängige Stiftung Schweizer Rechts (früher wohl mal in den USA, sind aber in die Schweiz umgezogen, um dem US-Recht zu entgehen)
 
Hab zuhause auch zwei lokale DNSn (Adguard auf ner VM und Pihole aufm Raspi), diese werden über DHCP verteilt.
Cache ordentlich groß gewählt und als Upstream den DNS meiner ehemaligen FH eingestellt.
Der hängt im DFN und demzufolge vertraue ich dem mal.
 
Gibt es einen Vorteil durch Upstreams im Vergleich zum "Selberauflösen"?
 
Wenn man den Resolver neu startet, ist er erst mal langsam, aber sobald sich der Cache einigermaßen gefüllt hat, geht ein lokaler Resolver ab wie Lutzi. Die Cache-Trefferquote liegt bei mir bei ca. 80 %.
Das ist auch meine Beobachtung - mit Cache, prefetch, serve expired gewinnt unbound als local resolver schnell an Fahrt. Habe aber noch Probleme, dass er dann bestimmte Domains nicht auflösen will (liefert zB nur CNAME aber keinen A record).

Die Kette Adguard Home -> Unbound > DoT upstream läuft bei mir dagegen äußerst lahm, U.a. werden wohl doppelte DNSSEC Prüfungen gemacht.
Beitrag automatisch zusammengeführt:

Gibt es einen Vorteil durch Upstreams im Vergleich zum "Selberauflösen"?
Doppelte DNSBL - adguard, nextdns, quad9 et Al filtern ja auch böse Adressen raus. Vorteil vermutlich gering, wenn man selbst DNSBL verwendet.
Schnellere Auflösung (bei erstem Aufruf), da upstream Cache meist größer und "besser" gepflegt.
 
Zuletzt bearbeitet:
Heya, ich hab mal 2 Fragen zu meinem OPNsense-Aufbau.
Die erste Frage ist zu VPN-Verbindungen vom Telefon in mein Netzwerk. Meine OPNsense ist hinter einer Fritzbox, diese ist dabei Router für ein 192er Netz das als WAN in die OPNsense geht. Jetzt würde ich gerne eine VPN-Verbindung in dieses Netzwerk kriegen - wie gehe ich da am besten vor?
Die zweite Frage ist zur Firewall. Kann ich bestimmte Hostadressen (also DNS-Namen bzw volle URLs) in der Firewall erlauben? Wenn ja, wie geht das?
 
Da Du ne Fritzbox hast, würde ich für die OPNsense einfach den "Exposed Host" Eintrag machen, damit werden alle Anfragen von Außen an die OPNsense weitergeleitet.
Vermutlich wirst Du aber noch einen DynDNS-Dienst brauchen, damit bei nem IP-Wechsel auch der VPN noch geht.
 
Hey konfetti :),


Ich verstehe nicht ganz warum man den Exposed Host einrichten sollte, wenn nur wenige Dienste von außen erreichbar sein sollen.

Damit werden die ganzen unnötigen anfragen an die Firewall weitergeleitet und der Mehrwert ist sehr gering.
Gibt es einen Vorteil gegenüber der Portfreigabe? Außer Sichtbarkeit von Anfragen und keine Portfreigaben auf der FritzBox.....

Meine Meinung dazu wäre eher:

1. FritzBox als Modem verwenden (Bridge-Mode)
2. Viele Öffentliche Dienste und kein Bridge-Mode möglich. (Exposed Host)
3. Wenige Öffentliche Dienste und kein Bridge-Mode möglich, dann die Portfreigaben in der FritzBox verwenden.

Da wäre dann aber eher wichtig das Routing in der FritzBox richtig zu konfigurieren, damit man kein doppeltes Nat benötigt wird.

Die FritzBox als erste Firewall Instanz zu verwenden, hat auch Vorteile.

Gruß Hipiman
 
Zu 1. wenn die FritzBox nur Modem ist, wird es daheim meist schwer mit der Telefonie, außer man setzt sich intern einen geeigenten Server für SIP auf, bzw. hat kein Analoges Telefon mehr.

Wenn die Firewall kein Exposed Host ist, musst Du halt alle Freigaben in 2 Systemen einstellen - so konfigurierst Du halt alles in der Firewall - selbst da ja teils an mehreren Stellen - je nach Konfig.
Ich hatte auch schon Probleme mit dem VPN, obwohl zwar die Ports freigegeben waren, das ein Aufbau zur Firewall nicht klappte.

Wenn Du eine mehrstufige Firewall willst, kannst Du das aber auch ganz bequem hinter der Fritzbox machen ;) - verkompliziert am Ende das ganze aber auch.
 
Interessante Frage, da muss ich mal mich einhängen...
Ich habe ein solches Setup, also Fritzbox, dahinter Opnsense, dahinter mein LAN. Telefonie macht die Fritzbox, analoge und DECT Telefone.

Jetzt würde ich gern in das Transfernetz Fritzbox <-> Opnsense ein OpenVPN Gerät stellen (DMZ für Arme, quasi) , als Backup falls die OPNsense ausfällt (die ist eine VM auf dem einzigen Virtualisierer ein Single Point of Failure) für Fernzugriff auf iLO etc...
Die OPNsense ist als Exposed Host eingetragen, damit kann ich ja keine Freigabe mehr für einen einzelnen Port machen, auf der OPNSense macht es keinen Sinn wenn der Zugriff als Sicherung gegen Ausfall...

Frage: könnte man stattdessen nicht Port 1:65530 an die OPNsense leiten und 31-35 für andere Dienste nutzen? Oder gibt das Probleme?
 
Heya, ich hab mal 2 Fragen zu meinem OPNsense-Aufbau.
Die erste Frage ist zu VPN-Verbindungen vom Telefon in mein Netzwerk. Meine OPNsense ist hinter einer Fritzbox, diese ist dabei Router für ein 192er Netz das als WAN in die OPNsense geht. Jetzt würde ich gerne eine VPN-Verbindung in dieses Netzwerk kriegen - wie gehe ich da am besten vor?
Die zweite Frage ist zur Firewall. Kann ich bestimmte Hostadressen (also DNS-Namen bzw volle URLs) in der Firewall erlauben? Wenn ja, wie geht das?
1.
Exposed Host und DynDNS in der Fritzbox.
Alles andere ist Gefrickel.
2.
Die Firewall arbeitet per default anders rum (alles raus erlaubt, alles rein geblockt).
URLs gehen nur mit deep packet inspection und TLS-Bruch in der OPNsense.

Frage: könnte man stattdessen nicht Port 1:65530 an die OPNsense leiten und 31-35 für andere Dienste nutzen? Oder gibt das Probleme?
Das Hauptproblem besteht schon in dem Parallelweg zu deiner OPNsense.
Das VPN-Gerät ist ja quasi ein zweiter Router in dein Netz, da musst du dieselben FW-Einstellungen machen wie in der OPNsense.
 
Das Hauptproblem besteht schon in dem Parallelweg zu deiner OPNsense.
Das VPN-Gerät ist ja quasi ein zweiter Router in dein Netz, da musst du dieselben FW-Einstellungen machen wie in der OPNsense.
Das ist korrekt, bzw einfacher weil sie keine Clients hat.
Würde das denn überhaupt funktionieren?
 
Wieso keine Clients?
Wenn du auf dein iLO zugreifen willst, hast du doch schon nen Client?
D.h., du musst das VPN-Gerät zumindest ins selbe VLAN hängen, an dem deine iLO hängt.
Somit hat jemand von außen Zugriff auf alle Clients in diesem VLAN.

Ja, würde funktionieren, da das VPN ja nur einen Port für den Tunnel braucht.
Dein SPoF ist aber trotzdem die Fritze. =)
 
Ich wollte eigentlich keinen Exposed Host einrichten, weil ich mich hinter meiner natürlichen NAT-"Firewall" der Fritze ganz wohl fühle. Wenn ich jetzt einen Posrt doppelt NATen muss, finde ich das weniger schlimm als auf die zusätzliche Sicherheit zu verzichten - denn gehen tut es ja. Das ist dann nicht Mission-Critical, ich würde gar auf DynDNS verzichten (stattdessen bei IP-Wechsel mein Telefon darüber informieren). Die Frage ist nur: Wie geht dem?
Zu der zweiten Anfrage: Wie würde man denn folgendes realisieren: Alle Geräte in einem Netz (Tablets für Kinder) sollen nur Updates ziehen können und den Store besuchen können, alles andere soll zu bleiben. Idee?
 
als Backup falls die OPNsense ausfällt (die ist eine VM auf dem einzigen Virtualisierer ein Single Point of Failure) für Fernzugriff auf iLO etc...
Warum nicht einfach richtig machen?
Sowas bekommt man mit nem ATOM Board und einer quad NIC easy hin. Braucht keinen Strom und alles ist easy.
Das ganze so konfiguriert, dass die VM immer primary ist und ab geht die Post.
 
Ich wollte eigentlich keinen Exposed Host einrichten, weil ich mich hinter meiner natürlichen NAT-"Firewall" der Fritze ganz wohl fühle. Wenn ich jetzt einen Posrt doppelt NATen muss, finde ich das weniger schlimm als auf die zusätzliche Sicherheit zu verzichten - denn gehen tut es ja. Das ist dann nicht Mission-Critical, ich würde gar auf DynDNS verzichten (stattdessen bei IP-Wechsel mein Telefon darüber informieren). Die Frage ist nur: Wie geht dem?
Zu der zweiten Anfrage: Wie würde man denn folgendes realisieren: Alle Geräte in einem Netz (Tablets für Kinder) sollen nur Updates ziehen können und den Store besuchen können, alles andere soll zu bleiben. Idee?
1.
DynDNS (einfach in der Fritze einrichten).
Alles andere IST Quatsch.
Klar kannst du irgendein Skript schreiben, was alle 5s die externe IP checkt und dir dann ne Mail oder ne SMS schreibt, wozu?

2.
Geht nur über DPI oder nen DNS-Blocker.
Updates werden ja über LoadBalancer über mehrere IPs (und auch Subdomains) verteilt.
Eventuell könnte man die AdGuard Home Store-Blocker-Liste in eine Whitelist umwandeln.
Also, wenn DNS-Anfrage von IP "Kinder-Tablet" kommt, dann schau nach ob diese in der IP-Whitelist drin ist, ansonsten liefer 0.0.0.0 zurück.
Das kann und wird aber zu unschönen Nebeneffekten führen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh