Messages

I usually leave ants alone in my garden unless their numbers get out of hand or they start coming inside. Sometimes, though, the nests get too close to the patio or mess with my flower beds, so I try things like pouring boiling water on the mound or using ant bait traps. The boiling water works for a while but honestly, the ants usually find a way back. I've read about using diatomaceous earth but never had lasting success with it. If you're ever dealing with stubborn pests like cockroaches indoors, there are traps made specifically for that. I came across a product called InfektTrap that's supposed to work really well for indoor infestations, especially since it's pet-safe and doesn't smell weird, https://sonic-barrier.us/products/infekttrap.

Yeah, Zenarmor could definitely help. It's pretty good at monitoring network traffic and spotting suspicious stuff. For a small setup like yours, it can give you useful insights without being too heavy. Just make sure you configure it right and keep an eye on alerts. It's not a magic fix but definitely a solid tool to add to your toolkit.

I ran into a similar issue when switching from legacy configs to instances. Most things carried over without any problems, but I hit a snag with older providers that still needed specific ciphers like AES-256-CBC. Couldn't find a clean way to handle that directly in the instances UI either, so I ended up sticking to legacy on a couple profiles that needed the extra settings. Wish they gave more flexibility on custom options in the new setup. For something similar with less hassle and more control, I've started using Xenaps Services occasionally. They don't mess around with strict KYC, and it's been smooth for managing different tools and VPN setups.

In my case, checking the Unbound logs really helped pinpoint the issue, so that might be worth a shot for you too. Adding whitelisted URLs should usually work, but I've also found that DNSSEC settings can sometimes cause access problems.

If it keeps acting up, you might consider looking into the microsoft 365 price for a more stable experience. I found that having direct access without these DNS headaches made a big difference.

Hey,  haven't heard any solid news about AI or machine learning being integrated into OPNSense just yet. I've been following some of the OPNids work, and while it's pretty cool, I think it might take a bit longer for OPNSense to adopt those features. It's definitely something to keep an eye on, though—always interesting to see how these projects evolve.

I've had a similar issue when I was running dual firewalls. Switching to VRRP helped a lot since it allows one router to take over the virtual IP if the other is in maintenance mode, which kept my LAN connected even when I was upgrading. I also made sure both routers were advertising the same routes to avoid losing internet access if one went down. It's worth checking your firewall rules, too, just to ensure they're allowing the right traffic even when one router is offline.

I've run into that -240 demotion issue before, and it usually points to a problem with the interface links for the CARP VIPs. It's a good idea to check if all the interfaces are up and stable. I found that looking through the logs can help identify any interface flaps or errors that might be causing the issue. When I had similar problems, restarting the CARP services on both units did the trick for me.

It's possible that some ports or protocols used by Office 365 are being restricted. I had customer support helping me when I had this issue, consider it. Mine was included in my Office pack, you can find it here.

It's lightweight and easy to use, and it blocks malicious IPs based on community input. It does what I need it to do.

Try manually setting the proxy on COMPUTER02 to 192.168.1.247:3128 in Windows Internet settings. Make sure to bypass the proxy for local addresses if needed. Also, check OPNsense firewall rules to ensure they aren't blocking the proxy traffic, and verify Zenarmor is configured to allow connections from other IPs.

[Endpunkte WLAN (PC, Noti, Smarti): DNS-Server WLAN-Fritzbox (im Home-Netz)]

So, das Testen der Sense hat doch sehr viel mehr Zeit gefressen als gedacht, aber nun habe ich zumindest jeden Menüeintrag einmal gesehen ...

Mein zentrales Problem scheint zumindest ansatzweise gelöst, aber der Reihenfolge nach:

