Messages

Thanks for the correction. I shouldn't have used pkg update -f && pkg upgrade or plain reboot.

In my case the upgrade was:

pkg update -f

pkg upgrade

opnsense-update

reboot

The only non‑recommended parts are the manual pkg usage and direct reboot. The system update was done correctly via opnsense-update.


From now on I'll follow the official upgrade path through the GUI/console and only use opnsense-update plus yes | opnsense-shell reboot if needed from shell.

Updated to 26.1.6 from previous 26.1.5 ; upgrade initially hung in GUI but completed cleanly via CLI (pkg update -f, pkg upgrade, opnsense-update, reboot).

Unbound + dnscrypt-proxy stack fully operational post-upgrade (correct listeners, dig tests OK, dnscrypt query logs PASS).

Firewall/NAT, IPv6 (track6), and WebGUI all behaving as expected so far.

System hostwatch is running correctly after the update and "Automatic Discovery" is enabled on the desired interfaces.
Please double‑check under Interfaces → Neighbors → Discovery that "Automatic Discovery" is ticked and that the correct interfaces are selected, then apply the changes.

Thanks

This is a frequent Unbound DNS issue on OPNsense where allowlists don't take effect immediately due to caching, CNAME redirects, or incomplete propagation after adding domains.

Check Reporting First
Go to Reporting > Unbound DNS > Overview or Details to spot the blocked domain (and any CNAME chain). Click it to whitelist directly—this auto-adds to Services > Unbound DNS > Blocklists > Allowlist Domains.

Use CLI on OPNsense: dig example.com @127.0.0.1 to trace resolutions and whitelist all linked domains.

Clear Cache Properly
In Services > Unbound DNS > General > Advanced, enable Flush DNS cache on restart. Apply changes, then Reload Unbound (full reload, not just cache refresh). Also restart the service via CLI: service unbound restart.

Flush client DNS too (e.g., ipconfig /flushdns on Windows). Test again—exceptions working confirms blocklist config is fine, just needs refresh.

Official Documentation
Full Unbound setup: [docs.opnsense.org/manual/unbound.html]

Reporting guide: [docs.opnsense.org/manual/reporting_unbound_dns.html]

Thanks for the detailed explanation, Cedrik! That GitHub link clears it up perfectly—makes sense why multi-select move isn't there yet with the sequence recalc logic.

A quick workaround I've used: when batch-creating rules in the new interface, set the Sequence field manually on each one right away (e.g., 100, 101, 102) to drop them in the exact order/position you want. No repositioning needed afterward.

Feature request for multi-move would still be nice, though—maybe with a "Move selected block" option that shifts the whole range?

Hey everyone,

I've spotted a limitation in OPNsense's "New Rules" feature (latest stable version): when creating multiple firewall rules in batch from the new Rules section, you can't select them all and use the rule's buttons (Move Up/Down) to reposition them together. It only works one at a time, which gets annoying with a bunch of rules.

Is this a bug ? Anyone found a workaround?

Thanks for the feedback!

I removed the "os-intel-microcode" plugin and, after that, several reboots with both WAN   and LAN   connected have all completed successfully. The previous boot hang with only solid amber on the switch has not reappeared so far.

I'll keep monitoring and report back if the issue returns.

Hi,

hardware:

Intel N5105 box, 4 × Intel i226‑V (igc0–igc3)

NVM firmware: V2.32‑0 on all ports

OPNsense 26.1.4

LAN: UniFi Switch, LAN on igc1

WAN: PPPoE on igc3 (with VLAN)

Since updating the i226 NVM to 2.32 and running 26.1.4 I'm seeing strange behaviour on every reboot:

If WAN (igc3) and LAN (igc1 → UniFi) are connected, during boot both ports show only amber on the switch and the firewall is unreachable from LAN.

In this situation the box often seems to hang (no red status LED blinking on the chassis, no visible console progress, only amber link, no traffic) and I have to hard power‑cycle it.

If I disconnect WAN and LAN and connect an HDMI monitor, the system boots normally, the red status LED starts blinking and OPNsense comes up without issues.

Once it has booted successfully, if I reconnect WAN and LAN, everything works as expected.

Once the system is up:

Internet and LAN are stable, full speed, no drops.

dmesg shows all 4 i226‑V with EEPROM V2.32-0 and only some link state changed to UP/DOWN messages during early boot, but no errors.

ifconfig shows igc1 and igc3 as 1000baseT full-duplex, status: active.

