Project

General

Profile

Bug #9270

"Remove all states to and from the filtered address" does not remove all states

Added by Yuri Weinstein about 2 years ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Category:
Diagnostics
Target version:
Start date:
01/13/2019
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.x
Affected Architecture:
All
Release Notes:
Default

Description

Simple use case:
Filter all states for an IP of any device (used my iPhone IP) in "Diagnostics"/"States"/"States"
Click on `Kill States` button

At this point it is expected that all states would be killed, but in fact not all states were killed.

Associated revisions

Revision ef094bef (diff)
Added by Renato Botelho 4 months ago

Ticket #9270: Make sure parameters are UTF-8

As described on ticket, for some reason we still don't know, when
pfSense_kill_states() is called with subnet as parameter (n.n.n.n/n) it
makes changes on $_POST content that can lead system to unpredictable
results.

Add a workaround for the moment encoding variables when call this
function and also pfsense_kill_srcstates() while we don't figure out the
root cause of the problem.

History

#1 Updated by Jim Pingle about 2 years ago

  • Target version set to 48
  • Affected Version set to 2.4.x
  • Affected Architecture All added
  • Affected Architecture deleted ()

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.

#2 Updated by Jim Pingle about 2 years ago

  • Target version changed from 48 to 2.5.0

#3 Updated by Yuri Weinstein over 1 year ago

Is this fix part of current development snapshot ?

#4 Updated by Jim Pingle over 1 year ago

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

#5 Updated by Yuri Weinstein 9 months ago

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

#6 Updated by Steve Beaver 6 months ago

  • Assignee set to Jim Pingle

#7 Updated by Steve Beaver 6 months ago

  • Assignee changed from Jim Pingle to Luiz Souza

#8 Updated by Steve Beaver 5 months ago

  • Assignee changed from Luiz Souza to Renato Botelho

#9 Updated by Renato Botelho 5 months ago

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
)

#10 Updated by Renato Botelho 5 months ago

  • Status changed from New to In Progress

#11 Updated by Renato Botelho 5 months ago

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

#12 Updated by Renato Botelho 4 months ago

  • Status changed from In Progress to Feedback

Can you please give next round of snapshots a try and see if the workaround I committed help?

#13 Updated by Jim Pingle 4 months ago

  • Status changed from Feedback to Resolved

Looks OK now. I no longer get the unexpected character in the field, and the states are killed as expected.

Thanks!

#14 Updated by Yuri Weinstein about 2 months ago

looks great in 2.5.0 thanks a million !

#15 Updated by Yuri Weinstein about 1 month ago

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 ?

#16 Updated by Jim Pingle about 1 month ago

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.

Also available in: Atom PDF