Messages

There is some detail in :

    System: Log Files: General

Last week I started building an OPNsense firewall which will be replacing one of the Drayteks currently using IPSEC. Doing so via a build network connected to my hub firewall.

As part of the build I configured a WireGuard tunnel to my hub firewall. When activated my monitoring system started reporting that I could see the remote site.

Looking in the hubs VPN: IPsec: Status Overview I could see bytes out being reported and, when tested, I had full access to the remote network.

On Monday I used my lab firewall to do the build for the next Draytek to be replaced. This time I configured three WireGuard VPN's to cover each of the remaining  Draytek's.

Again I now had access to the remaining sites.

This morning I disabled the spoke end of the WireGuard tunnels for all four of the Drayteks.

I still have access to the remote sites, which infers that this could be used as a temporary workaround.

Just to note that after updating to 26.7.2_2 I am still seeing the same behavior.

Tunnels showing as up.

Outbound traffic:
Traffic going out in the Live log
IPSEC Status Overview reporting no bytes out

Inbound traffic:
IPSEC Status Overview reporting bytes coming in.

I only see the 'Last updated' column update when there has been a change to the data being downloaded.

I use fractional values for hours which are working fine for numerous aliases.

I did experiment with various values but currently the smallest I use is 0.1

That was also my experience.

Do your changes persist after a reboot?

In the current Rules display scheduled rules no longer indicate their status while previously they were coloured green/orange for active/inactive.

Was this intentional?

No, not at this time.

I also found that the 'fix' mentioned earlier did not persist after a reboot.

As per the release notes:

firewall: legacy rules pages move to plugin

Look for:

os-firewall-legacy

I've seen this behavior as well:

https://forum.opnsense.org/index.php?topic=52494.msg271271#msg271271

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.