/var/log/boot.log is clean (interfaces, VLAN, PPPoE, WireGuard, DNS, etc. all configure fine).

BIOS:

ASPM and L1 Substate for all PCIe Root Ports are already Disabled.

I also set DMI Link ASPM Control from Auto to Disabled, but the behaviour on reboot did not change.

Questions:

Is this "long amber / sometimes hanging during boot" behaviour expected with i226 + NVM 2.32 + OPNsense 26.1.4, or does it indicate a problem?

Are there any additional recommended BIOS settings (ASPM, EEE, PCIe power saving) for i226 on OPNsense to avoid this kind of boot/link issue?

Should I keep the default igc settings (no tunables), or is there a minimal recommended set for this platform?

I can provide full dmesg, boot.log and additional logs if needed.

Thanks!

From what you wrote, it sounds like you actually have two separate issues: 1) ICMP to the virtual IPs, and 2) Unbound DNS queries not being answered, even though general Internet and DNAT work.

Below is a step‑by‑step way to troubleshoot and also some explanation of what to look for.

1. Pinging 192.168.55.127 / 192.168.55.254 (virtual IPs / CARP)
When a VIP / CARP address does not respond to ping, the most common causes are:

No firewall rule allowing ICMP to the firewall

CARP / VIP not correctly bound to the interface, or the node is not MASTER

If virtualized: hypervisor not allowing MAC spoofing / promiscuous mode

Please check:

Go to Firewall → Rules → LAN (and any interface where traffic is coming from).

Add a rule like this:

Action: Pass

Protocol: ICMP

Source: your LAN network (or "any" for testing)

Destination: This Firewall (or explicitly 192.168.55.127 / 192.168.55.254)

Move this rule near the top (above any "block" rules) and Apply changes.

Go to Firewall → Virtual IPs and verify:

Type: CARP or IP Alias as intended

Interface: the correct interface where 192.168.55.127 / .254 live

On Status → CARP (failover): the active node should show MASTER for that VIP.

If this is running in a hypervisor (Proxmox, ESXi, Hyper‑V, etc.):

Make sure the virtual NIC / vSwitch allows MAC spoofing or promiscuous mode, otherwise the VIP MAC address may not be forwarded and you will not get replies to ping.

After that, from a LAN client, test:

bash
ping 192.168.55.127
ping 192.168.55.254
If this starts replying, the ICMP part is solved.

2. Unbound DNS not answering queries
You mentioned you cannot query Unbound, but you can ping 1.1.1.1 and use DNS in general, and your DNAT works. That means routing/WAN are basically fine, but the firewall is not answering DNS on the IP you expect (or is blocking it).

Please check the following:

Unbound DNS → General

Go to Services → Unbound DNS → General.

Under Network Interfaces, make sure the interfaces where your clients are (e.g. LAN, maybe the CARP/VIP interface, and "Localhost") are selected, not just WAN.

Save & Apply.

Firewall rules for DNS

Go again to Firewall → Rules → LAN.

Ensure there is a rule that allows TCP/UDP port 53 from your LAN to the OPNsense address you are using as DNS.

Source: LAN net

Destination: "This Firewall" or the VIP you want (e.g. 192.168.55.127)

Port: 53 (TCP/UDP)

Client configuration

On a LAN client, check that:

Default gateway points to the correct IP (e.g. 192.168.55.127 or .254, depending on your design).

DNS server is set to that same IP if you want HA with CARP (for example 192.168.55.127 as a shared VIP used for DNS).

Tests

From a LAN client, run:

bash
nslookup opnsense.org 192.168.55.127
nslookup opnsense.org 192.168.55.254
or with dig:

bash
dig @192.168.55.127 opnsense.org
dig @192.168.55.254 opnsense.org
If you get a timeout, it's still a firewall / interface binding issue.
If it works for one IP but not the other, then the problem is specific to that VIP / node.

Check from OPNsense itself

Go to Diagnostics → DNS Lookup and try resolving something (e.g. opnsense.org).

If this works on the firewall but not from LAN, then Unbound is fine and the issue is purely firewall / routing between your LAN and the firewall address.

3. What would help to debug further
If you are still stuck after these checks, it would be very helpful if you can share:

Screenshot of Firewall → Virtual IPs (showing the config for 192.168.55.127 and .254, with type and interface).

Screenshot of Firewall → Rules → LAN (at least the top rules, including ICMP and DNS).

Screenshot of Services → Unbound DNS → General (especially Network Interfaces section).

