pfSense

I found this one in 2.0.x, but not yet in 2.1. However it looks like someone else had it happen identically:
http://forum.pfsense.org/index.php/topic,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:

<destination>
    <network>wan</network>
    <not/>
</destination>

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.