Project

General

Profile

Actions
Copy link

Bug #12588

closed

Automatic rule tracker IDs incorrect after multiple filter reloads

Added by Steve Wheeler about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Jim Pingle
Category:
Rules / NAT
Target version:
2.6.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.01
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:
All

Description

In some circumstances the generated ruleset is created with unexpected tracker ID values at boot.

The values seen vary by install but are consistent across a reboot. For example:

#---------------------------------------------------------------------------
# default deny rules
#---------------------------------------------------------------------------
block in log inet all ridentifier 1000104531 label "Default deny rule IPv4" 
block out log inet all ridentifier 1000104532 label "Default deny rule IPv4" 
block in log inet6 all ridentifier 1000104533 label "Default deny rule IPv6" 
block out log inet6 all ridentifier 1000104534 label "Default deny rule IPv6"

After a filter reload the ruleset uses expected values:

#---------------------------------------------------------------------------
# default deny rules
#---------------------------------------------------------------------------
block in log inet all ridentifier 1000000101 label "Default deny rule IPv4" 
block out log inet all ridentifier 1000000102 label "Default deny rule IPv4" 
block in log inet6 all ridentifier 1000000103 label "Default deny rule IPv6" 
block out log inet6 all ridentifier 1000000104 label "Default deny rule IPv6"

This can result in firewall log entries mislabelled or labelled unexpectedly.

Tested:

2.6.0-DEVELOPMENT (amd64)
built on Mon Dec 13 20:27:39 UTC 2021
FreeBSD 12.3-STABLE

I have replicated this in 22.01 and 2.5.2/21.05.2 as well as older versions.

Actions
Copy link
 #1

Updated by Jim Pingle about 3 years ago

This can happen if filter_configure_sync() runs twice and filter.inc is only loaded once. The tracker variables are only initialized when filter.inc is first included so if the function runs twice it keeps counting up from where it stopped.

Something like this should fix it (and does on my local testing):

diff --git a/src/etc/inc/filter.inc b/src/etc/inc/filter.inc
index fd4274f99d..d4d456bdf5 100644
--- a/src/etc/inc/filter.inc
+++ b/src/etc/inc/filter.inc
@@ -117,6 +117,8 @@ if ($config['ipsec']['filtermode'] == 'if_ipsec') {
  *
  */

+define("TRACKER_DEFAULT", 1000000000);
+define("NEGATE_TRACKER_DEFAULT", 10000000);
 define("ANTILOCKOUT_TRACKER_START", 10000);
 define("ANTILOCKOUT_TRACKER_END", 10999);
 define("BOGONS_TRACKER_START", 11000);
@@ -126,8 +128,8 @@ define("RFC1918_TRACKER_END", 12999);
 define("PFLABEL_MAXLEN", 63);
 define("USER_LABEL_INTRO", "USER_RULE: ");

-$tracker = 1000000000;
-$negate_tracker = 10000000;
+$tracker = TRACKER_DEFAULT;
+$negate_tracker = NEGATE_TRACKER_DEFAULT;
 $antilockout_tracker = ANTILOCKOUT_TRACKER_START;
 $bogons_tracker = BOGONS_TRACKER_START;
 $rfc1918_tracker = RFC1918_TRACKER_START;
@@ -262,6 +264,9 @@ function filter_delete_states_for_down_gateways() {
 function filter_configure_sync($delete_states_if_needed = true) {
        global $config, $g, $after_filter_configure_run, $FilterIflist;
        global $time_based_rules, $filterdns, $aliases, $dummynet_name_list;
+       global $tracker, $negate_tracker;
+       $tracker = TRACKER_DEFAULT;
+       $negate_tracker = NEGATE_TRACKER_DEFAULT;

        /* Use filter lock to not allow concurrent filter reloads during this run. */
        $filterlck = lock('filter', LOCK_EX);

Actions
Copy link
 #2

Updated by Jim Pingle about 3 years ago

The easiest way to replicate is to run:

filter_configure_sync();
filter_configure_sync();

For example by editing /etc/rc.filter_configure_sync to run it twice and then running that script.

Actions
Copy link
 #3

Updated by Jim Pingle about 3 years ago

  • Assignee set to Jim Pingle
Actions
Copy link
 #4

Updated by Jim Pingle about 3 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #5

Updated by Steve Wheeler about 3 years ago

Looks good. Systems that were coming up incorrectly numbered at boot every time are no longer doing so with that patch.

Tested:

2.6.0-DEVELOPMENT (amd64)
built on Tue Dec 14 06:19:09 UTC 2021
FreeBSD 12.3-STABLE

and
22.01-DEVELOPMENT (amd64)
built on Tue Dec 14 06:23:27 UTC 2021
FreeBSD 12.3-STABLE

Actions
Copy link
 #6

Updated by Jim Pingle about 3 years ago

  • Subject changed from Rule tracker ID incorrectly numbered at boot. to Automatic rule tracker IDs incorrect after multiple filter reloads

Updating subject for release notes.

Actions
Copy link
 #7

Updated by Danilo Zrenjanin almost 3 years ago

  • Status changed from Feedback to Resolved

Tested:

2.6.0-BETA (amd64)
built on Tue Jan 04 06:15:30 UTC 2022
FreeBSD 12.3-STABLE

It is fixed.

Ticket resolved.

Actions
Copy link

Also available in: Atom PDF