Messages

Thanks. I had already done that.

I'm wondering if this is caused by an extra space in the alias entry.

I have since tried removing and replacing the alias in question. Which now passes data.

But it is not obvious if it was the update to the alias or the process of editing that resolved this.

I'm seeing some more examples of this which are also inconsistent across firewalls.

After the upgrade to 26.7.1 some inbound traffic started to be blocked on one firewall.

The alias at the root of the problem is structured:

      +----- Alias_NW1 subnet
      |
Alias-+----- Alias_NW2 subnet
      |                     
      +----- Alias_NW3 + NW4 subnets

The cause was the alias covering NW3 & NW4. Removing either one of them resolved the problem.

The inconsistency is that I use the same rule, that stopped passing traffic, on numerous other firewalls.

Most notably there are two identical Protectli firewalls where the rule passes on one and not the other.

Just been looking at an issue where I had lost NFS access across a site-to-site Wireguard VPN.

I found that a permit rule that was using an alias that contained aliases ( Alias_NW1, Alias_NW2 ) was not allowing traffic to pass.

While a separate rules for Alias_NW1 and Alias_NW2 worked as they should.

This looks to be a change of behavior from prior to 26-7

Back to the services widget.

If the start, restart, stop objects were colour coded to follow the service status, e.g. green - when running, this would be consistent with other widgets. Then the cell back ground could follow the theme, except when a service is stopped when it would be set to red.

All use tunnel mode.

These tunnels are configured to be uni-directional (for monitoring purposes), but I do see a few bytes (<500) coming into the OPNsense FW as reported on the VPN: IPsec: Status Overview page. Nothing reported going out.

The Firewall: Log Files: Live View does show outbound traffic being passed.

I was eventually able to see a message in the Draytek syslog explorer that may be useful:

## IKEv2 DBG : Process Packet : Receive IKEv2_INFORMATIONAL but can't find state for iCookie = c46dbe5dad535841 rCookie = 9b374fd129951dbc from {IP_Address}

But I've not found much detail on it yet.

Post upgrade I'm seeing an issue with traffic between a firewall running 26.7 and four Draytek 286x routers.

The tunnels are showing as active at both ends, traffic is reported leaving the OPNsense firewall, but I'm not seeing it arrive at the Draytek end.

Anyone else seeing similar?

One of my firewalls has a Realtek RTL8125 on the motherboard and was using the os-realtek-re driver.

Upgrading to 26.7 failed after the os-realtek-re driver was updated, after which configd would not restart.

Removing the driver prior to the upgrade resolved the issue.

It helps.

For both browsers after opening and closing edit mode the widgets resize.

When using page reload, via <F5>, the larger widget size does still occasionally appear. Less so for Firefox.

On Firefox - Edit, add widget, save, reload. On Brave - Edit, remove widget, save, reload. Neither changed the behavior.

I have HDPI screens which are scaled. To rules this out I reverted both to 100%. Doing shows that the System Information widget is doing the same thing. Though it is resizing within a few seconds, or so.

The Disk widget eventually resized on both browsers after ~ 10 minutes.

Applied the patch and rebooted the lab firewall (26.7.r2_3)

This did not change the widget layout.

This may be a red herring as I've just see this behavior on my local live firewall running 26.1.11_6.

My initial suspicion was the browser, Firefox 152.0.5 on Linux, But I see a similar behavior in Brave.

The difference is that in Brave I can see the box drawn oversized before collapsing back to the expected size. I subsequently saw the same with Firefox but after a few minutes.

The disk widget on the RC's does not always display as expected.

If you want to save space how about placing the widget tile centered on top of the orange line, for all widgets ?

Just upgraded my lab firewall from 26.1.11_6  to 26.7.r1 without issue.

I'm also using the os-realtek-re driver.  Yes, I am aware of the Realtek adapters reputation, which is why it was only being used in a simple LAN configuration, which up until now has not given any noticeable problems.

That I saw the Intel I226-V do the same thing yesterday suggests there could be other factors here.

Though the difference with the Intel NIC was that it recovered shortly afterwards without manual intervention.