Project

General

Profile

Bug #6028

no firewall rules loaded after reboot with invalid ruleset

Added by Pi Ba almost 5 years ago. Updated 22 days ago.

Status:
Resolved
Priority:
High
Category:
Rules / NAT
Target version:
Start date:
03/25/2016
Due date:
% Done:

0%

Estimated time:
Affected Version:
All
Affected Architecture:

Description

not a single firewall rule loaded after reboot..

There should be some failsafe default ruleset that prohibits access from at least all 'wan interfaces' until a proper ruleset can be loaded.

Granted this is caused by another issue https://redmine.pfsense.org/issues/6024 where a invalid rule gets written to the debug.rules..
There have been other cases that made rules.debug fail to load like having shapers with wrong bandwith or url-aliases that point to a somehow invalid formatted file.. So i think it would be better to provide a minimal 'bootup ruleset' that blocks all wan access instead of being 'wide open' until at least some proper rules could be applied.

Associated revisions

Revision 70f5cde9 (diff)
Added by Renato Botelho 3 months ago

Ticket #6028: Persist last valid set of rules

Save the last version of a valid set of rules under /cf/conf to make it
to persist on reboot. This allow it to be loaded when, for some reason,
current ruleset is invalid.

Revision 5341fe71 (diff)
Added by Renato Botelho 3 months ago

Ticket #6028: Fix path to rules.debug.old

History

#1 Updated by NOYB NOYB almost 5 years ago

Pet peeve of mine that the system seems to be wide open by default until firewall rules get applied. Think I brought it up or mentioned it once long ago in the forums.

So even if the firewall rules load properly the system still seems to be open between the time the interface is brought up and when the firewall rules get applied.

And as you have noticed if the rules fail to get applied the system remains open.

#2 Updated by Chris Buechler almost 5 years ago

  • Subject changed from not a single firewall rule loaded after reboot.. (du to a invalid ruleset.) to no firewall rules loaded after reboot with invalid ruleset
  • Status changed from New to Confirmed
  • Assignee set to Chris Buechler
  • Target version set to 2.3.1
  • Affected Version changed from 2.3 to All

Ought to keep a "last known good" rules.debug and apply that if it fails, and if that fails/is unavailable, maybe just the anti-lockout rule on LAN. I'll look at it post-2.3.

#3 Updated by Chris Buechler almost 5 years ago

  • Target version changed from 2.3.1 to 2.3.2

#4 Updated by Chris Buechler over 4 years ago

  • Assignee deleted (Chris Buechler)
  • Target version changed from 2.3.2 to 2.4.0

#5 Updated by Jim Thompson about 4 years ago

  • Assignee set to Renato Botelho

#6 Updated by Grischa Zengel over 3 years ago

I wrote this 4 years ago in #3175

#7 Updated by Renato Botelho over 3 years ago

  • Target version changed from 2.4.0 to 2.4.1

#8 Updated by Pi Ba over 3 years ago

Another example making no rulesloaded (vtnet doesnt support altq): https://redmine.pfsense.org/issues/7594

#9 Updated by Jim Pingle over 3 years ago

  • Target version changed from 2.4.1 to 2.4.2

#10 Updated by Renato Botelho over 3 years ago

  • Target version changed from 2.4.2 to 2.4.3

#11 Updated by Jim Pingle almost 3 years ago

  • Target version changed from 2.4.3 to 2.4.4

#12 Updated by Jim Pingle over 2 years ago

  • Target version changed from 2.4.4 to 2.4.4-GS

#13 Updated by Jim Pingle over 2 years ago

  • Target version changed from 2.4.4-GS to 48

#14 Updated by Jim Pingle almost 2 years ago

  • Target version changed from 48 to 2.5.0

#15 Updated by Renato Botelho 4 months ago

  • Status changed from Confirmed to In Progress

#16 Updated by Renato Botelho 3 months ago

  • Status changed from In Progress to Feedback

#17 Updated by Chris Linstruth 25 days ago

Manually created an invalid configuration by modifying config.xml to make an HFSC queue that cannot load because the child bandwidth is higher than the parent queue.

Crash report begins.  Anonymous machine information:

amd64
12.2-STABLE
FreeBSD 12.2-STABLE b102db12494(devel-12) pfSense

Crash report details:

PHP Errors:
[05-Feb-2021 15:09:14 Etc/UTC] PHP Warning:  fopen(): Filename cannot be empty in /etc/inc/notices.inc on line 101
[05-Feb-2021 15:09:14 Etc/UTC] PHP Warning:  Cannot use a scalar value as an array in /etc/inc/config.lib.inc on line 1157
[05-Feb-2021 15:09:14 Etc/UTC] PHP Warning:  Cannot use a scalar value as an array in /etc/inc/config.lib.inc on line 1159
[05-Feb-2021 15:09:14 Etc/UTC] PHP Warning:  Cannot use a scalar value as an array in /etc/inc/config.lib.inc on line 1157
[05-Feb-2021 15:09:14 Etc/UTC] PHP Warning:  Cannot use a scalar value as an array in /etc/inc/config.lib.inc on line 1159
[05-Feb-2021 15:09:14 Etc/UTC] PHP Warning:  Invalid argument supplied for foreach() in /etc/inc/util.inc on line 1872

No FreeBSD crash data found.

#18 Updated by Renato Botelho 25 days ago

Chris Linstruth wrote:

Manually created an invalid configuration by modifying config.xml to make an HFSC queue that cannot load because the child bandwidth is higher than the parent queue.

[...]

This implementation will not cover PHP errors. When PHP crashes code is not executed and there is not much we can do.

#19 Updated by Renato Botelho 25 days ago

Chris Linstruth wrote:

Manually created an invalid configuration by modifying config.xml to make an HFSC queue that cannot load because the child bandwidth is higher than the parent queue.

[...]

Apply following patch to your system and reboot. It will make it to create an invalid set of rules without crash PHP

diff --git a/src/etc/inc/filter.inc b/src/etc/inc/filter.inc
index aeb79c9c11..f3fed92d1c 100644
--- a/src/etc/inc/filter.inc
+++ b/src/etc/inc/filter.inc
@@ -4010,6 +4010,7 @@ EOD;
                        }
                }

+               $ipfrules .= "\nINVALID LINE HERE\n";
                $ipfrules .= "\n# User-defined rules follow\n";
                $ipfrules .= "\nanchor \"userrules/*\"\n";
                /* Generate user rule lines */

#20 Updated by Viktor Gurov 22 days ago

  • Status changed from Feedback to Resolved

tested with patch on 2.5.0.a.20210204.2250
works as expected

Also available in: Atom PDF