Messages

Updated to 24.7 r.2 yesterday morning. All went well and working from home was fine.

This morning, DNS resolution was broken - Adguard Home was not resolving (I think - might have also been Unbound as I am running Adguard Home -> Unbound as resolver).

A reboot did NOT help. (Re-)Starting Adguard Home manually from the CLI errores out due to a service "yy" blocking the port (?).

Rolling back (via bectl) to 24.1.10_3 helped instantly - II am up an running without problems.

Apologies for lack of detail - cant dig deeper / replay the erroneous config right now, so just a word of caution and not a full bug report.

Doesn't seem to be the kernel issue, as I am running virtualized in ESXi.

(Edit: fixed title)

On the certs:

I use a very easy setup with acme let's encrypt certificates:

1. Use a wildcard cert

2. Paste into adguard home GUI settings -> encryption settings:

Certificate path:
/var/etc/cert.pem

Key file path:
/var/etc/key.pem

Works.

I gather the regular approach is to use firewall rules to control whether e.g. NTP is available or not to a given subnet, not limiting the "listen to" interface settings in each service.

Works for me. No WAN rule "pass"ing traffic to port 123 = nobody from outside can access my local NTP server.

Do not use the Opnsense box for WiFi. Use a separate AP.

PCIe 3.0 x1 is 8 GT/s or 0,97 GByte/s (https://www.heise.de/select/ct/2020/24/2014911062765141952), so yes, 4x Gigabit is no problem.

As to cards, customary proposal would be an Intel i350-T4 (and variants) -- buy used, but beware the fakes (https://forums.servethehome.com/index.php?threads/comparison-intel-i350-t4-genuine-vs-fake.6917/).

Wouldn't this be a classic case for (free)RADIUS?

- unknown / unauthenticated clients are assigned to the untrusted VLAN
- authenticated clients are assigned to the trusted VLAN

(note: I've always wanted to set this up on my home network to cleanly separate work and private devices, but have never gotten round to it)

There are several forum threads on power consumption.

One in particular recommended using powerdxx and playing around with the C states. Try here: https://forum.opnsense.org/index.php?topic=28033.0

But generally speaking, a firewall is unlikely to reach high C states because it will invariably be woken up by incoming traffic (= interrupts). Plus, certain NICS or NIC settings will prevent high C states (example: Intel 1G NIC, an i219 IIRC, will prevent high C states if you enable jumbo frames).

Try a CPU with less cores but higher per-core ooomph (higher IPC, higher CPU frequency, etc.)

And try it without using HyperThreading (SMT).

Sounds more like an issue with getting internet connectivity to OPNsense than the routing/firewalling.

Just checking that you
- do not use USB NICs
- do not use Realtek NICs (or if you do, have installed the plugin drivers)
- do not use Intel i225 / i226 NICs ?
- do not run OPNsense virtualised
- have checked and re-done the cabling

I have enabled "OPNsense-App-detect/test" with suricata in IDS Mode. Opnsense 23.7.1_3. Suricata listening on LAN and VLAN interfaces (not WAN).

Testing eicar download via HTTP wget/curl triggers the alert. Using a browser doesn't because the browser/website switches to HTTPS automatically.

That is probably because the device got a DHCP dynamic address while being unnamed and you subsequently "named" it. It should fall into one item on next DHCP release or at least next reboot.

Thanks - just ran into the same issue.

It certainly can be fixed, but would need to be done by @mimugmail as maintainer of the OPNsense community repo.

I've posted a bug at https://github.com/mimugmail/opn-repo/issues/173

It could also be the Realtek NICs acting flaky. Have you installed the newer driver from the plugins?

I could not get the OPNsense backend to work with a CloudFlare token using only v4. It would generate this error:

Account XXX [cloudflare - XXX ddns] error receiving ZoneID [[{"code": 6003, "message": "Invalid request headers", "error_chain": [{"code": 6102, "message": "Invalid format for X-Auth-Email header"}, {"code": 6103, "message": "Invalid format for X-Auth-Key header"}]}]]

I think that "Invalid format for X-Auth-Email header" indicates that you are not using Cloudflare "token" service (if token auth is used, it would read something like "bearer authentication").

You need to use username "token" (literally "token"!) or leave it empty to use the token authorisation. DO NOT USE YOUR CLOUDFLARE EMAIL / USERNAME!

Running adguard and chrony and never had an issue between those two.

I assume you have disabled the regular NTP server service? (Services -> Network Time -> General -> "Time Servers" empty and "Client Mode" ticked)

And another wild shot in the dark: You have disabled the rate limit in Adguard Home (Settings -> DNS Settings -> Rate Limit set to "0")?