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

    DMZ interface DNS rule seems to be failing at random??

    Scheduled Pinned Locked Moved Firewalling
    7 Posts 3 Posters 2.0k 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.
    • T Offline
      TheCeltic
      last edited by

      I have 3 interfaces.. LAN/WAN/DMZ (actually, I have a 4th management interface as well).

      I have created rules to allow DNS to/from the LAN and the DMZ. For some reason, The DMZ system occasionally stops being able to access the internet (can't browse to www.google.com for example). When I check the log files, it shows traffic to PORT 53 being blocked… I verify the rule still exists to permit port 53 traffic and it does.

      What is really weird is that if I use "quick rule" to create another rule allowing the system to access DNS, the system is then able to connect for a while, but eventually starts dropping again. Any ideas what may be causing this? The LAN rule works perfect. The interface for the DMZ is a separate nic from the onboard one used for the LAN. I don't think the problem is with the nic.

      Any assistance is appreciated!

      1 Reply Last reply Reply Quote 0
      • B Offline
        biggsy
        last edited by

        You shouldn't need a rule to allow DNS from your LAN.

        Did you allow both TCP and UDP 53 through the DMZ interface?

        1 Reply Last reply Reply Quote 0
        • T Offline
          TheCeltic
          last edited by

          Not TCP and UDP, just UDP… is that the problem?

          1 Reply Last reply Reply Quote 0
          • B Offline
            biggsy
            last edited by

            It's one possibility.

            From what I've seen in various places, DNS can fall back to TCP/53 under some circumstances.  Can't hurt to try it.

            1 Reply Last reply Reply Quote 0
            • T Offline
              TheCeltic
              last edited by

              Another oddity.. It seems that if I use the IP (and not an alias) for the rule, the DNS rule doesn't stop working. I have to wait a bit to confirm.

              1 Reply Last reply Reply Quote 0
              • johnpozJ Online
                johnpoz LAYER 8 Global Moderator
                last edited by

                Any rule for DNS needs to allow both udp and tcp, since dns will move to tcp if over 512 bytes

                http://tools.ietf.org/html/rfc5966

                it should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) may result in resolution failure and/or application-level timeouts.

                In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below), the normal behaviour of any DNS server needing to send a UDP response that would exceed the 512-byte limit is for the server to truncate the response so that it fits within that limit and then set the TC flag in the response header.  When the client receives such a response, it takes the TC flag as an indication that it should retry over TCP instead.

                So how exactly is pfsense resolve this alias for your dns?  I would have to assume if the pfsense box fails to resolve the alias, then that rule would fail.  Why can you not just use the IP for your name server?  Name servers IP don't normally tend to change all that often ;)

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 25.07.1 | Lab VMs 2.8, 25.07.1

                1 Reply Last reply Reply Quote 0
                • T Offline
                  TheCeltic
                  last edited by

                  Excellent! Thanks.

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