Messages

Since you have to reboot anyway, I throw the Intel NVM updates on a FAT32 USB stick with an EFI shell (for machines that don't have one built in) (command reference), and use the EFI updater. Probably not worth the effort for a few devices, but conveniently OS-independent. I usually make the stick DOS bootable and throw BIOS updates on it as well.

[...]
I have no idea where that org got the code for IGC. [...]

Most (if not all) drivers for Intel devices are provided by Intel. FreeBSD devs make few (if any) changes, so FreeBSD ends up with a lot of issues in common with Windows. The Linux drivers tend to get more third-party attention - there was a similar issue with the 82574/82579 (discrete/integrated Ethernet) years ago (~2011) that was fixed in Linux but persisted in Windows and FreeBSD.

Have you tested the hardware outside of OPNsense? e.g. memtest86 and mprime. I don't have a suggestion for testing the SSD, other than checking SMART counters (offhand I don't see the device-specific counters in the OPNsense SMART utility, so I'd look from a shell).

[...]
but recent x64 CPUs often sport AES-NI support. [...]

SSE-era: Intel Westmere (2010), Silvermont (2013); AMD Bulldozer (2011). I don't know about the code-level support (parallelism and width: early devices had one 128 bit path, while later ones have up to two 256 bit paths).

[...]there are hardware accelerators available[...]

Lots of discussion in the "Hardware and Performance" section, for Atoms with QuickAssist, mostly. There are few drivers available, and it seems like a faster CPU could wipe out any advantage from the accelerator.

Aside: I mostly worked with IPSEC ~20 years ago. Stuff's a bit faster now.

No problems here. The usual: Newer firmware (NVM) is usually better, and check temperatures in a low-airflow environment (vs. i350).

"Firewall: Diagnostics: Statistics" -> "rules" -> "filter rules" (expand) also gives the "rulenr", UUID, and definition.

What do the kids say these days? "Pics or it didn't happen"?

In this case, most diagnostic would be logs from "Firewall: Log Files: Plain View" with the definitions of the rule(s) in question (capture of "Firewall: Rules: [interface]" may be sufficient). Unfortunately the quickest way I can see to correlate logs to rules is via the "Firewall: Log Files: Live View" -> "i" ("Detailed rule info") for the rule in question, as it gives the "rulenr" value (assuming the additional correlation of a unique Description/label). Log reference. Naturally the "Detailed rule info" for the particular event would suffice in place of the log, but that may be inconvenient to capture.

Someone else here may have a better method.

I'd check those blocks in the live log, particularly using the "i" on the right. Protocol or protocol-related attributes such as TCP flags can be tough to spot offhand - it's easy to get locked into the address/port pair.

[...]Not 100% this would work with OPNsense.

I use that method (switch as port expander via VLANs). I use bridges on the firewall to limit rulesets. The only downsides I recall offhand are limitations in netflow port statistics (bridge stats are OK; port stats are mostly unavailable) and potential ARP issues (an unlimited ARP responder can mess you up).

Quick edit: The "Firewall: Log Files: Live View" is a great way to troubleshoot rulesets.

Does your System Information gadget show the same time as the latest time in the graph?

Yes, it shows current time with TZ:
"Current date/time
Tue Aug 26 9:25:27 CDT 2025"

It's about 2025/08/25 12:30 here... I believe I set the TZ in BIOS, but I don't recall.

[...]won't that be a problem[...]

Yep. Either leave the main unconfigured or unassigned. Ideally you'll configure your switch (or other device) to send only tagged packets on that port.

[...]
This is not obvious how to configure it on OpenSense, also no idea how to define a specific TRUNK port which will transport my VLANs to the switch.

Nothing to it, it's just like your other interfaces:

Code Select Expand

root@fw:/home/user # ifconfig bridge1
bridge1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: TRUST (lan)
        options=0
        ether 58:9c:fc:10:ff:c9
        inet 10.101.11.1 netmask 0xffffff00 broadcast 10.101.11.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: vlan0.109 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 19 priority 128 path cost 2000
        member: vlan0.107 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 17 priority 128 path cost 2000
        member: vlan0.105 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 15 priority 128 path cost 2000
        member: re0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 6 priority 128 path cost 800
        groups: bridge
        nd6 options=9<PERFORMNUD,IFDISABLED>
root@fw:/home/user #

(I have three more bridges as well.) Nothing defines a trunk port on OPNsense other than configuring VLANs on it.

"Services: Dnsmasq DNS & DHCP" has the option ("General" -> "DHCP"). But I wouldn't expect you'd activate it unintentionally.

[...] resolver log which were around 40Gig large [...]

That's a heck of a log. I have a server that's been running for 10 years and has only logged 3GB (errors only). Were you running a query log?

How do you know that you get one request? [...]

Firewall logs (I have logging enabled on all filters). In this case, the "let out anything from firewall host itself" rule.