Messages

In the meantime ;-) are you able to modify the grok expression to cater for both formats?

Trying to figure out how to do that very thing...

If you add a ticket on GitHub that's something to consider for improvement. I agree that it shouldn't differ but we need to isolate the code bits responsible first to make a meaningful plan forward.

https://github.com/opnsense/core/issues/10059

BLUF: Built in rules have no dashes ("-") in the Rule ID (e.g., 02f4bab031b57d1e30553ce08e0ec131) and Security Onion (Elastic) seems to parse these events fine. User created rules do have dashes (e.g., 0be7d07b-1e80-47ff-8ff8-8e553095d4e5) and Security Onion (Elastic) seems unable to parse any of these rules.

Have been trying to configure my church's OPNsense to send filter logs to our instance of Security Onion. Church was previously using pfsense and filter logs were working. Elastic uses the same integration for both OPNsense and pfsense, so initially ruled out an issue with the configuration on Security Onion. That said, I was seeing the following error: "Provided Grok expressions do not match field value". Conjured up my best SearchFu but couldn't find anything definitive. The Elastic integration for OPNsense/pfsense seems well maintained so it seemed odd that it couldn't handle OPNsense's input.

So, i pointed my home instance of OPNsense to the Church's Security Onion (networks are connected via Wireguard, and are running exact same hardware and versions of OPNsense) and it seemed like the logs from home worked fine. However, eventually, I did find some from home that weren't being parsed (same error) and some from church that were parsed fine.

I copied the original messages of both good and bad events to compare and could find only one difference; the presence of dashes in the Rule ID. All events with dashes in the Rule ID failed to parse and all events with no dashes parse fine. As far as I can tell, all built-in rules are dash free and all user created rules use dashes. Turns out, for my home instance, I don't have explicit deny rules on each interfaces (using the built in one) whereas the church does have explicit deny rules per interface. This is why, I think, most events from my home instance worked and most from the church did not.

So, anyone else using Security Onion seeing the same thing? I am also curious why the difference in formats for Rule IDs.

Jumping on the bandwagon here instead of a new post since it seems related. Appreciate the wealth of information in this thread. Hoping for a sanity check...

...snip...

Following up.

Put in a support ticket with Protectli (my device is a VP2440) and they confirmed it has the 2MB variant of the i226V and recommended I try flashing under Ubuntu. Booted my device into a live USB Ubuntu environment and flashed both NICs. This time nvmupdate64e reported success. No discernible difference otherwise in the flash process or in the state of the NICs post flashing.

So, while the flash process reported an error under OPNsense, I wonder if the error was... erroneous. Regardless, both NICs show 2.32 2MB ROM has been applied with a successful output from the flash tool. So, time to monitor my link stability and move on to other troubleshooting if necessary.

Appreciate the help.

@Waldhaar_
You only flashed one 226?

That is correct; flashed the one I am using for WAN. As a side note, I am using one of the IPs on a vlan interface for ssh (those vlans are connected via the dual X710 interfaces to my switch), so I should be able update the LAN without any interruption to the ssh session.

Here's some tidbit from Intel docs for flash tool, maybe try using the debug env variables and then grab an inventory

Looked through the guide and couldn't seem to get any additional information than has already been shared. I did fail trying to set the environment variables for additional debug; I guess I am out of my depth with regards to setting those on FreeBSD/OPNsense. I'll keep at it.

I don't always trust the etid's as being 100% accurate in relating 1MB vs 2MB nvram. I does look like the OROM didn't finish.
What does the log file say?

My last code block is what I assumed was the log (dumped to file when attempting the update).

You can also use the flash util to get all the info of the 226.

Using the flash util to get an inventory, here's the output relevant to the two i226 NICs:

Code Select Expand

# ./nvmupdate64e -i -l inventory.log
<snip>
[00:002:00:00]: Intel(R) Ethernet Controller I226-V
        Alternate MAC address is not set.
        Flash inventory started.
        Shadow RAM inventory started.
        Shadow RAM inventory finished.
        Flash inventory finished.
        OROM inventory started.
        OROM inventory finished.
[00:004:00:00]: Intel(R) Ethernet Controller I226-V
        Alternate MAC address is not set.
        Flash inventory started.
        Shadow RAM inventory started.
        Shadow RAM inventory finished.
        Flash inventory finished.
        OROM inventory started.
        OROM inventory finished.
