Project

General

Profile

Actions

Bug #6133

closed

Firewall Rull Using !LAN address Error

Added by NOYB NOYB about 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
Rules / NAT
Target version:
-
Start date:
04/13/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.3
Affected Architecture:

Description

Firewall rule using !LAN address in destination results in the following error.

@Notices

Filter Reload
• There were error(s) loading the rules: /tmp/rules.debug:297: syntax error - The line in question reads [297]: block in log quick on $LAN inet proto { tcp udp } from any to ! port 53 tracker 1452958855 label "USER_RULE: Block Unapproved DNS Servers"@

The rule settings are:
Block: enabled
Log: enabled
Protocol: IPv4 TCP/UDP
Source: *
Port: *
Destination: !LAN address
Port: 53(DNS)
Queue: none
Schedule:
Description: Block Unapproved DNS Servers

Same rules work fine on VirtualBox VM; Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz 2 CPUs: 1 package(s) x 2 core(s).

But not on Dell Inspiron 5100; Intel(R) Pentium(R) 4 CPU 2.66GHz. Full install on USB flash drive.

Forum thread:
https://forum.pfsense.org/index.php?topic=109719.0

Actions #1

Updated by Jim Thompson about 8 years ago

  • Assignee set to Chris Buechler
Actions #2

Updated by Chris Buechler about 8 years ago

  • Category set to Rules / NAT
  • Status changed from New to Confirmed
Actions #3

Updated by Chris Buechler almost 8 years ago

  • Target version changed from 2.3.1 to 2.3.2

no replicable test case for this. it fixes itself by the time the system finishes booting so not a huge deal, but ugly.

Actions #4

Updated by NOYB NOYB almost 8 years ago

Have not seen this so far on 2.3.1. It's not been long and only a few reboots, but previously it was every boot. So good possibility it is fixed. That's good. Would be nice though to know the cause so it can be avoided in future.

Far as I am concerned, unless I see this again, it is fixed.

Actions #5

Updated by Chris Buechler almost 8 years ago

  • Status changed from Confirmed to Feedback

I'm guessing this may have been fixed by the more proper validation that config.cache is sane.

Actions #6

Updated by Chris Buechler almost 8 years ago

  • Status changed from Feedback to Resolved
  • Target version deleted (2.3.2)

this definitely looks to have been fixed in 2.3.1 with the validation of config.cache

Actions

Also available in: Atom PDF