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

    DNS Resolver Setup / Hardening

    Scheduled Pinned Locked Moved DHCP and DNS
    10 Posts 5 Posters 4.7k 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.
    • G
      guardian Rebel Alliance
      last edited by

      My plan is to use Untangle as my system's only way to resolve DNS.

      I am planning on using OpenDNS as DNS servers since they do some emerging threat screening.

      To prevent malware from using it's own DNS server to "call home" or tunneling traffic over DNS I want to prevent any other traffic from leaving the network via Port 53.

      I am using the DNS Resolver with the following DNS servers firewall rules:

      127.0.0.1
          208.67.222.222  [All OpenDNS - which if I understand correctly use DNS to protect against for some threats ]
          208.67.220.220
          208.67.220.123
          208.67.222.123

      Firewall Rules: (Capatures of the individual screens attached)
      PASS  IPv4 TCP/UDP *  *  LAN address 53 (DNS)  *  none Allow pfSense to handle DNS requests
      BLOCK IPv4 TCP/UDP *  *  *    53 (DNS)  *  none  Block DNS requests to anywhere else

      My questions are:

      • Is this strategy likely to break something?  Is my strategy for setting things up this way sound?

      • Have I done the firewall rules correctly - I found them somewhere (can't remember where), and I'm not 100% as to what they do.

      Thanks…
      ![DNS_FWRule_ Pass.jpg](/public/imported_attachments/1/DNS_FWRule_ Pass.jpg)
      ![DNS_FWRule_ Pass.jpg_thumb](/public/imported_attachments/1/DNS_FWRule_ Pass.jpg_thumb)
      DNS_FWRule_Block.jpg
      DNS_FWRule_Block.jpg_thumb

      If you find my post useful, please give it a thumbs up!
      pfSense 2.7.2-RELEASE

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

        You want those rules on LAN, not WAN. Otherwise looks fine.

        1 Reply Last reply Reply Quote 0
        • G
          guardian Rebel Alliance
          last edited by

          @cmb:

          You want those rules on LAN, not WAN. Otherwise looks fine.

          Thanks for that… tested and works great.  For the benefit of other Noobs like myself, I'll post screen shots for 2.3.1.

          I'm wondering what the difference is between the way I have done this vs the method described here?

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

          I tried disabling my rules a setting up this rule but all it did was break DNS for the LAN.

          This is the way my DNS servers are set up:

          127.0.0.1
              208.67.222.222
              208.67.220.220
              208.67.220.123
              208.67.222.123

          so I assume that this condition:

          'Before adding this rule, ensure the DNS Forwarder or DNS Resovler is configured to bind and answer queries on Localhost, or All interfaces.'

          has been satisfied, but maybe there is something I don't understand.

          The interface has changed and maybe I did something wrong and didn't set up the rule as directed.

          The entries: NAT reflection / Filter rule association confused me.  Not sure if I should have done something with them or not.

          pfSense-DNS_Capture1.jpg
          pfSense-DNS_Capture1.jpg_thumb
          pfSense-DNS_Capture2.jpg
          pfSense-DNS_Capture2.jpg_thumb

          If you find my post useful, please give it a thumbs up!
          pfSense 2.7.2-RELEASE

          1 Reply Last reply Reply Quote 0
          • P
            paftdunk
            last edited by

            I've been doing the same thing awhile, and for the same reason. The only thing that broke was my 2nd gen Ooma voip box–another 1st gen box didn't care. So I just gave its ip permission for outbound :53.

            1 Reply Last reply Reply Quote 0
            • G
              guardian Rebel Alliance
              last edited by

              @paftdunk:

              I've been doing the same thing awhile, and for the same reason. The only thing that broke was my 2nd gen Ooma voip box–another 1st gen box didn't care. So I just gave its ip permission for outbound :53.

              Maybe one of the experts here can comment… is it possible to set up an alias in the Resolver to make these boxes with hard coded DNS servers think the Resolver the DNS server that they have hard coded.

              Slightly off topic... but I'd like to do the same thing with NTP.... Is it possible to block outside access to NTP and use a aliases (or some other mechanism) to force pool.ntp.org (or whatever) to use the pfsense box?  (Using the logs to figure out what names to setup as aliases.)

              If you find my post useful, please give it a thumbs up!
              pfSense 2.7.2-RELEASE

              1 Reply Last reply Reply Quote 0
              • P
                paftdunk
                last edited by

                Your question made me realize there's actually a much better way to do this: NAT Port Forwarding.

                I set up a port forward rule to redirect all LAN originated traffic for :53 to my firewall ip. As soon as I created it, I started seeing the actual lookups my ooma was directing to their own servers.

                $ dig @8.8.8.8 blog.pfsense.org
                ;; reply from unexpected source: 10.100.100.1#53, expected 8.8.8.8#53
                
                1 Reply Last reply Reply Quote 0
                • johnpozJ
                  johnpoz LAYER 8 Global Moderator
                  last edited by

                  " I want to prevent any other traffic from leaving the network via Port 53"

                  I don't really get the redirect mentality.. Why not just block it outright if that is what you want to prevent?  To me redirection of traffic is bad, you sure wouldn't like it if your isp did that ;)

                  Same goes for ntp, if you want clients to use your ntp then hand it out via dhcp, or set your window machines to use it.  Things that don't work via ntp will get the idea they should use the local provided one..

                  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 24.11 | Lab VMs 2.8, 24.11

                  1 Reply Last reply Reply Quote 0
                  • K
                    kpa
                    last edited by

                    Just create a rule on the LAN interface that blocks TCP and UDP traffic to port 53 unless the destination address is one of pfSense's own addresses. Turn on logging for the rule. Make sure the rule is placed before any pass rules, job done.

                    1 Reply Last reply Reply Quote 0
                    • G
                      guardian Rebel Alliance
                      last edited by

                      Hi johnpoz…

                      @johnpoz:

                      " I want to prevent any other traffic from leaving the network via Port 53"

                      I don't really get the redirect mentality.. Why not just block it outright if that is what you want to prevent?  To me redirection of traffic is bad, you sure wouldn't like it if your isp did that ;)

                      What I actually wanted to do is to force pfSense to be DNS resolver for the whole network.  Still debating if I should force it to use OpenDNS servers (for malware screening) or leave the setting the way it is to actually do a recursive lookup.  I also will eventually bring in pfBlocker/Suricata which I believe net a controlled DNS as well.  Hard coded stuff just breaks so it is going to take some kind of router magic to fix it.

                      @johnpoz:

                      Same goes for ntp, if you want clients to use your ntp then hand it out via dhcp, or set your window machines to use it.  Things that don't work via ntp will get the idea they should use the local provided one..

                      With NTP is there an alternative?

                      Windows doesn't allow custom NTP servers does it?.

                      Also some consumer boxes have these things in firmware that aren't easy to change.  They use something.pool.ntp.org or whatever it is. 
                      I've been worried about some ot that traffic from a myriad of different servers of unknown accuracy from all over that may be doing something over port 123 other than NTP that I don't know about.

                      I've got my pfSense box talking nice to the redundant National Reasearch Centre in Canada and the time is steady as a rock within 100ms,

                      If you find my post useful, please give it a thumbs up!
                      pfSense 2.7.2-RELEASE

                      1 Reply Last reply Reply Quote 0
                      • G
                        guardian Rebel Alliance
                        last edited by

                        @paftdunk:

                        Your question made me realize there's actually a much better way to do this: NAT Port Forwarding.

                        I set up a port forward rule to redirect all LAN originated traffic for :53 to my firewall ip. As soon as I created it, I started seeing the actual lookups my ooma was directing to their own servers.

                        $ dig @8.8.8.8 blog.pfsense.org
                        ;; reply from unexpected source: 10.100.100.1#53, expected 8.8.8.8#53
                        

                        Can you please share a screen capture (or at least be a bit more specific…. I'm not clear about how you did this.  Thanks.

                        If you find my post useful, please give it a thumbs up!
                        pfSense 2.7.2-RELEASE

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