[00:002:00:00]: Intel(R) Ethernet Controller I226-V
        Vendor                 : 8086
        Device                 : 125C
        Subvendor              : 8086
        Subdevice              : 0000
        Revision               : 4
        LAN MAC                : 6462662501E5
        Alt MAC                : 000000000000
        SAN MAC                : 000000000000
        ETrackId               : 80000422
        SerialNumber           : 646266FFFF2501E5
        NVM Version            : 2.50(2.32)
        PBA                    : G23456-000
        VPD status             : Not set
        VPD size               : 0
        NVM update             : No config file entry
          checksum             : Valid
        OROM update            : No config file entry
          CIVD                 : 0.0.0
          EFI                  : 0.1.4, checksum None
[00:004:00:00]: Intel(R) Ethernet Controller I226-V
        Vendor                 : 8086
        Device                 : 125C
        Subvendor              : 8086
        Subdevice              : 0000
        Revision               : 4
        LAN MAC                : 6462662501E6
        Alt MAC                : 000000000000
        SAN MAC                : 000000000000
        ETrackId               : 80000303
        SerialNumber           : 646266FFFF2501E6
        NVM Version            : 2.23(2.17)
        PBA                    : G23456-000
        VPD status             : Not set
        VPD size               : 0
        NVM update             : No config file entry
          checksum             : Valid
        OROM update            : No config file entry
          CIVD                 : 0.0.0
          EFI                  : 0.1.4, checksum None
I'm still new to all this, but the flash utility is reporting the updated version for the igc0 NIC.

Jumping on the bandwagon here instead of a new post since it seems related. Appreciate the wealth of information in this thread. Hoping for a sanity check...

New to OPNsense and experienced what it seems many others were with the i226 NICs on my device (which has two). Read through this thread several times, the read me for the NVM update tool, etc.. and moved forward with trying to flash the firmware. Long story short... I can't figure out if the flash was successful or not. Sounds crazy I know.

Here's is the latest output from dmesg (igc0 is WAN, igc1 is LAN).

Code Select Expand

# dmesg | grep igc | grep EEPROM
[1] igc0: EEPROM V2.17-0 eTrack 0x80000303
[1] igc1: EEPROM V2.17-0 eTrack 0x80000303
[1] igc0: EEPROM V2.17-0 eTrack 0x80000303
[1] igc1: EEPROM V2.17-0 eTrack 0x80000303
[1] igc0: EEPROM V2.17-0 eTrack 0x80000303
[1] igc1: EEPROM V2.17-0 eTrack 0x80000303
[1] igc0: EEPROM V2.32-0 eTrack 0x80000422
[1] igc1: EEPROM V2.17-0 eTrack 0x80000303
[1] igc0: EEPROM V2.32-0 eTrack 0x80000422
[1] igc1: EEPROM V2.17-0 eTrack 0x80000303
For good measure, here's the output of pciconf:

Code Select Expand

# pciconf -lV | grep igc
igc0@pci0:2:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc1@pci0:4:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
From my reading, the eTrack ID ending in 303 indicated I had the 2MB variant. As such, I used the following nvm.cfg:

Code Select Expand

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_2MB_2.32.bin
EEPID: 80000422
RESET TYPE: REBOOT
REPLACES: 80000303
END DEVICE
However, the output from nvmupdate64e was:

Code Select Expand

Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.43.20.0
Copyright(C) 2013 - 2025 Intel Corporation.

./nvmupdate64e -b -l nvm.log -m 6462662501e5 -f -u -c nvm.cfg

Config file read.
Inventory
[00:002:00:00]: Intel(R) Ethernet Controller I226-V
        Alternate MAC address is not set.
        Flash inventory started.
        Shadow RAM inventory started.
        Shadow RAM inventory finished.
        Flash inventory finished.
        OROM inventory started.
        OROM inventory finished.
Update
[00:002:00:00]: Intel(R) Ethernet Controller I226-V
        Creating backup images in directory: 6462662501E5.
        Backup images created.
        Flash update started.
        NVM verification started.
        Shadow RAM verification started.
        Shadow RAM verification finished.
        Flash verification started.
Difference found in module Invalid at offset 0x202E - update required.
        Flash verification finished.
        NVM update is required.
        NVM verification finished.
Error:          Flash update failed.
        Device update failed.
Update security revisions
[00:002:00:00]: Intel(R) Ethernet Controller I226-V
        Skipping update minimum security revisions.
Update VPD with VPD template
[00:002:00:00]: Intel(R) Ethernet Controller I226-V
        Skipping VPD update with VPD template.
So... it failed? But dmesg shows (after a reboot and the subsequent reboot) the new version v2.32 and eTrack ID 0x80000422, so it... succeeded? My WAN interface is working. I'm in a monitoring mode to see if previous issues persist.

Figured it best to pause and get a sanity check before moving forward with the other NIC.

Am I missing something obvious?