OPNsense Forum
Archive => 22.7 Legacy Series => Topic started by: bigops on January 19, 2023, 06:21:17 am
-
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
-
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
-
Yes reboot will flush all states.
Also pf keeps track all states and will clear a state when the timeout is reached since a matching packet has came through.
Timeout is rarely occurred on a busy or persistent connection hence I usually perform manual state reset after making changes to its firewall rules since existing states will keep using whatever rule created them.
You can view pf timeout settings with 'pfctl -s timeouts'