One Firewall Rule Being Troublesome



  • At boot up I get a php crash report and the following message.

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

    rules.debug line 304 is the only one with that tracker #:

    
    block  in log  quick  on $LAN inet proto { tcp udp }  from any to !192.168.2.1 port 53 tracker 1422327490  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

    Editing and save/reloading the rule does not result in the error.  Only happens at bootup.

    Is there a dependency on DNS here?  If so there are no DNS servers specified on System / General Setup page and though DNS Resolver is enabled it may not be up at the time the rules load.


  • Moderator

    Do you have the "Disable DNS Forwarder" checked in System / General Setup?

    On another note, they should probably change the word "Forwarder" to "Disable DNS localhost"…  Users might think that "Forwarder" is DNSMasq?



  • @BBcan177:

    Do you have the "Disable DNS Forwarder" checked in System / General Setup?

    Nope.



  • I can replicate that on a test system. I put in a pass rule for !WANaddress. There seemed to be no problem in real time, but after reboot:

    There were error(s) loading the rules: /tmp/rules.debug:149: syntax error - The line in question reads [149]: pass in quick on $WAN reply-to ( em0 10.0.2.2 ) inet proto { tcp udp } from any to ! port 53 tracker 1460503814 keep state label "USER_RULE: Test not destination" @ 2016-04-12 23:40:11
    

    The rule in /tmp/rules.debug looks good now, so at the next filter reload it gets it OK.



  • Thanks Phil.  Guess it's not just a me thing then.

    I just now rebooted and submitted the crash report too.

    If I enable RAM disk then I don't get this error but instead get errors about some of my URL tables.  Plus system takes forever to boot.  Does okay until starting cron.  At that point it hangs for a while (several minutes) and spins the fan 100%.  So its working pretty hard on something.

    Submitted crash reports for those too.



  • Even though there are these crash reports and notification messages, the rule does seem to be working.

    My dev vm has the same rules, and nearly identical config, and does not have a problem with this.



  • Replacing "LAN address" selection in the firewall rule with a selection of an alias of containing the lan ip address.  It works without any crash report or notifications.



  • Another reboot just now resulted in this:

    
    pf_busy
    •  PF was wedged/busy and has been reset. @ 2016-04-12 20:54:51 
    
    Filter Reload
    •  There were error(s) loading the rules: pfctl: DIOCXCOMMIT: Device busy - The line in question reads [0]: @ 2016-04-12 20:55:21 
    
    

    Submitted the crash report.



  • Can't seem to replicate the problem with the missing LAN IP. Probably some kind of race condition I'd guess. Does seem to be cosmetic since by the time the system finishes booting it'll have the IP there and have the ruleset reloaded.

    Phil, what'd you do to replicate? And on what kind of system? I'm testing on relatively fast hardware or VMs on fast systems, maybe something replicable on an ALIX or something?

    NOYB: All 6 of the crash reports from your IP today are just notices trying to send something and failing to resolve DNS.

    Warning:  dns_get_record(): DNS Query failed in /etc/inc/notices.inc
    
    

    what do you have configured for notifications?



  • @cmb:

    Can't seem to replicate the problem with the missing LAN IP. Probably some kind of race condition I'd guess. Does seem to be cosmetic since by the time the system finishes booting it'll have the IP there and have the ruleset reloaded.

    Phil, what'd you do to replicate? And on what kind of system? I'm testing on relatively fast hardware or VMs on fast systems, maybe something replicable on an ALIX or something?

    NOYB: All 6 of the crash reports from your IP today are just notices trying to send something and failing to resolve DNS.

    Warning:  dns_get_record(): DNS Query failed in /etc/inc/notices.inc
    
    

    what do you have configured for notifications?

    Okay sounds like then the crash reports were not related to the firewall rule issue.  The notifications settings would have been the same as they were on 2.2.6.  Never changed them and they were working.

    Due to those, and slow boot at certain points, most noticeably starting cron, I just decided to install fresh.
    Not getting the crash reports, nor slow boot, now.  But still get the notice about the firewall rule.

    As mentioned earlier these 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).

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



  • The crash reports apparently were due to Growl being enabled with a bogus "IP Address" (domain name) that couldn't be resolved.

    The !LAN address firewall rule notification still an issue.



  • I have the same firewall rule under 2.3 using any instead of LAN and it seems to work fine.



  • @coxhaus:

    I have the same firewall rule under 2.3 using any instead of LAN and it seems to work fine.

    It's not the same firewall rule if it is using any instead of !LAN address.  It's the !LAN address that has the problem.  As I think it was cmb mentioned it is likely a race issue that "LAN address" isn't quite available in time for the initial loading of the rules.  But then later it is.  Don't think "any" would suffer from such, and I know an alias doesn't.



  • So does !LAN relate to only IP addresses defined to pfsense? I am not sure.  I would think "any" would be a better choice since it would cover any foreign networks and block DNS for them as well.



  • "LAN address" is the IP address of the pfSense LAN interface.

    So the rule blocks all packets that have a destination port of 53 (DNS) combined with a destination address other than the pfSense LAN interface.  Thus the only allowed DNS is that which is provided by pfSense.  In this case DNS Resolver (unbound).

    Any would also block LAN based DNS requests to pfSense.  That is not desired.  Desire is for all DNS request to be blocked except those to pfSense.


  • Moderator

    @NOYB:

    "LAN address" is the IP address of the pfSense LAN interface.

    So the rule blocks all packets that have a destination port of 53 (DNS) combined with a destination address other than the pfSense LAN interface.  Thus the only allowed DNS is that which is provided by pfSense.  In this case DNS Resolver (unbound).

    Any would also block LAN based DNS requests to pfSense.  That is not desired.  Desire is for all DNS request to be blocked except those to pfSense.

    You could also redirect these other DNS requests back to pfSense. For IPv4 that is…

    https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense



  • I get it. It is inverse of LAN.  I tested on my pfsense.



  • @BBcan177:

    You could also redirect these other DNS requests back to pfSense. For IPv4 that is…

    https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense

    Prefer anything, apps, device, etc. attempting to use DNS not supplied by the local network, result in a fail.



  • Phil, what'd you do to replicate? And on what kind of system? I'm testing on relatively fast hardware or VMs on fast systems, maybe something replicable on an ALIX or something?

    It was in a VirtualBox VM on my Windows10 laptop. I just tried rebooting it twice again and can't get the error to happen again. But for some reason the VM is booting much faster than usual at the moment, so maybe it is a timing thing.