Bug #2883


pf rules contain erroneous "!/" artifact leading to "syntax error" in log

Added by Stilez y over 8 years ago. Updated over 8 years ago.

Rules / NAT
Target version:
Start date:
Due date:
% Done:


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


I found this one in 2.0.x, but not yet in 2.1. However it looks like someone else had it happen identically:,59847.0.html (ignore the thread title)

So I'm reporting it as live/new in 2.1 since I can't track down an existing bug on it. Summary is from that thread:

The symptom is that - possibly at random, or after a rules change with no obvious error - rules reloading consistently begins to fail, with an error like this:

There were error(s) loading the rules: /tmp/rules.debug:188: syntax error - The line in question reads [188]: block return in log quick on $IPsec inet from any to !/ label "xyz"

Notice the "(from|to) !/" artifact. It led to puzzlement in the forum thread.

I hit this !/ artifact last year in 2.0.1. It results from a bug possibly related to PPPoE (and some other WAN networks?) having the WAN subnet ending up undefined under some or all conditions, which caused this problem when pfsense tried to create the pf rules string.

As a result, Pfsense was trying to produce a clause in the rule in some cases, something like "from any to !{{$NETWORK_IP}}/{{$NETWORK_CIDR_BITS}} ....." only the two variable terms are evaluating to null or empty strings giving a rule with the "to !/" artifact in it.

And indeed there's a rule in the OP's rules config dump that is trying to include conditions such as "<not> <WAN subnet>" or similar, and the OP also has PPPoE according to the thread:


Separate, I looked last year into why it "randomly" seemed to start. For me it was because of a second issue. It seemed there was a bug of some kind in advanced or usual PPP config (similar to the MTU non-saving issue?), that some data may in some circumstances not be saved in the PPP config, when PPP settings are edited, and instead when PPP settings are saved, they got some incorrectly blanked data instead.

Presumably wan subnet should evaluate to something when used in a rule condition, and if the UK ISP tells the user it's a /29 rather than the entire internet for PPPoE then that's a pragmatic sensible value to allow the user to enter, if not a technically precise one, since the router or its rules just need to know what to regard as its own WAN IP range in rules.

I didn't find exact code fixes but those were unquestionably the 2 issues behind the odd syntax bug. Although PPPoE doesn't have a "wan subnet", in the UK PPPoA/PPPoE connections do almost universally have a subnet provided by the ISP (or else dialup protocols aren't correctly operated by almost any UK ISP?). Either way (and even if technically wrong for PPP), the quickest solution for me was to mod the code to allow explicit entry of a WAN subnet for all kinds of WAN, including PPP, even if technically incorrect. That fixed it completely.

Actions #1

Updated by Chris Buechler over 8 years ago

  • Category set to Rules / NAT
  • Target version set to 2.1
  • Affected Version set to All

most parts of rule generation ensure a legit IP and subnet, need to fix that for this circumstance. Where these return as blank, the rule needs to be skipped and an error logged.

There is probably some other root cause but without being able to replicate and having specific info on that, the above is the proper fix for the known problem.

Actions #2

Updated by Ermal Luçi over 8 years ago

  • Status changed from New to Feedback

I already have pushed a fix for this.
Test with newer snapshots.

Actions #3

Updated by Vladimir Putin over 8 years ago

I have tested this fix already with no luck
Provided more information here,59847.msg322816.html#msg322816

Actions #4

Updated by Renato Botelho over 8 years ago

  • Status changed from Feedback to New
Actions #5

Updated by Vladimir Putin over 8 years ago

It is fixed. At least for me. No more errors on boot. It could be gitsync issue that is not working now and was activated in Updater settings. Thanks for help.

Actions #6

Updated by Renato Botelho over 8 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF