opnsense / pfctl bug?

[bb-mitch]

In the "olden days" clicking the X next to a state in opnsense / pfsense worked. the state was gone - of course if the internal host continues to send a traffic a new state will be created (on a different NAT port), which will fail to reach the end host. That's ok... but at least one could kill those states.

Looking for a solution I found a related issue on pfsense... https://forum.netgate.com/topic/107208/pfctl-k-id-not-working/7

Basically what it comes down to is that the states panel doesn't seem to kill states like it should. It USED to work.

Regularly we used to use this function to search out and kill states for a particular client to affect changes like a new NAT target etc. but it hasn't worked in the past long while - only large scale (like IP filter, click KILL button) have worked (which doesn't work in this case for us. we might want to drop a SIP registration without dropping a call - we only want to kill a single mapping or the mappings in a related group.

The pfsense thread seems to identify the issue - although he was using pfctl directly.

In short:
pfctl -s state -vv

produces a list of states like:
all udp 10.x.x.x:ppppp (66.x.x.x:PPPPP) <- 216.x.x.x:RRRRR       NO_TRAFFIC:SINGLE
   age 00:00:04, expires in 00:00:56, 1:0 pkts, 32:0 bytes, rule 104
   id: 010000005cb3317b creatorid: 9171c710

It's these last two numbers that are key. I believe the docs on pfctl make it look like you can kill a state like this:
pfctl -k id -k 010000005cb3317b

But in reality it requires both the id and the creator:
pfctl -k id -k 010000005cb3317b/9171c710

I think this is likely a bug in both pfsense and opnsense, but people who need it have just been working around it.

Does what I'm suggesting make sense?

[chemlud]

I used scheduled FW-rules in the past and long time ago (with pfsense... maybe 2015?) the kill job for states (per IP) stopped working correctly (these states with the strange notation persisting) and I had to kill ALL states, to make the schedule work correctly...

[bb-mitch]

Thanks @chemlud - in our case we can't rely on killing all states. Consider today... certain traffic from certain clients needs to be flushed to enable reconnection (switching to an alternate proxy on our side). Relying on killall for this means we'd have to work outside their hours / be unable to manage this. so pretty critical for us to fix. that said, I think the pfctl WORKS - the call from opnsense / pfsense to pfctl seems to be the issue.

Will continue to update my notes on both forums if I can, but I this man is relevant.
https://www.freebsd.org/cgi/man.cgi?query=pfctl&sektion=8

Code: [Select]

     To kill a state with ID 4823e84500000018 created from a backup
     firewall with hostid 00000002 use:

   # pfctl -k id -k 4823e84500000018/2

In the case of opnsense the creator id always seems to be set, and changes as states are updated / replaced.

One other interesting option would be if we were able to kill states by label. To do that, we need to "label" the rule. Is that possible? then we could kill states in the form:

Code: [Select]

It is also possible to kill states by rule label or state ID.  In
     this mode the first -k argument is used to specify the type of
     the second argument.  The following command would kill all states
     that have been created from rules carrying the label "foobar":

   # pfctl -k label -k foobar

Any ideas / knowledge appreciated. Even if the bug can't be fixed, that would help us (and others) work around the issue. Thanks everyone!

Mitch

[bb-mitch]

Here's something I noticed...
Running pfctl -s labels shows there are stats.

pfctl -s labels
02f4bab031b57d1e30553ce08e0ec131 7366693 7044318 508222235 7044318 508222235 0 0 0
02f4bab031b57d1e30553ce08e0ec131 7366487 18 1264 18 1264 0 0 0
1d245529367b2e34eeaff16086aeafe9 144 0 0 0 0 0 0 0
1d245529367b2e34eeaff16086aeafe9 3 0 0 0 0 0 0 0


When I cat /tmp/rules.debug I see labels are automatically applied...
port {xxxxx} label "4d91ecae57340e4d7495b86fead00729" # : Allow TO 8A

Do these change with each edit? Regardless it will still be possible to do:
pfctl -k label -k 4d91ecae57340e4d7495b86fead00729

That's pretty cool.

[Fright]

not a bug - just one of the states killing options
a little confused.
how do you want to kill: by rule lable? by state id?
now it kills by src\dst IPs

[franco]

Hi Mitch,

I'm a little confused since there was no page or version mention and I vaguely remembered something:

https://github.com/opnsense/core/commit/5a95ccfef3e

This did indeed fix the states kill bug in diag_dump_states.php and went into 19.1 unnoticed. The forum link attached is interesting in particular:

https://forum.opnsense.org/index.php?topic=10150.0

A thread opened by yourself but lacking feedback on the patch above.

So with regard to the patch and 19.1 and diag_dump_states.php is that working or are we talking about something different?

There could be breakage now that we are on FreeBSD 12, but then I again we haven't heard about it (yet).

Would appreciate a clarification.


Thanks,
Franco

[Fright]

it feels like it's not that hard to add the ability to view and kill by state id

[franco]

True, likely at the risk of replacing something that others already consider convenience to be able to kill multiple states between peers (if they even care that is).


Cheers,
Franco

[Fright]

so this does not replace the "remove all related states"  between pairs button but adds new one )
but maybe I didn't fully understand the topic starter

[franco]

Ok, let's wait for a reply