Zur Architektur nochmals Folgendes:

   
• Alle Endpunkte (Windows PC, Smartphones, Notebooks) sind per WLAN "ganz üblich" über eine FB konnotiert, die mit Ihrem WAN-Interface an einem Sense-Port "hängt". Die FB wird nur als WLAN-Host benutzt, da dies wesentlich komfortabler ist als beispielsweise die Sense mit einem WLAN Netz auszurüsten. Die FB "verteilt" Standard-Gateway und DNS-Server via DHCP, dabei trägt sich die FB selbst als Standard-Gateway und DNS-Server im Heimnetz ein. Geprüft und ok, aber wenn man vergisst, nach Änderungen die lokalen Caches zu löschen, steht man ziemlich im Wald!!

   
• Auf der WLAN ("Internet") Seite der FB "holt" sich die FB selbst per DHCP von der Sense am LAN-Interface die Gateway- und DNS-Server Koordinaten. Die Sense wird dabei das Standard-Gateway und die IP-Adresse des Pi (Pi-Hole) wird als DNS-Server übermittelt (beides geprüft und ok).

   
• DNS-Anfragen werden (habe ich überprüft!) so sämtlich an Pi-Hole übermittelt. Auch dies kann man sehr schön im Log (Pi-Hole Dashboard) sehen. Diese schickt nach Filterung die DNS Fragen via LocalHost an den DNS-Resolver (Unbound) - alles Pi-lokal - und gibt die Ergebnisse der Namensauflösung an die Sense zurück. Auch dies lässt sich gut bestätigen (Host Anfrage der Sense z.B. auf der Konsole) und funktioniert.

   
• Die von Pi-Unbound erzeugten DNS Anfragen werden über den OPT1 Port an die Sense (Standard-Gateway) geschickt. Hier muss noch geprüft werden, ob diese über den VPN Tunnel oder normal per WAN transportiert werden. Auch sind noch Fragestellungen offen, wie eigentlich die Namensauflösung funktioniert, solange der VPN Tunnel noch nicht steht. Vorab: es funktioniert, aber ich habe es noch nicht verstanden, da zum VPN Aufbau (genau) eine DNS-Auflösung (ohne Tunnel) benötigt wird. Auch müssen noch Tests bezüglich eines Kill-Switches realisiert werden, wenn der VPN Tunnel ungeplant zusammenbricht.

   
• Die Sense verwendet auf der WAN-Port Seite - Richtung Internet - eine separate weitere Fritzbox als "Ersatz-Modem" im Exposed-Host Modus, die dann mit dem Internet des ISPs verbunden ist. Diese Lösung war kostengünstig greifbar, Performance ist gut und die Box bleibt remote administrierbar.

Damit sollte auch die Frage geklärt sein, wer den DNS-Server stellt: Es ergibt sich hier die per DHCP aufgebaute Zuordnungskette:

   
• Endpunkte WLAN (PC, Noti, Smarti): DNS-Server WLAN-Fritzbox (im Home-Netz)
• WLAN-Fritzbox (WAN Seite): DNS-Server Pi-Hole
• Sense: DNS-Server Pi-Hole
• Pi-Hole auf dem Pi: verwendet den DNS-Server Unbound per LocalHost, Anfragen gehen über die Sense ins Internet.

Wesentlich, die entscheidende Einstellung war (u.a.):
Unter Firewall: NAT: Port Forward:
Interface: LAN, Protocol: TCP/UDP, Destination Invert, Destination : LAN address, Dest Port Range : DNS, Redirect target IP : 127.0.01 (verstehen ich allerdings NOCH nicht), Redirect target port: DNS.Unter Setup ,,System:Settings:General":Pi-Hole als einzigen DNS Server mit Gateway ,,none" eintragen.
DNS-Server Options: Kreuz machen bei ,,do not use the local DNS ...", Rest ungekreuzt. Damit verschwindet LocalHost als Namensauflöser (DNSMASQ oder Unbound).

Dnsmasq ist im Forward-Mode. Folgende Optionen sind gekreuzt:

   
• Enable Dnsmasq
• Enable DNSSEC
• Register DHCP leases
• Register DHCP static mappings
• Rest nicht aktiviert!

Nachdem das jetzt läuft, müssen noch die restlichen Firewall Regeln aktiviert bzw. geprüft werden.

Bezüglich der Regeln bin ich gerade dabei, diese komplett neu zu gestalten und zu testen. Wird noch etwas dauern.

Ohne Sense (z.B. an einer Fritzbox) funktioniert der Pi problemlos.

