Messages

Just did the migration of the rules and nat rules. It was a matter of exporting & importing them using the migration assistant, then a review audit of the rules - along with testing connectivity to be as expected. Indeed all worked correctly. I had tried this a few months ago, and it was bad experience that I just reverted to the backup, and in an earlier forum chat, I concluded that I'd leave this till December / January. But now that it's done, things will hopefully be smoother moving forward with the upgrades, and any changes.

- no wireguard group
- set(check) Disable routes

Can you elaborate on the "no wireguard group"?

It was created for me when I created the initial road-warrior WG connection, but it is only present in the FW Rules section, and I've kept it blank. All of the rules are at the individual WG interface - firewall rules. I currently have about 8 WG connections working with "set (check) disable routes)". Traffic is per interface routed, and rules per interface, nothing is configured for the WG Group that only appears at the firewall rules section.

thanks

There is no rush to migrate. Totally fine to not migrate in 2026. I did it on one site, and personally have a hard time getting warm with the new firewall rules. IMHO it is a downgrade and looks messy, even if you change filters all the time. But to be fair, I have not invested much time into it yet :)

Thanks for the feedback. I'll hold off till 2027 as more updates come out, it will help things flesh out better.

Both work, but with 26.7 the legacy rules management GUI will be available as a plugin only. You can still use it but it won't receive any more feature updates and will eventually be removed although that could be 2-3 years from now.

So long story short: use Rules [new].

Will the new rules be stable and work correctly in 26.7 to warrant migration of complex rule-sets that are currently working in what's to become legacy?

The 2-3 year timeline for the old-rule plugin, - is there to allow people to migrate gradually their configs? Or more time to sort out the quirks of the new rules before completely dumping the old-rule plugin?

(Just trying to gauge whether I should try again to migrate in July / August or later in the year. I had tried to migrate when the new rules were introduced with the helper tool, and things just collapsed for me that I had to resort to a previous backup.)

Since upgrading to 25.7.6, my wireguard connections seem to work fine for a while then, either

i) not pass any traffic yet appear connected with a handshake,

ii) wireguard status icon turning into a black question mark, and no traffic.

iii) Go down completely.

As I have a couple of WG connections in a Group gateway that has a final fallback to the WAN connection, the fallback to the WAN is messy. So, I ran a machine on a single WG connection by itself, and the same issue appears.

Release notes for 25.7.6 state the update introduced  wireguard: add debug option to instances. Nothing in particular stands out in the messaging. The dpinger on the other hand reports losses and gateway fallover works.

Then, there are times when the dpinger reports the connection is up, & WG status reports a handshake and some little traffic. But, when I try to do a traceroute, all the traffic stops at the gateway.

I've had to delete & recreate all WG connections at the service provider & on opnsense, and change the IP-address scheme. Then, they would work for 2 days and crash again.

My configuration and setup had been stable, without any changes for quite sometime, 6+ months....Any thoughts whether this could just be an opnsense bug? If so, how do we report it, and what diagnostic report, or testing do we submit.

This is still an issue in OPNsense 25.7.6, as it has not been resolved.

An OpenVPN tunnel as a gateway set by itself in the rules, works fine. Place that OpenVPN gateway in a group, and it is automatically skipped.

Alright will give it a go, and see how it fairs.

Seeking some guidance from anyone that had ventured down this path.

I'm currently running ISC dhcp4, with static mappings for clients, some with different DNS servers and some with different gateways.

How did you go about sorting these out if you've migrated across to the KEA server instance?

Looking at the guidelines by OPNsense,"Configure kea dhcp 4 manually, requires supplying your own /usr/local/etc/kea/kea-dhcp4.conf file (advanced users only)".

It'll require,
Downloading the .conf file, - running a script to convert my isc dhcp4 mappings across to the same format, then, uploading the conf file, replacing the one on the server, and then starting up the service.

All future changes are to be done by doing manual console - terminal edits to the .conf file.

What did you do?

Thanks,

The recent update that was rolled out a couple of days ago - solves the issue. All is working correctly now.

Done - just sent the requested feedback.
Thank you,

Just ran a health check audit, and similarly, had a similar error 2 in regards to sysctl.conf - size issue.

I'm now getting the following error after the recent update of Zenarmor.

Zenarmor -    v.1.17.1
Zenarmor Application DB: 1.17.24042216

I haven't changed anything with my configuration - and Zenarmor is strictly configured for the LAN interfaces across different VLANs.

Is anyone facing a similar problem? 

"Possible deployment misconfiguration: devices with public IP addresses detected"  To correct this, please see the following document: https://www.zenarmor.com/docs/opnsense/installing/web-ui-initial-configuration#3-deployment-mode--interface-selection