Firewall rules not applied without resetting state table

[marco-shagrat]

Hi,
  i was struggling with the configuration of a site 2 site openvpn PSK VPN on a testing environment.

The test configuration is this:

client1         -|                                                                |-client3
(192.168.101.20) |                                                                | (192.168.102.20)
                 |    opnsense1 (Server)                    opnsense2 (Client)    |
                 |--- LAN: 192.168.101.1 <----------------> LAN: 192.168.102.1 ---|
                 |    WAN: 192.168.17.45                    WAN: 192.168.17.46    |
client2         -|                                                                |-client4
(192.168.101.21) |             |------- TUNNEL NETWORK  -------|                  | (192.168.102.21)
                                       (10.10.10.0/24)


The firewall rule on WAN interface on opnsense1 was set to allow incoming connection on openvpn server port (1194).
The firewall rules on OpenVPN interface correctly set as shown in the attached image.
The openvpn tunnel goes up ad expected.

Now, the problem.

From client 4 there are 2 terminals pinging 192.168.101.20 and 192.168.101.21.

With the rules configured (see the attachment) I can ping both client1 and client2.

If I disable the second rule (allow packets to 192.168.101.21) I expect to see the first terminal continue pinging client1 and the second terminal stopping pinging client2, but both pings still work.

I go to Firewall->Diagnostics->States->Actions->reset state table

The ping to client2 stops and the ping to client1 still works (the expected behaviour).

If I re-enable the rule the ping to client2 starts responding instantly (as expected).

If I disable (again) the rule the ping to client2 continue responding (sigh) until i go to flush states table.

Is this the expected behaviour?

If needed i can attach both firewalls configuration files.

Thanks in advance for any reply to my question.

[tiermutter]

Yes, this is the expected behaviour, because the states are already set when it was allowed previosly. Thats why you need to flush the states when you are denying something: all states are killed and will be blocked now by your new ruleset.

Allowing something will not need a flush, because a new connection attempt will be allowed directly, there is no state that needs to be killed.

[tiermutter]

You can see it like this:

Opening a door causes everyone to go in immediately, even if the door was closed before.
Closing a door causes that no one can go in, but it will not kick out anyone already inside, but flushing states will kick out everyone.

[marco-shagrat]

Sorry for the (maybe) stupid question but why not flushing automatically states (if needed) if something changes in the rule set?

Maybe only my opinion but in a firewall, if I want to block someting (adding and applying a rule) why do I need to do something else to REALLY apply a rule?

 

[marco-shagrat]

You can see it like this:

Opening a door causes everyone to go in immediately, even if the door was closed before.
Closing a door causes that no one can go in, but it will not kick out anyone already inside, but flushing states will kick out everyone.

Clear but, not the exact example maybe.

If i'm pinging the "open door" and the door is closed meanwhile i expect that the next ping finds the "door" closed and so fails.

Maybe not closing or kicking off established connections (TCP or others) but new connection i expect will be blocked or denied.

Only my opinion...

[tiermutter]

Sure, but the STATE (not the ping itself) already exists, it was established when the door was open. The next n pings from host X are using the existing state, they do not need new ones.

[franco]

If you are asking for all states to be reset on a firewall rule reload imagine restarting your firewall in a company setting during working hours. That's exactly why you want connection states to be remembered...


Cheers,
Franco

[marco-shagrat]

If you are asking for all states to be reset on a firewall rule reload imagine restarting your firewall in a company setting during working hours. That's exactly why you want connection states to be remembered...


Cheers,
Franco

No doubt about this, but I ask you. If i have to flush the states table to make the applied rule really effective, what's the difference?

More over. If I'm adding a rule that blocks specific traffic why not to flush only states that should be affected by that rule?
I see that in the states table I can search and delete states line by line, why not doing this automatically? I think filter out states affected by the new rule shoud not be so difficult.

Or let the admin be abe to choose, something like "You added a block rule, shoud the states table be flushed?" when the rule is applied.

I don't want to be annoying, just thinking.

What do you do when you REALLY need to add such a rule in your environment? how do you plan the change?

thanks in advance

[Fright]

I see that in the states table I can search and delete states line by line, why not doing this automatically?

because its not that simple: in pf there is no way to just give a command to check all existing states against the updated rulesets. moreover, the state table simply does not contain all the attributes of the rules by which connections were once allowed. for example, what if the tag has changed in the rule?