RESOLVED - Syntax error in pfctl config file: macro 'LAN' not defined



  • If you see an alert during a filter reload like this:

    There were error(s) loading the rules: /tmp/rules.debug:159: macro 'LAN' not defined/tmp/rules.debug:159: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [159]: pass in quick on $LAN from 10.168.25.0/24 to 10.168.25.0/24 keep state label "USER_RULE: 20080708, heinzenm"…

    This error occurs if a user defined rule is added to the LAN or WAN interfaces. By default there is only a $lan and a $wan macro. All user defined rules use a uppercase macro name. Therefor the rules use $LAN and $WAN. This causes the filter reload to fail and not load any rules.

    Change the following lines in /etc/inc/filter.inc

    
        335         if($config['interfaces']['lan']) {
        336                 $aliases .= "lan = \"{ {$config['interfaces']['lan']['if']}{$lan_aliases} }\"\n";
        337                 $aliases .= "LAN = \"{ {$config['interfaces']['lan']['if']}{$lan_aliases} }\"\n";
        338         }
    
        366         } else {
        367                 $aliases .= "wan = \"{ " . $wanif . "{$wan_aliases}  }\"\n";       
        368                 $aliases .= "WAN = \"{ " . $wanif . "{$wan_aliases}  }\"\n";
        369         }
    

    That fixed my problem. Maybe not the best solution, but it works for me now.



  • another caps sensitivity issue it looks like, I sent this link to Ermal who made those related changes, hopefully he'll know right away what's causing it.



  • Grab a snapshot after 1 hour or 2 and retry should be fixed.



  • Hi,
    i'm having a similar problem for an opt interface on Rel 1.2 full inst:

    There were error(s) loading the rules: /tmp/rules.debug:129: syntax error/tmp/rules.debug:130: syntax error /tmp/rules.debug:131: syntax error /tmp/rules.debug:224: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [129]: pass in quick on $PubWlan proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server"…

    I got around by changing the opt interface name to lowercase letters, but this should be fixed on 1.2.x as well.



  • @eskild:

    Hi,
    i'm having a similar problem for an opt interface on Rel 1.2 full inst:

    There were error(s) loading the rules: /tmp/rules.debug:129: syntax error/tmp/rules.debug:130: syntax error /tmp/rules.debug:131: syntax error /tmp/rules.debug:224: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [129]: pass in quick on $PubWlan proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server"…

    I got around by changing the opt interface name to lowercase letters, but this should be fixed on 1.2.x as well.

    Mixed case on 1.2 has never been a problem, this thread is entirely related to changes in 1.3. I have 1.2 installs using mixed case interface names and know many others do as well. I'm guessing you probably have an alias with the same name, which isn't valid and input validation has been added to 1.2.1 to prevent that.



  • @cmb:

    @eskild:

    Hi,
    i'm having a similar problem for an opt interface on Rel 1.2 full inst:

    There were error(s) loading the rules: /tmp/rules.debug:129: syntax error/tmp/rules.debug:130: syntax error /tmp/rules.debug:131: syntax error /tmp/rules.debug:224: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [129]: pass in quick on $PubWlan proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server"…

    I got around by changing the opt interface name to lowercase letters, but this should be fixed on 1.2.x as well.

    Mixed case on 1.2 has never been a problem, this thread is entirely related to changes in 1.3. I have 1.2 installs using mixed case interface names and know many others do as well. I'm guessing you probably have an alias with the same name, which isn't valid and input validation has been added to 1.2.1 to prevent that.

    Yes, you are absolutely right. I had an alias with the same name as the interface. After I changed the alias, and then the interface name, I no longer see the previous problems.

    Thanks for all your help, it is highly appreciated.


Log in to reply