Messages

Confirmed working after updating ZenArmor.
Thanks Vesalius

+1, I am getting plenty of Phalcon errors, and am also not abled to get to ZenArmor interfaces due to Phalcon errors. I am assuming that the Phalcon upgrade will need to be factored in by the ZenArmor devs.

Also I lost my network connectivity/internet/DNS about 5 minutes after a reboot, after the upgrade; it's worth noting that I am testing 22.7b (new) kernel and base. I assumed that it may be related to ZenArmor; after removing ZenArmor, all is fine after a reboot (regained stable connectivity).

I didn't have any issues with 22.1.8_1 but upgraded regardless:
22.1.9 + 22.7b(new) kernel+base
All is good so far after 2 days, and the update was uneventful.

Simplistic setup:
- VLANs on WAN + MAC spoofing with dhcp
- VLANs on LAN + DHCP server
- plugins: IGMP-proxy, uPNP, Sensei
- 4xi225 NICs
- Suricata on WAN
- Zenarmor on LAN

22.1.8_1 + 22.7b kernel+base
All is good so far after a day, and the update was uneventful.

Simplistic setup:
- VLANs on WAN + MAC spoofing with dhcp
- VLANs on LAN + DHCP server
- plugins: IGMP-proxy, uPNP, Sensei
- 4xi225 NICs
- Suricata on WAN
- Zenarmor on LAN

After looking at other topics, I ended up testing compiling the IGD driver and then tried OpnSense 22.7pre3 (disabling the compiled driver). Both options solved my problem, but having to recompile the IGD driver each time the kernel is updated is rather inconveniencing. With 22.7pre3, all has been working fine for the past hour:
https://forum.opnsense.org/index.php?topic=27299.msg137706#msg137706

I'll drop off of this topic as there are too many variables, and other topics that may be more focused than this one.

@bugvito you will need to re-compile the IGB driver again for 22.7 (and for every kernel update).  What brand hardware are you using?

I'm aware. I was wondering if I could find a way to execute a command on a new kernel install event to recompile the driver. With that said, the driver still loaded and worked fine under 22.7pre3 without recompiling, but is a lucky/risky thing to do/try. This would still be an unviable solution, as this may cause problems down the road.

I did disable my compiled igd driver (confirmed not loaded with kldstat) and updated to 22.7.pre3, and to my pleasant surprise, everything is working fine for me (after 1h).
The test box is a cheap HSUNG RS34g with 4xi225 (I believe that the board itself is popular: 1090np-12).

Unfortunately this does not help identifying the real issue at hand for this topic, and as some already reported, 22.7 did not resolve their issue, while the original issue may not be intel nic specific.

Good find Vesalius,

I had time to test a bit last night, and the steps posted to compile the IGB drivers did solve my WAN problems. I have another issue so my testing only lasted about 30-60 minutes, but without any WAN issues.

I will remove the tunable setting specifying the compiled IGB driver, and potentially test 22.7 if all goes well.

None of this helps identifying/resolve the real cause, unfortunately.

Thanks!

Is moving to 13.1 a possibility for 22.7? Assuming that this issue would be resolved?

I have this issue on a X710 and on another system with I225... and no issues on a test VM (unraid/KVM virtio NIC) and also no issue on some old crappy realtek onboard NIC.

Same here; my VM with VirtIO is fine for WAN with VLANs and MAC spoofing (2 USB dongles on proxmox, AQC111U), my bare metal with I225 has issues with this WAN+vlan+spoof setup.

In my case it's really only an issue on Intel NIC's... switched my WAN to the onboard Realtek NIC and all is working now (mac spoofing with IDP on in IPS mode, OPNsense 22.1.6)

Is there any kernel or driver fix underway?

What would be your intel NIC model? I'm having WAN issues (spoofing MACs on WAN vlans) when upgrading from 22.1.2 to 22.1.5-6 with the dreaded i225, but I'm not clear at this point the actual issue.

I reinstalled OPNsense bare-metal, (22.1.2); rather than import a config, I simplified the setup from scratch with only WAN(vlan 34/35) and a MGMT port.  The WAN got an IP on vlan 35 and 34 as it should. I updated OPNsense to be able to install the IGMP proxy plugin, but after the upgrade to 22.1.6 without any other changes, I was no longer able to get a WAN IP on vlan 35 nor 34.

At this point I think that I'm mixing too many variables. The NICs may be fine (verified revision 3 and firmware > 1.45), the drivers (igc) could be the culprit if they changed between 22.1.2 and 22.1.6, or maybe something else is at play. My proxmox setup with some QNAP 5Gbps dongles (virtio to OPNsense) works fine with 22.1.6 and is solid so far, with the same vlan setup.

At this point I'll have to shelf this little box until i225 support is more mature, and/or when I have time to look deeper into it.

I have been looking forward to setup a new low power box with intel interfaces rather than my current proxmox setup. My VM works fine, but I wanted to do away with the USB dongles, potentially have the ability to offload some functions, the two layers of updates, etc...

I have a small box with 4xi225-v, and while the ports worked out of the gate with a fresh install (bare metal), originally 22.1.5, now updated to 22.1.6, I am struggling with traffic on vlan interfaces.
My WAN consists of 2 vlans, while my LAN port has 4. DHCP fails on the WAN interfaces, while DHCP works for the clients on the LAN.
Traffic however does not go through on any vlan interfaces. Assigning physical ports, however, DHCP and traffic works fine.

This seems to be the same issue that is now solved for linux:
https://forum.proxmox.com/threads/unable-to-pass-vlan-to-trunk.90862/
https://forum.proxmox.com/threads/is-anyone-using-i225-v-nic-in-their-pve-setup.76708/

Is this being looked into by any chance, or does anybody know of potential workarounds? I'd rather avoid proxmox, but at this time, it appears to be the simplest workaround, defeating what I was trying to achieve.

Any help is welcomed!

I updated to 2.7.7 with suricata 6.0.4, and the network drop issue reappeared right away.  Restarted the OpnSense VM, same issue.

I then disabled suricata, and no issues at all.  I then re-enabled IPS (suricata), and no issues, aside from wifi calling and Teams not letting me talk, but I could hear just fine. Looking into it, a rule "Conficker-C P2P encrypted traffic UDP Ping Packet" was blocking outbound UDP traffic on port 4500; setting this to "Alert" only resolved this issue.  This last issue is not directly related to this post, but seems to support the suggestion that something changed in the behavior of suricata, as I had not added any rules and had updated to the latest rulesets in all cases.  This rule had been configured the same way in all cases, and only started to cause issues after moving to suricata 6.0.4.

I'm not a fan of the "solution", as disabling and re-enabling a service does not resolve the actual problem, akin to a duct tape solution, but I am not in a position to look under the hood and see if a caching issue, configuration change between version, etc... could be the cause.

All seems good now on my end.

I'm glad the that issue is resolved for you! :)

For the "version" discussion; whether it's a configuration that no longer jives with an updated package, or a package that is "broken", old definitions causing issues with Suricata, or any other case, coming only after an update and can be repeated, this is a versioning issue.  This does not mean that a package is broken per se, but a set of condition lead to an issue with some package version.

With verasense no longer experiencing the problem, I'll take a deeper look time permitting.

Unfortunately after a day or so on 21.7.7 (keeping suricata from 21.7.5) I started having issues with anything voice related (Microsoft Teams for example), but no network cutout like before.  Restarted everything, same issue right away. Unfortunately I don't have the cycles to look into this.  Reverted to 21.7.5, and all seems fine again, but could also simply be coincidence.  Sorry for not having time to spend on this and gather useful details.