Messages

Du kannst prüfen ob der lighttpd Server läuft:

Code Select Expand

sockstat -P tcp | grep -E '(80|443)'
root     lighttpd   87831 7   tcp4   *:443                 *:*
root     lighttpd   87831 8   tcp6   *:443                 *:*
root     lighttpd   87831 9   tcp4   *:80                  *:*
root     lighttpd   87831 10  tcp6   *:80                  *:*
...

Die logs des Webservers sind unter /var/log/lighttpd/ zu finden, die Systemlogs unter /var/log/system/.

Hast Du einen Neustart der Sense gemacht nach dem Update?

The standard, automatically created 'Default LAN allow' firewall rules does not log, that is why you don't see that traffic. If you enable it - and keep the default logging for blocked and passed packets - you will see two matching rules, one on the LAN interface and one on the WAN interface.

Maybe it's worth going one step back: What rules do you have on the WAN interface? Per default there are no open ports on it.

As a best practice, it is recommended to protect LAN interfaces

Yes, but then you would not select "Show WAN interfaces". Or at least you would not select the WAN interface to be protected.

What is the OPNsense version you are running and what is the deployment mode?

With the settings (security zones set for LAN and WAN) in you first post/screenshot the error message should not appear. Just for a test, what happens when you remove the security zone from WAN and apply the 'lan' security zone? And if the error message disappears, remove the 'lan' and add the 'wan' security zone again.

Have a read through Zenarmor: Web UI Initial Configuration, Zenarmor (Sensei): Installing via Web Interface and Best Practices for Zenarmor Deployment.

That will give you a good overview over setting up Zenarmor.

What does it say when you click the 'i' icon? Often if a allow-all rules is blocked the it's connections with TCP options, which are blocked by default. Check your rule, under 'Advanced features' -> 'allow options'.

Btw: you 3rd rule, redirect NTP to local is an odd rule: it will never be executed, it's already included in the first rule.

ist es auch möglich, den Tunnel mit einer ULA einzurichten, und dann eine Art Route zu konfigurieren, sodass meine Wireguard Peers über die IP der opnsense ins Internet können?

ULAs entsprechend den privaten IP Bereichen im IPv4, eine IPv6 NAT Regel ist notwendig damit ULAs auf das Internet zugreifen können.

Is it possible that Opnsense can get into a infinite loop with the DNS server(s)?

I'm really not sure, in what scenario would you think that a loop be possible? The flow should be either 'client - pi-hole - unbound' or 'client - OPNsense - pi-hole - unbound'. Would there be a situation where unbound sends a request to pi-hole?

You don't haven any influence over what website uses to determine you location. And it wouldn't matter what router OS you run.
Was it different when you were running pfSense? Did you get an IP from another range?

https://ipinfo.io and https://www.maxmind.com/en/geoip-web-services-demo are two ways (amongst) many to check our public IP.

But again that doesn't really matter, the website's IP geolocation DB is maybe outdated. Or the IP range your ISP uses is only recently allocated to your ISP.

If it's important to you, then do use a VPN to connect to some location in the US and check if it changes.

I the meantime I also upgraded to 25.1.8 and the issue is gone.

That's even better, they found the issue too and fixed it.

hint.uart.0.at="isa"

You add that line to the file /boot/loader.conf.local (without 'set') and it will be applied during boot.

To add it you execute:

Code Select Expand

echo 'hint.uart.0.at="isa"' >> /boot/loader.conf.local

Wow, uptime von 20252 Tagen, nicht schlecht :) (wenn es wohl auch eine Fehlanzeige ist.

• Kannst Du auf die auf Konsole des N150 gehen und dir die Logs ansehen (/var/log/lighttpd/, /var/log/system)
• Und passiert es auch mit einem anderen Browser?
• Und kannst Du die Temperatur prüfen (sysctl -a | grep temperature)? RJ45 Transceiver im SFP+ werden ganz schon warm/heiss. Und wenn es ein ungekühltes Geräte ist, und schön klein, wird eventuell das Ding zu heiss.

You redirect does work, indeed.

If I remember correctly, in the case of a device trying to query (let's say) 1.1.1.1, on pi-hole the originating client is listed as OPNsense, since it is forwarded from OPNsense. Is that not so? That is why I thought it would be helpful to have logging for one or all of these rules enabled, temporarly.

If you now manually query 1.1.1.1 from a client, what does the pi-hole show as the client?

Update/edit: I found this https://forum.opnsense.org/index.php?topic=28602.0 - lucky my German is not that bad :-) I'll check this first, you will never know.

(I do speak German) It's about setting the disabling legacy UART. Does the device even have a normal BIOS? If yes, of course try it (but it would hint towards an issue with the console).

My IPv4 LAN is on a single /24, no vLANs or seperate subnets

That means if something (virus/malware/rough application/script) is trying to contact a public DNS directly, it will show up on the pi-holes as if the query came from OPNsense but it may really be originating from a client.

Enable "Log packets that are handled by that rule" for your DNS-redirected-to-pihole rule. If a clients makes these request you would see them.
You cannot view this attachment.

Also, I've never been to that site, or any of its related github links

There is not much going on on that site anyway, no reason to visit it at all, but maybe it's infected.