Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    One Firewall Rule Being Troublesome

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    19 Posts 5 Posters 3.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N Offline
      NOYB
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • BBcan177B Offline
        BBcan177 Moderator
        last edited by

        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?

        "Experience is something you don't get until just after you need it."

        Website: http://pfBlockerNG.com
        Twitter: @BBcan177  #pfBlockerNG
        Reddit: https://www.reddit.com/r/pfBlockerNG/new/

        1 Reply Last reply Reply Quote 0
        • N Offline
          NOYB
          last edited by

          @BBcan177:

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

          Nope.

          1 Reply Last reply Reply Quote 0
          • P Offline
            phil.davis
            last edited by

            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.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • N Offline
              NOYB
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • N Offline
                NOYB
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • N Offline
                  NOYB
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • N Offline
                    NOYB
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • C Offline
                      cmb
                      last edited by

                      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?

                      1 Reply Last reply Reply Quote 0
                      • N Offline
                        NOYB
                        last edited by

                        @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.

                        1 Reply Last reply Reply Quote 0
                        • N Offline
                          NOYB
                          last edited by

                          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.

                          1 Reply Last reply Reply Quote 0
                          • C Offline
                            coxhaus
                            last edited by

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

                            1 Reply Last reply Reply Quote 0
                            • N Offline
                              NOYB
                              last edited by

                              @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.

                              1 Reply Last reply Reply Quote 0
                              • C Offline
                                coxhaus
                                last edited by

                                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.

                                1 Reply Last reply Reply Quote 0
                                • N Offline
                                  NOYB
                                  last edited by

                                  "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.

                                  1 Reply Last reply Reply Quote 0
                                  • BBcan177B Offline
                                    BBcan177 Moderator
                                    last edited by

                                    @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

                                    "Experience is something you don't get until just after you need it."

                                    Website: http://pfBlockerNG.com
                                    Twitter: @BBcan177  #pfBlockerNG
                                    Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                                    1 Reply Last reply Reply Quote 0
                                    • C Offline
                                      coxhaus
                                      last edited by

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

                                      1 Reply Last reply Reply Quote 0
                                      • N Offline
                                        NOYB
                                        last edited by

                                        @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.

                                        1 Reply Last reply Reply Quote 0
                                        • P Offline
                                          phil.davis
                                          last edited by

                                          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.

                                          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                                          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                                          1 Reply Last reply Reply Quote 0
                                          • First post
                                            Last post
                                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.