Messages

Initially I was thinking the same.  But then I came across this in the documentation

The Sequence does not have to be unique, multiple rules can share the same number. Though what this means is that the filter is not populated as strictly in order as if all rules have a unique sequence.

So I don't think it is a reliable way to identify the processing order??

While troubleshooting I also felt that if we have a column which shows the rule number which lists the processing order it would be helpful especially when all the rules are now bunched together.

I am pretty sure you can Enable that Column within the new Firewall Rules and also Disable exisiting ones : Click around a bit! ;)

Not sure where you found that option.  The only columns that I found was ID and sort order and sequence.  Both are not really helpful.  Is there something that I am missing? 

A serial number of firewall rules would go a long way to quickly identify the position of the rule on the firewall table

As the 26.7 version has started to take the definitive steps to decommission the old firewall rules I finally decided to migrate most firewalls into the new rule-set.  The migration went ahead without much issues but after the migration found that some connections which had been working for years started failing.  Investigating further it appears that the migration assistant doe not really care of the processing order of the rules when migrating. 

To capture all blocks for further troubleshooting the approach adopted earlier was to have an explicit block at the end of each interface firewall rule.  During troubleshooting it was observed that the migration assistant had put some rules of the interface after a block all rule on the interface.  This resulted in the catch all block rule denying access.  So had to manually move rules around so that rules for each interface are grouped together rather than in mix.

While troubleshooting I also felt that if we have a column which shows the rule number which lists the processing order it would be helpful especially when all the rules are now bunched together.

With the new rules UI there's a separate column with a checkbox to enable/disable rules.  The icons are just visual indicators now, not interactive.

Don't forget to also hit "Apply."

Thanks

Looks like after the upgrade the one click change like enablement and disablement of the specific rule (green arrow) functionality is lost.  I tired it from multiple browsers and it doe not do anything.  Is this correct?

I have been trying to troubleshoot a rather strange issue with the firewall.  It seems that with the similar configuration some rules work but other do not
You cannot view this attachment.

The rules in Green highlighted seems to work fine but the one in orange does not

I performed a packet capture on the interface and it seems that there are packet RTX and connection finally times out.  ICMP and UDP packets are seen correctly.  I am also able access the internet with out any issue
You cannot view this attachment.

But the traffic is not logged against the firewall or does not seem to be present in any other interfaces since pcap on all of them turned out to be blank for 443 traffic

Any suggestions on how to resolve this

Thanks

BG

Hi
This has been an issue that was noticed from a couple of years ago. Whenever a firewall update happens which requires a reboot after the update, there seems to be some issues with State tables when Dual WAN is configured and there is PBR configuration which requires some traffic routed to a specific Circuit rather than the one with the highest priority or default. This results in stuff like VPNs to fail till the state table is reset manually.  Steps to reproduce the issue
 There should be multiple WANs configured
 Some traffic should be always routed to the secondary WAN via a PBR
 The secondary traffic should have something like a VOIP or VPN configured

Now when the firewall is upgraded and goes for a reboot, the VPN stops working. Doing a packet capture on the firewall it seems that after the reboot the traffic is placed on the wrong interface.  But when the firewall state tables are cleared manually after the firewall has rebooted everything works fine again

 

I recently started noticing that one of the WAN circuits in my dual WAN setup regularly goes down with a dpinger error.  I have started noticing this after upgrading to Opnsense 24.1 and enabling IPv6 on the interface that is failing.  Looking at the logs for Gateways I see these constantly

2024-04-13T13:26:48-05:00   Warning   dpinger   WAN_DHCP 142.254.155.185: sendto error: 22   
2024-04-13T13:26:47-05:00   Warning   dpinger   WAN_DHCP 142.254.155.185: sendto error: 22   
2024-04-13T13:26:46-05:00   Warning   dpinger   WAN_DHCP 142.254.155.185: sendto error: 22   
2024-04-13T13:26:45-05:00   Warning   dpinger   WAN_DHCP 142.254.155.185: sendto error: 22   
2024-04-13T13:26:44-05:00   Warning   dpinger   WAN_DHCP 142.254.155.185: sendto error: 22   
2024-04-13T13:26:43-05:00   Warning   dpinger   WAN_DHCP 142.254.155.185: sendto error: 22   
2024-04-13T13:26:42-05:00   Notice   dpinger   Reloaded gateway watcher configuration on SIGHUP   
2024-04-13T13:26:42-05:00   Notice   dpinger   Reloaded gateway watcher configuration on SIGHUP

This error comes immediately after gateway watcher is reloaded.  Not sure why SIGHUP is being generated when there is no change in the firewall or reboots.  This happens only on one of the gateways (primary)

Is there any way to search or filter on rules in Opnsens?  For example if I want to search for a rule which contains an IP address and destination port.  I have been trying to do this but has not be able to find any easy way

Thanks

This issue seems to be similar to something which I had raised earlier here https://forum.opnsense.org/index.php?topic=31961.msg154479#msg154479.  But there was no response or solution.  The workaround that I am working on is to reset the state table after the firewall has any reboots or upgrades and once the state table is reset the routing seems to work fine

Has this been observed by anyone?  The issue is becoming more frequent and I have to reset the table every couple of days for this to keep working.  Is this a bug introduced in OpnSense / FreeBSD?

I had posted this in the 22 forum earlier.  https://forum.opnsense.org/index.php?topic=31961.msg154477#msg154477

The issue with outbound NAT seems to still persist in the 23 version also.  The issue is that if there is a gateway group with dual WAN interfaces in it and for operational reason a specific outbound traffic is redirected to a gateway with a lower priority (other than the gateway group) sometimes the outbound traffic seems to land up on the wrong gateway.  Rebooting the appliance does not seem to solve the issue, but manually clearing the state table again puts the traffic onto the correct gateway. 

This used to work fine in all earlier versions so seems to be some kind of bug introduced recently.

Skip rules when gateway is down is checked to prevent gateway rewrite on failure.

For now the issue seems to have been resolved.  As part of troubleshooting I was looking into the state table and i could see that the state table had entries which shows that the traffic was blocked since it was on the wrong interface (but there was not logs in the firewall live logs) After resetting the state table it started working again

One question that I have further on this is :  Does the state table clear during a reboot or the state table has to be cleared manually?  Is there any scavenging mechanism so that wrong state tables does not remain

I was managing an OpnSense system which was running flawlessly over the past few years.  But in the last month I started noticing an issue which seems to have been introduced recently as the same configuration had been working find for more than 2 years.  In the setup there is a server in a DMZ interface which needs UDP port 36605 to be forwarded to it.  The server will also contact other servers in the internet on the same UDP port (36605).  This setup is behind a firewall with 2 WAN interfaces.
This particular traffic to port 36605 needs to go via the WAN2 interface (WAN1 is default).  There is rule in the interface which will direct traffic to WAN 2
The inbound NAT seems to work fine, but outbound traffic (even though there is no NAT on the WAN1 interface for the DMZ server network ) seems to end up in WAN1 instead of expected WAN2.  A rough illustration is attached.

Does someone have suggestions or is this a bug.

Thanks

Found it it is in the IPsec Advanced settiings