Ich vermute allerdings auch, das die vom Pi ausgelösten Unbound DNS Requests (via LocalHost auf dem Pi) nur von der Sense durchgereicht werden (Pi kann ja DNS korrkt auflösen), aber NICHT für die Sense-interne Namensauflösung verwendet werden. Damit bekommt der Pi seine korrekte DNS-Auflösungsantwort, aber die Sense benutzt die Antwort nicht.

Paket Transport Weg:

LAN-Client (Windows) --> DNS Router (Fritzbox) --> DNS Gateway Sense (via DHCP) --> Forwarded to Pi@OPT1 Port --> Pi-Hole Filter --> Pi@127.0.0.1 (Unbound) --> DNS Standard-Gateway Sense für UDP-Port 53 Pakete --> Redirektion to VPN Tunnel --> Tunnelaustritt beim VPN Provider --> authoritative/Root Server DNS Server Kontakt (und dann die Kette wieder retour).

Ich versuche das Problem weiter zu verstehen ...

Moin moin dsecure,

Zunächst einmal Danke für den Link, allerdings geht s so nicht bei mir:

   
• Der Pi-Hole "sitzt" an einem sparaten Port (OPT1), also nicht auf dem LAN-Interface.
• Der Pi-Hole verwendet selbst Unbound zur DNS-Auflösung, daher macht Unbound auf der Sense wenig Sinn.
• Auch nach einer Adaption der Forward Regeln (statt localhost die IP vom Pi-Hole) geht s nicht.
• Für die DHCP Services verwende ich Dnsmasq, aber der löst keine DNS-Anfragen auf.
• Die von Pi-Hole ausgelösten DNS-Anfragen versuche ich per Redirekt wieder einzufangen, um sie dann in den VPN Tunnel einzuleiten, damit diese Port-53 Requests erst beim VPN Provider aus dem Tunnel ins Internet geroutet werden.

Sobald ich nur den Pi-Hole als System-DNS eintrage, ist alles andere egal, die Sense macht keine DNS-Abfragen mehr!
Erst mal vielen Dank, gibt es weitere Vorschläge?

Hallo,

Irgendwie hänge ich mit meiner Sense an einem ,,Denk"-Problem fest:

Setup: Ich habe einen Raspi 4 mit dem Pi-Hole (v4.3.1) und lokalem Unbound Service per LocalHost an einem separaten Interface (OPT1, igb2) der Sense (v20.1.a_120-amd64) angeschlossen. Pi-Hole soll sämtliche DNS Anfragen der Sense ,,bearbeiten". Dazu sind auf der Sense ,,Services: Dnsmasq DNS: Settings" sowie ,,Services: Unbound DNS: General" disabled. Als einziger DNS Server ist im Setup der Sense die IP-Adresse des Pi-Holes unter ,,System: Settings: General" eingetragen. Die beiden Optionen unter ,,DNS server options" sowie ,,Gateway switching" sind nicht ,,angekreuzt". Für die DHCP IP-Adressenmetrik ist die MAC-ID des Raspis als statistisches Interface Mapping unter ,,Services:DHCPv4: [OPT1]" eingetragen. Raspi kann sämtliche Netze (LAN, WAN) per Ping erreichen, ebenfalls wird Raspi aus diesen per Ping erreicht.

Problem: Die Sense IGNORIERT für eigene DNS-Anfragen den als System DNS eingetragenen Pi-Hole:

root@OPNsense:~ # host intel.de 192.168.10.9
Using domain server:
Name: 192.168.10.9
Address: 192.168.10.9#53
Aliases:

Host intel.de not found: 2(SERVFAIL)

Grundsätzlich werden allerdings (auch nicht eingetragene) externe DNS-Server erreicht:

root@OPNsense:~ # host intel.de 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

intel.de has address 13.91.95.74
intel.de mail is handled by 100 mtab.intel.com.

Wird hingegen ein externer DNS-Server (z.B. 8.8.8.8) unter ,,System: Settings: General" eingetragen, dann wird die DNS-Anfrage ebenfalls korrekt aufgelöst:

host intel.de
intel.de has address 13.91.95.74
intel.de mail is handled by 100 mtab.intel.com.

