Project

General

Profile

Actions

Bug #10359

closed

Require State Filter setting breaks filter rule link to associated states

Added by Jens Groh about 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Category:
Diagnostics
Target version:
Start date:
03/19/2020
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.4-p3
Affected Architecture:
All

Description

If one configures

System > General Setup
- Require State Filter -> yes (enabled checkbox)

that's a great way to stop browsers (like firefox) to crash or load infinitely while opening "Diagnostics > State" on a busy firewall.
We had to set this as on our busy datacenter cluster there were so many state that most browsers were going down while trying to load the state table page unfiltered.

But: with the above option set, the cross-linking of states belonging to filter rules is no longer working:

  • enable "Require State Filter"
  • save
  • go to "Firewall > Rules"
  • click on the States in front of a busy firewall rule that you want to check
  • you are redirected to diag_dump_states.php but the page thinks that your call is "unfiltered" therefore not showing anything

This behavior can be found up until the latest 2.4.5 RCs.

Is it possible to "rewrite" the call from the filter rules page, that it shows the states for that rule but leave the general "require state filter" in place so nobody accidentally crashes its browser entering diag_dump_states.php without filtering? Perhaps filling out the corresponding fields when jumping to the page? I know, no game-breaking bug, but a little annoying one as it robs us of a valid diagnostic/debugging tool and linking to states in firewall rules becomes obsolete.

Thanks,
Jens

Actions #1

Updated by Viktor Gurov about 4 years ago

Firewall rules page uses $_REQUEST['ruleid'], but diag_dump_states.php checks only for $_POST['filter'] and requirestatefilter option.
This PR adds check for $_REQUEST['ruleid']:
https://github.com/pfsense/pfsense/pull/4241

Actions #2

Updated by Jim Pingle about 4 years ago

  • Status changed from New to Pull Request Review
Actions #3

Updated by Renato Botelho about 4 years ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Renato Botelho
  • Target version set to 2.5.0
  • % Done changed from 0 to 100

PR has been merged. Thanks!

Actions #4

Updated by Viktor Gurov about 4 years ago

works as expected on 2.5.0.a.20200321.2101

Actions #5

Updated by Viktor Gurov about 4 years ago

  • Status changed from Feedback to Resolved
Actions #6

Updated by Jens Groh about 4 years ago

Cherry-picked and manually installed "b9ab356250f68213fe36b6cba1758feee581ac83" via System Patches to 2.4.5-RC

Working as expected (tested with and without, reverted and applied again).
Currently running an upgrade to latest 2.4.5-RC and will try again.

Actions #7

Updated by Jens Groh about 4 years ago

Re-tested on latest 2.4.5-RC, still working as expected.

Actions #8

Updated by Jens Groh about 4 years ago

Just as a short question: I suppose after following the quick release of 2.4.5 that fix didn't go into 2.4.5, too? Just asking so I can have it rolled out via System Patches instead? Or are there plans for a 2.4.5-p1 somewhere? :)

Actions #9

Updated by Viktor Gurov about 4 years ago

Jens Groh wrote:

Just as a short question: I suppose after following the quick release of 2.4.5 that fix didn't go into 2.4.5, too?
Just asking so I can have it rolled out via System Patches instead?

Yes, for 2.4.5 you need to use System Patches for this fix.

Or are there plans for a 2.4.5-p1 somewhere? :)

Stay tuned for Netgate news.

Actions #10

Updated by Jim Pingle almost 4 years ago

  • Status changed from Resolved to Feedback
  • Target version changed from 2.5.0 to 2.4.5-p1
Actions #11

Updated by Jim Pingle almost 4 years ago

  • Status changed from Feedback to Resolved

Works as expected now. Filtered states are displayed when following the link from the rules list.

Actions

Also available in: Atom PDF