pfSense

Is this fix part of current development snapshot ?

It is still in a "new" state, so no, it has not yet been addressed.

@jim This is very annoying bug and makes troubleshooting more difficult. Any chance to address it in the next point release?

Jim Pingle wrote:

There does seem to be an issue here, looks like it's in the pfSense module function pfSense_kill_states(). Sometimes it works, most of the time it doesn't.

Also if you enter an address or subnet in the filter box using a CIDR mask, such as 198.51.100.6/32, when you click the Kill button the / in the input field is replaced by an odd character of some kind (�, hex 0xFFFD, UTF-8 Hex EF BF BD). If I comment out the calls to pfSense_kill_states() that character remains correct.

I've collected $_POST value before and after pfSense_kill_states() is called and it really modifies it. Still investigating why such thing could happen.

Array
(
    [__csrf_magic] => sid:cdd036935bce2fdb1b1e5f7a290dabe4c18afb8a,1606411806
    [interface] => all
    [xfilter] => 172.21.4.175/32
    [killfilter] => Kill States
)
Array
(
    [__csrf_magic] => sid:cdd036935bce2fdb1b1e5f7a290dabe4c18afb8a,1606411806
    [interface] => all
    [xfilter] => 172.21.4.17532
    [killfilter] => Kill States
)

Just complementing the experiments I did today:

adding utf8_encode() to pfSense_kill_states() parameter fix the issue that affects $_POST. Now I'm concerned what else can be wrong on other calls to pfSense_* functions

looks great in 2.5.0 thanks a million !

Not sure if this should be added as a new issue

Assume you have an external IP XXX
And an OpenVPN net 192.168.200.0/0

After OpenVPN client connects it gets an IP 192.168.200.2

Now let's use States to see and kill all states for 192.168.200.2

There are lots of states look like this:

WAN    tcp    XXX:49313 (192.168.200.2:62472) -> <some_IP>:443    TIME_WAIT:TIME_WAIT    84 / 108    6 KiB / 129 KiB

And they don't get killed.

Expected - all states associated with 192.168.200.2 killed, or there is an option to select all and allow kill.

@Jim Pingle @Renato Botelho - what do you think ?

That's a different problem since it's a NAT address and not the final source or destination. Unrelated to this. I'm not sure if pfctl supports killing states by that address.

Check for an existing issue, if there isn't one, open a new one for that.