Output from a LAN client:

ping 192.168.55.127

ping 192.168.55.254

nslookup opnsense.org 192.168.55.127

With those, it's much easier for us to point out exactly what needs to be adjusted.

[GUIDE] Updating Intel I226‑V NVM firmware (1MB) to 2.32 on N5105 mini‑PC (OPNsense)

This guide explains how to update the NVM firmware of Intel I226‑V NICs (1MB PROM) from problematic versions (e.g. 2.14 / 2.17) to 2.32 using Intel's nvmupdate64e tool and the BillyCurtis firmware, by booting the firewall into an Ubuntu live environment.

1. Context and warnings
Typical scenario:

Hardware: N5105 mini‑PC with 3–4× Intel I226‑V (device ID 111C).

Current state (example):


dmesg | grep igc
[1] igc0: <Intel(R) Ethernet Controller I226-V> ...
[1] igc0: EEPROM V2.14-0 eTrack 0x80000110
...
 igc1: link state changed to UP
 igc1: link state changed to DOWN
 igc1: link state changed to UP
...
Problem: I226‑V NVM 2.14 / 2.17 is known to cause link flapping, random disconnects, ping spikes, especially with ASPM/EEE enabled.

Target: move NICs to FXVL_111C_V_1MB_2.32.bin (EEPID 80000425) as documented by BillyCurtis and in the OPNsense thread:

"[solved] Intel i226 Firmware (see post #39]"
https://forum.opnsense.org/index.php?topic=48695.0

DISCLAIMER: You do this at your own risk. Always back up the NVM first, never power‑off during an update, and read the Intel "Quick Usage Guide" that comes with the tool.
�

