Messages

I'll pass this on, thanks!


Cheers,
Franco

One more note: to narrow it down further after playing with it, it appears to happen when there's an interface specific rule. Another rule set I setup that doesn't use interface seems to appear normally. Maybe just a javascript repeat/cascading issue or something.

Thanks all for the feedback! There's also this one now.

https://github.com/opnsense/core/commit/87345016d4fe9aee1

And we're probably shipping all later this week in 25.7.7.


Cheers,
Franco

Thanks for 25.7.7 today! Really appreciate the teams' work on all of this. Really great.

Just wanted to note I still see an issue on the live firewall log with the rules text that is presented (not in design/color, that's fixed) but in what is displayed. For instance, I have a rule for "interface is WAN" but then subsequent rules that are related to src or port will say "src does not contain WAN" or "dstport does not contain WAN" or "protoname does not contain 'WAN'" when that's not what the rule is at all. To be clear, the rules work, but after saving them, they then appear as this when selecting a saved template.

Here's a picture:

New issue: Live log applied filter "bubble" is blank under both browsers. Filters still work, and filters may be deleted by poking where the "X" would normally be. Friggin' browsers! Heh.

Mine were "blank" when using dark mode (white text on white background), but using default theme, it shows this text in the bubbles (as an example):

Anecdotally after the most recent update, WireGuard seems to be having issues after a reboot of OPNsense now. WG clients aren't able to connect, I restart the WG service, and they're able to connect again. Easy to mitigate, but it's very manual intervention, and not sure why it started happening. Just thought I'd mention it.

I've tracked down what is happening on my simple setup (address only, no prefix) and created a PR for discussion:-

https://github.com/opnsense/dhcp6c/pull/36

Wondering if my situation over the past couple of weeks could be related, this was working before:

1. WAN pulls IPv6 fine via DHCPv6 client.
2. LAN has a static IPv6 address. Clients pull an IPv6 address via routing advertisement (managed mode) and DHCPv6 server (so I can control the address they receive). This stopped working though I noticed one day on my phone when I saw it didn't pull an IPv6 address.
3. So I dropped back versions of dhcpv6c and opnsense proper ( 24.1.8 ) as stated in the thread. This only allowed me to serve out clients via unmanaged routing advertisements and not via the DHCPv6 server I have running.

So with that background, the question is does anyone think this issue would affect the ability to use the DHCPv6 server to serve out static-mapped addresses with routing advertisements set to managed (not working) instead of unmanaged (working) as it is now?

Thanks for the quick reply! That was definitely it.

Upgraded to 24.1_1, cannot ping out to the internet now. Not sure what changed.

Pinging from OPNsense command line:

PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: No route to host

Has anyone else seen this?

I have stopped suricata, zenarmor, crowdsec, and nothing seems to help.

Upgraded yesterday and I must say: superb job! I've been up almost 24 hours and it's smooth sailing so far.

Yeah I updated mid-typing.

Update: whatever was fixed regarding IPv6, DHCPv6 and delegated prefixes in the 23.1.8 update seems to have resolved my IPv6 dropping issues. I rebooted afterward and at the very least, so far, have not had to touch it. It just works.  ;D

Understood.

Question on ZenArmor config: Do I need to use the Emulated driver for this or can I use Native?

Ohhh. Geez man, I'm slow. Hmm, well I'm wondering then why I'm still getting these drop issues when I switch ZenArmor out of monitoring-only mode. :\ Oh well, thanks for the help.

We are looking for internal approval between participating parties on the last published state for 23.1.6. Overall it looks like we are better off with the patches than without and we likely won't get broader feedback otherwise. If not I expect 23.1.7 to have it in a few weeks.

Based on this comment, I was thinking the patches for netmap issues were going to be a part of the 23.1.7 release. Guess that's not the case.

Hi @dfw3xam1n3r
Did you test Zenarmor with Routed (L3 Mode, Reporting and Blocking available) with emulated netmap driver on OPNsense 23.1.6 and have any issues? Some users reported that their problems are resolved with this configuration.

Yeah I did and the same thing happened, so I'm just in monitoring mode until 23.1.7 comes out.

We have the exact same issue running 23.1 with an Watchguard M370 appliance.

Lan port appears up but the connectivity is lost and it is not visible from the lat network even with arp -a.

The problem happens infrequently every 7-14 days and is very difficult to track down. VPN and WAN interface work and the firewall management is acccessible when this happens (Through VPN). Zenarmor is activated, but it is not really doing much besides reporting: Routed Mode (L3 Mode, Reporting + Blocking) with native netmap driver.

Will try with the emulated driver if that will fix the issue. The logs have nothing noteworthy from the time of the issue happening.

Just installed the latest 23.1.6 patches but not feeling optimistic since this has happened multiple times already.

Any ideas on tracking down the issue?

This issue will be fixed in 23.1.7 coming out in a couple of weeks, re: netmap/ZenArmor issue. Here is a thread on it. https://forum.opnsense.org/index.php?topic=32114.75. In the thread there were patches you can apply in the interim. I just have my ZenArmor set to monitoring only for now.