OPNsense Forum
Archive => 20.7 Legacy Series => Topic started by: bb-mitch on January 13, 2021, 08:59:54 pm
-
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?
-
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...
-
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
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:
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
-
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.
-
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
-
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
-
it feels like it's not that hard to add the ability to view and kill by state id
-
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
-
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
-
Ok, let's wait for a reply :)