2. References
Main OPNsense thread (read post #39 and following):
https://forum.opnsense.org/index.php?topic=48695.0

BillyCurtis Intel I226‑V NVM firmware repo (1MB/2MB bins + README):
https://github.com/BillyCurtis/Intel-I226-V-NVM-Firmware
�

Ready‑made package (tool + 1MB 2.32 bin + example cfg + README):
https://intel226bucket.s3.us-east-1.amazonaws.com/i226.zip
�

Intel document: "Intel Ethernet NVM Update Tool – Quick Usage Guide for FreeBSD" (included in the ZIP, Revision 1.4, 333909‑005).
�

3. Preparation (on OPNsense and on a separate PC)
3.1. Check NICs and current NVM in OPNsense
On the OPNsense console / SSH:


dmesg | grep igc
ifconfig igc0 | grep ether
ifconfig igc1 | grep ether
ifconfig igc2 | grep ether
ifconfig igc3 | grep ether
Example output (adapt to your box):

I226‑V with NVM 2.14, EEPID 80000290 (→ I226‑V 1MB 2.14 bin in BillyCurtis README).
�

MAC addresses (example values):

igc0: 00:AA:BB:CC:DD:10 → 00AABBCCDD10

igc1: 00:AA:BB:CC:DD:11 → 00AABBCCDD11

igc2: 00:AA:BB:CC:DD:12 → 00AABBCCDD12

igc3: 00:AA:BB:CC:DD:13 → 00AABBCCDD13

Write your own MACs down in both formats (with and without colons) for later use with -m.
�

3.2. Prepare two USB sticks
USB1: Ubuntu Desktop live (created with Rufus / Balena Etcher from the ISO).
�

USB2: plain FAT32 stick for firmware files.

On USB2:

Download and extract:
https://intel226bucket.s3.us-east-1.amazonaws.com/i226.zip
�

Create a folder i226-fw.

Copy into i226-fw:

nvmupdate64e

FXVL_125C_V_1MB_2.32.bin

nvm.cfg

Optional: Intel PDF and the README.

3.3. Adjust nvm.cfg for 1MB I226‑V 2.14 → 2.32
Open nvm.cfg on USB2 and ensure it matches your case. For a 1MB I226‑V with EEPID 80000110, a typical config is:


CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.20.0

; NIC device
BEGIN DEVICE
DEVICENAME: Intel(R) Ethernet Controller I226-V
VENDOR: 8086
DEVICE: 125C
SUBVENDOR: 8086
SUBDEVICE: 0000
NVM IMAGE: FXVL_125C_V_1MB_2.32.bin
EEPID: 80000425
RESET TYPE: REBOOT
REPLACES: 80000110
END DEVICE
NVM IMAGE: must match the 1MB 2.32 bin filename.

REPLACES: set to your current EEPID (e.g. 80000110 for 2.14) instead of the example 2.17 EEPID from the thread.

4. Offline phase – Booting Ubuntu live on the firewall
When you can take the firewall offline:

Power off the N5105.

Connect monitor, keyboard, and USB1 (Ubuntu).

Enter BIOS/boot menu and boot from the Ubuntu USB.
�

In Ubuntu's boot menu select "Try Ubuntu" (do not install).

Once on the desktop, insert USB2 (firmware).

5. Ubuntu terminal commands (local console)
Open a Terminal window and:

bash
# 1) Go where Ubuntu mounts USB devices
cd /media/ubuntu
ls
Identify USB2 volume name (e.g. I226_FW), then:

bash
# 2) Enter data stick and firmware folder
cd I226_FW/i226-fw
ls
# You should see: nvmupdate64e, FXVL_125C_V_1MB_2.32.bin, nvm.cfg
5.1. Verify NICs and current firmware
bash
sudo ./nvmupdate64e -i
Confirm it detects your I226‑V NICs and shows the current NVM version (e.g. 2.14).
�

5.2. NVM backup (mandatory)
bash
sudo ./nvmupdate64e -b -l nvm_backup.log
The tool will create backup(s) and the log file in the same directory (i226-fw on USB2). Do not delete them; copy them to a safe location later.
�

5.3. Per‑interface firmware update (example MACs)
Using the generic example MACs from above:

igc0 → 00AABBCCDD10

igc1 → 00AABBCCDD11

igc2 → 00AABBCCDD12

igc3 → 00AABBCCDD13

Run, one interface at a time:

bash
# Update igc2 (example)
sudo ./nvmupdate64e -b -l nvm_igc2.log -m 00AABBCCDD12 -f -u -c nvm.cfg

# Update igc3
sudo ./nvmupdate64e -b -l nvm_igc3.log -m 00AABBCCDD13 -f -u -c nvm.cfg

# Update igc0
sudo ./nvmupdate64e -b -l nvm_igc0.log -m 00AABBCCDD10 -f -u -c nvm.cfg

# Update igc1
sudo ./nvmupdate64e -b -l nvm_igc1.log -m 00AABBCCDD11 -f -u -c nvm.cfg
Replace the -m values with your own MACs (without colons). This is exactly the pattern recommended in the thread, adapted to 1MB 2.14 → 2.32.

If any update command fails, immediately run:

bash
echo $?
and look up the error code in the Intel Quick Usage Guide or in post #39 notes.
�

6. Reboot and validation in OPNsense
Quit Ubuntu, shut the firewall down cleanly, remove both USB sticks.

Boot normally into OPNsense from the internal drive.

On the OPNsense console:


dmesg | grep igc
You should now see something like:


igcX: EEPROM V2.32-0 eTrack 0x80000115
for all updated ports instead of V2.14-0 0x80000110.
�

Check logs for a while and ensure there are no more frequent link state changed to DOWN/UP bursts on the I226‑V interfaces after boot.
�

7. Practical tips from the thread
Do not flash "blindly": always adjust nvm.cfg to match your actual EEPID and PROM size (1MB vs 2MB). Users with 2MB PROM need the FXVL_125C_V_2MB_2.32.bin + EEPID 80000422 config instead.
�

If you must flash an in‑use NIC over SSH, consider the "sleep + reboot" script approach shown in post #59 to avoid hard power‑offs; with local console (monitor + keyboard) it's easier to perform a graceful reboot afterwards.
�

If you are on latest OPNsense / FreeBSD 14.3 with the newer igc driver, keeping Intel NICs on up‑to‑date NVM images (e.g. 2.32) is strongly recommended to avoid the known I226 issues.

Hi Franco,

totally fair, thanks for taking the time to explain your side.

It's actually helpful to hear explicitly that for some features it can be easier (and healthier for the project) to either rewrite them later or refuse them altogether, instead of dragging extra maintenance burden into the community edition. That perspective isn't always obvious from the outside.

From my side, I'll keep using and advocating the existing TOTP flow on CE and, if in the future I end up in a business context where WebAuthn/FIDO2 on OPNsense becomes a hard requirement, I'll look seriously at commercial support and the Business Edition as the right channel to push for it.

In any case, I appreciate the transparency and the balance you're trying to keep between community features and a sustainable commercial offering.

Cheers,
opnessense

I understand your point, and I really appreciate the work that goes into OPNsense and its integrations.

From my side, it wasn't meant as "I want everything for free", but more as a reality check.

I also agree that 100 USD per year is not a huge amount in absolute terms, but for some users it can still be a noticeable expense, especially in a purely home or hobby context.

I fully understand that business users are the ones who should drive and pay for most of the professional integrations, and that the community edition already gives us a lot at zero cost. For my use case I'll just keep working with what is available in CE, and if one day I really need a specific integration for a business environment, I'll look at the paid options.

Thanks again for the clarification and for maintaining the balance between community and business needs.

Thanks all for the feedback.

My box is an N5105 with 16 GB RAM and 4× i226‑V, and at the moment I don't have any real issues: CPU is around 7–10%, RAM ~37%, temps ~24 °C and I'm getting full line speed.

Initially I was looking at nightcomdev's tunables more as a reference to better understand what each sysctl does, not to blindly copy the whole list. Based on that, I decided to only test a very small, hardware‑oriented subset for the i226‑V NICs:

hw.pci.enable_aspm=0
dev.igc.0.eee_control=0
dev.igc.1.eee_control=0
dev.igc.2.eee_control=0
dev.igc.3.eee_control=0

dev.igc.0.fc=0
dev.igc.1.fc=0
dev.igc.2.fc=0
dev.igc.3.fc=0
net.inet.tcp.tso=0

The idea was just to harden NIC behaviour and avoid known i226 quirks (ASPM/EEE/flow control/TSO), without touching RFC compliance or radically changing the TCP/IP stack. However, as soon as I applied these tunables my LAN links started flapping (interfaces going up and down repeatedly) and I had to hard‑reset the firewall. After removing those tunables and rebooting, everything went back to normal and the system is stable again.

Given that my setup was already working fine and the extra tunables clearly caused instability on my specific hardware/switch combination, I've decided to stick with the standard OPNsense/FreeBSD settings and not apply additional i226 tunables or firmware updates unless I run into a clear, reproducible problem that actually requires them.

So for now I'll leave any further tuning aside and stick with "if it isn't broken, don't fix it". Thanks again for the cautions and explanations.

You're right, I agree with you "bimbar" – WebAuthn/FIDO2 is a good alternative and not something tied to YubiKeys only

I'd also really like to see it supported in OPNsense alongside or as an alternative to the current TOTP‑based 2FA, and hopefully OIDC can eventually reach the community edition too.

Thanks for the help — it's all working now.

I ended up keeping Local Database and TOTP enabled at the same time instead of disabling Local, used the auth tester (remembering it always switches back to Local after each test), and set up a proper emergency plan with backed‑up TOTP seeds, SSH access, and console access so I don't risk locking myself out again.

Hi,

I'm trying to enable TOTP 2FA for the admin user on the GUI using a YubiKey (Yubico Authenticator on Windows), but the Local + TOTP tester almost always fails with "Authentication failed." Once it worked, but every attempt after that has failed.

Environment

OPNsense version: 26.1.4

Authentication servers (GUI): Local Database and Local + TOTP

TOTP server:

Type: Local + Timebased One Time Password

Token length: 6

Time window: 2 (also tried empty)

Reverse token order: unchecked (also tested checked)

User / token

User: admin

OTP seed generated in GUI (System → Access → Users → admin → OTP seed, "Generate new secret" + Save)

Enrolled via QR code into YubiKey Authenticator on Windows

TOTP code: 6 digits

Time

Timezone: Europe/Rome

NTP enabled with pool servers

date on the firewall matches PC time (≤ 1–2 seconds drift)

Problem

admin can log in with username + password (via Local Database).

In System → Access → Tester:

Server: Local + TOTP

User: admin

Password: adminPassword + 6‑digit TOTP (also tried TOTP+password with reverse order)

Result: almost always "Authentication failed."

It did work once (tester accepted the credentials and showed a success), but all attempts before and after that were "Authentication failed."

What I already tried

Regenerated the admin OTP seed multiple times and saved.

Deleted and re‑added the account in YubiKey Authenticator using the new QR code each time.

Rebooted the firewall.

Restarted the webgui service under System → Diagnostics → Services.

Checked System Logs: I only see some lighttpd errors like php-fastcgi.socket-X: Connection refused, but nothing clearly related to TOTP or authentication failures.

Question

Are there any known issues with Local + TOTP + YubiKey on 26.1.4, or extra logs/debug options I can enable to see why the TOTP is rejected? The fact that the tester worked once and then never again makes me think of some state/bug rather than a simple time or password format issue.

Thanks.