Wird der Pi-Hole im Setup unverändert an einem LAN-Switch des Routers (FB) angeschlossen und als DNS-Server verwendet, so funktioniert alles prima, Pi-Hole tut also was er soll.

Auch wenn der Raspi an de Sense-Interface angeschlossen ist, so kann auf der SSH-Console des Raspis sowohl auf die Sense als auch auf das Internet zugegriffen werden. Auch funktioniert die DNS-Auflösung:
 
xxx@RaspiPi4:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.9  netmask 255.255.255.0  broadcast 192.168.10.255
        inet6 fe80::dea6:32ff:fe07:XXXX  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:07:XX:XX  txqueuelen 1000  (Ethernet)
        RX packets 82766  bytes 10538900 (10.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 86669  bytes 14082819 (13.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 512837  bytes 123663752 (117.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 512837  bytes 123663752 (117.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

• Raspi hat per DHCPv4 die korrekte IP-Adresse (192.168.10.9) bezogen,

xxx@RaspiPi4:~ $ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

• Raspi hat als Standard-Gateway (192.168.10.1) die OPT1 Interface IP Adresse der Sense für die Default-Route bezogen,

xxx@RaspiPi4:~ $ cat /etc/resolv.conf
# Dynamic resolv.conf file for glibc resolver generated by resolvconf
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search localdomain

• 
  Raspi verwendet als DNS-Server den Unbound Service per LocalHost.

Auch die lokale DNS-Auflösung auf dem an der Sense angeschlossenen Raspi funktioniert:

xxx@RaspiPi4:~ $ dig intel.de @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> intel.de @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19619
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;intel.de.                      IN      A

;; ANSWER SECTION:
intel.de.               3600    IN      A       13.91.95.74

;; Query time: 198 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Fr Sep 06 20:21:16 CEST 2019
;; MSG SIZE  rcvd: 53

Warum verweigert die Sense den als System-DNS eingetragenen Pi-Hole? Wo ist der Wurm drin?

Hallo zusammen,

Als externen DNS-Server möchte ich einen auf Raspberry Pi 4 basierenden Pi-Hole (aktuelle Release) Resolver betreiben. Leider wird der Raspi 4 NICHT IMMER von der OPNsense erkannt, diese Erkenntnis hat mich 3 Tage Suchen ,,gekostet", da ich zunächst verzweifelt in den Routing Regeln den Fehler gesucht habe.

Mein Test-Environment:
Ein PC Engines APU.2D4 Board, Firmware coreboot mainline v.4.10.0.0, Development Release Type OPNsense 20.1.a_120-amd64 (aktuell), Raspberry Pi 4 auf igb2 (OPT1) exklusiv.

Der Raspi 4 ist wie folgt in das System eingebunden: (siehe Attachment snap-1, snap-2, snap-3)

Nach einem Kaltstart der FW wird der Raspi 4 auf der zugewiesenen IP Adresse korrekt erkannt und auch in die FW-interne ARP-Tabelle eingetragen (snap-4).

Mein Problem:
Löscht (Flush) man aber mal testweise diese Tabelle, so verschwindet der Raspi 4 Eintrag. Auch diverse (Re-)Konfigurationen der FW-Einstellungsparameter können dies bewirken. Ein (nach längerer Wartezeit) öfter vorgenommener Refresh bringt diesen (statisch definierten) Eintrag nicht wieder zurück!

Nach vielen Experimenten bin ich zusätzlich auf die folgende Merkwürdigkeit gestoßen:

Speichert man die unveränderten Einträge unter ,,Services: DHCPv4: [OPT1]" (s.o.) per ,,Safe" erneut und ohne Änderung ab, so wird der Raspi 4 erneut wieder in die ARP Tabelle eingetragen.

Dieses Verhalten ist reproduzierbar.

Es stellt sich die Frage, ob hier noch ein Konfigurationsfehler von mir vorliegt oder ob es sich um ein Initialisierungsproblem der OPNsense internen ARP-Tabelle handelt.

Es wäre schön, wenn die Community hier einen Blick riskieren könnte.