Project

General

Profile

Actions
Copy link

Bug #3083

closed

Firewall rule toggle fails after several enable/disable cycles : 2.1 RC0 and 2.0.3 release

Added by Mark Tiramani over 11 years ago. Updated about 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Web Interface
Target version:
2.1
Start date:
07/09/2013
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:
i386

Description

Please see the description in my forum post for more details:
http://forum.pfsense.org/index.php/topic,64098.0.html

Synopsis:
A block rule fails completely if toggled between enabled and disabled using the icon to the left of the rule.
The error condition can occur after just 1 cycle, but may take 6 full cycles of enabled/disabled/reset-states:

  • add new ICMP block rule (enabled) LAN->WAN, host->host
  • save and apply
  • start an ICMP echo request (constant ping to remote host on WAN if)
  • disable rule
  • wait for replies to commence
  • enable rule
  • reset states
  • return to firewall rules LAN page
    (possible multiple repeat required here...)

At this point the ICMP echo replies continue, despite the block rule showing as enabled. The firewall is essentially exhibiting the opposite of the expected, and indicated, behaviour.

This issue became apparent by chance during initial evaluation of pfSense 2.0.3 RELEASE (i386) 2 weeks ago (as a possible addition to our data-centre hosting setup).
Several configurations of hardware, routing and rulesets were tried, but for thorough repeated testing I reverted to a completely "factory default" setup behind an ADSL broadband router with DHCP on WAN/em1, and just 1 user-added firewall rule on the LAN interface.

I emphasise that this has nothing to do with resetting states. The only remedial action available via the web GUI is to either add another rule or re-save the existing rule. I have also tried waiting up to 30 minutes after entering the error state and then accessing various web GUI pages, then resetting states, then stopping the ping, waiting 30min etc.; the error condition remains.

Actions via the console shell that trigger an OS file stat (e.g. an "ls" on the /tmp/rules.debug file) result in the block rule being reinstated to the live ruleset, and after a state reset the block rule becomes effective again (a volatile buffer being committed?).

On a system that is installed to HDD a reboot also flushes the block rule such that it is correctly reinstated.

I have only tested on 2.0.3 and the July 4th snapshot of 2.1 RC0. However, testing within a carefully controlled set of conditions (as described) has been as rigorous and exhaustive as I could make time for. I am satisfied that the effect I am seeing is not due to hardware or user error.

Actions
Copy link

Also available in: Atom PDF