OPNsense Forum

Archive => 20.7 Legacy Series => Topic started by: cfranklin on October 30, 2020, 07:18:02 PM

Title: Existing connections still working after Disabled/Deleting rules
Post by: cfranklin on October 30, 2020, 07:18:02 PM
I have 3 interfaces WAN,LAN1,LAN2 and a rule to allow ICMP packets from LAN1 to LAN2. After disabling and or deleting this rule. Existing connections are still allowed to continue. Unless I reboot the firewall, "States Reset" or wait for the existing connection to stop transmitting anything long enough for them to timeout.

Why doesn't disabling or deleting the rules automatically kill these connections ?   

Title: Re: Existing connections still working after Disabled/Deleting rules
Post by: mimugmail on October 30, 2020, 07:21:32 PM
Because it's stateful, it's the usual behavior for most vendors
Title: Re: Existing connections still working after Disabled/Deleting rules
Post by: cfranklin on October 31, 2020, 01:05:45 AM
Is there a way to disable to "feature" ?

Quote from: mimugmail on October 30, 2020, 07:21:32 PM
Because it's stateful, it's the usual behavior for most vendors

No vendor's firewall (meraki, cisco, sonic wall, sophos and barracuda just to name a few)  I've ever used has ever allowed existing connection(s) to continue after a rule was removed
when the default was to block. This kind of stateful makes sense for proxies (haproxy as an example) or a application like samba. It also doesn't make sense why adding a block rule also doesn't stop these existing connections.

What if I needed to deal with an "problem" connection and needed to alter a rule, that existing problem connection would be allowed to continue ?

Title: Re: Existing connections still working after Disabled/Deleting rules
Post by: cfranklin on October 31, 2020, 01:08:27 AM
I found the documentation about stateful have needing to do a reset.

https://docs.opnsense.org/manual/firewall.html
Title: Re: Existing connections still working after Disabled/Deleting rules
Post by: mimugmail on October 31, 2020, 08:26:20 AM
iptables works this way, and as most vendors use it I'd say it's expected behavior