Messages

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")?

you can install Chrony and use NTS.

Yep. Here's a list of NTS servers:
- https://gist.github.com/jauderho/2ad0d441760fc5ed69d8d4e2d6b35f8d
- https://gitlab.com/-/snippets/2481323

I use:
time.cloudflare.com,ptbtime1.ptb.de,ptbtime2.ptb.de,ptbtime3.ptb.de,ntp2.glypnod.com,nts.sth1.ntp.se,nts.sth2.ntp.se,ntp.3eck.net,ntp.trifence.ch,ntp.zeitgitter.net,nts1.adopo.net,www.jabber-germany.de,www.masters-of-cloud.de,ntppool1.time.nl,ntppool2.time.nl,ptbtime4.ptb.de,paris.time.system76.com,ntp3.fau.de

1. Create an IP alias with a NOT ("!") setting, e.g. "!1.2.3.4".
2. Create an alias that combines your IP list and the not-IP-alias
3. Use the new combined alias.
4. Done.

No help here, but I also had some issues a few weeks back where renewals would no longer work.

I *think* it was failing the DNS challenge...?

I ended up deleting and newly creating my acme/letsencrypt config. 

That was end of February.

Re: fake i350:

https://forums.servethehome.com/index.php?threads/comparison-intel-i350-t4-genuine-vs-fake.6917/

https://www.hardwareluxx.de/index.php/news/hardware/netzwerk/58048-gefaelschte-netzwerkkarten-von-intel-bei-namhaften-deutschen-shops.html

Username should be either empty or just use the word "token". That tells ddclient to use the API token bearer mechanics. You then put your (newly generated) API token into the password field.

Note: The API token is NOT the same as your Global API Key. See https://developers.cloudflare.com/fundamentals/api/get-started/create-token/. Your token needs both DNS Read and DNS Write permissions. Lots of tutorials on the interweb.

Do NOT use any kind of individual username (such as Zone ID, account ID, email, etc.) - if you do, only your Global API Key works.

Also note this is for OPNsense 23.1 -- not sure if it already works for 22.1 legacy series.