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

    DMZ Subnet DNS stops resolving after 12 hours

    Scheduled Pinned Locked Moved DHCP and DNS
    6 Posts 3 Posters 2.5k 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.
    • S Offline
      sgebhard
      last edited by

      Hello everyone, I am fairly new to Pfsense (1 year) and am having problems with my DMZ subnet.  Setup is as follows:
      2 WAN connections (both from same ISP, same DNS servers) with load balancing and fail over

      1 LAN subnet with nothing forwarded to it (192.168.0.0)
      1 DMZ subnet with all the devices that need ports on it (192.168.3.0), DMZ interface bridged with main WAN (WAN1)
      Runnng Squid with HAVP
      DNS forwarder enabled

      After reboot everything works great for about 12 hours, then the DMZ stops resolving DNS, LAN subnet is fine, not affected.  When it stops, I looked in the logs and cannot see any anomolies in DNS forwarder, Squid, or HAVP, after DNS stops a reboot fixes it immediately again for 12 hours.  I don't think it is a configuration issue, as if it were it would not work at all.  What am I missing?  The packet capture attached is on the DMZ subnet, you can see the resolve fails.  Any assistance on this would be great, I am tearing my hair out!  Thanks

      [dmz packat capture.txt](/public/imported_attachments/1/dmz packat capture.txt)

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

        I have no clue as I can't get my installation to work at all.

        But allow me to ask… what are the physical resources the pfSense box has available? Memory? Hard drive space? Does your ISP drop your connection after 12 hours for no apparent reason? Public Static IP?

        1 Reply Last reply Reply Quote 0
        • S Offline
          sgebhard
          last edited by

          The ISP doesnt' shut off after 12 hours, my LAN subnet is unaffected, if the ISP was shutting down, both WAN's would have to shut off, and my LAN is still resolving.  The hardware is a IBM Netvista P4 2.0 Gig CPU, 1 Gig RAM, all 4 NIC cards are brand new Intel gigabit.  New 80 gig hard drive also.  The public IP's (Both) are DHCP, but Cox doesn't change IP's I've had the same IP for 8 years on my main WAN!

          1 Reply Last reply Reply Quote 0
          • S Offline
            sgebhard
            last edited by

            Update on this issue:  Over the past days, one by one, I shut off packages that might disrupt DNS, first squid, then HAVP, then DNS forwarder, each time no change, DNS stops on the DMZ subnet.

            1 Reply Last reply Reply Quote 0
            • W Offline
              wallabybob
              last edited by

              Your packet capture shows DNS requests going to 68.105.29.11 and 68.105.29.12 yet you have DNS forwarding enabled. Some systems on your DMZ are not using using the DNS forwarder on the pfSense box. Is this intentional? What are the systems on the LAN using as DNS?

              I haven't read the whole of your capture but it appears that the DNS requests are being answered by ICMP    Destination unreachable (Host unreachable) from 192.168.3.1.  What is 192.168.3.1 (ISP router?) and why is it sending ICMP destination unreachable responses? Can you access 68.105.29.11 or 68.105.29.12 from LAN when this is happening? Are you seeing incoming ICMP destination unreachable responses on the WAN interface at this time?

              Why do you have DMZ and WAN bridged?

              1 Reply Last reply Reply Quote 0
              • S Offline
                sgebhard
                last edited by

                Good questions!  Like I said I am new to this.  When I moved the servers over to the DMZ subnet, some are statically set and I did not change the dns to reflect pfsense.  I'll try that.  Also 192.168.3.1 is the DMZ interface

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