Navigation

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

    [SOLVED] DNS on WAN - host overrides

    DHCP and DNS
    3
    7
    358
    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.
    • P
      pq last edited by

      Hello,
      I have pfSense on intranet network, separated fom internet. I have WAN on intranet and LAN on my local network, I am using NAT. I would like to set pfSense as DNS server for requests coming on WAN and asking translations for my servers. I will have up to 10 DNS records and I want to set it statically.

      I enabled resolver, enabled it on WAN, created rule and now playing with Host overrides and Domain overrides.
      I have host overrides  KUKI    MYDOMAIN.MY  10.10.10.10

      If I try ask for it using nslookup, response is only Query refused.
      Can anybody help me, please?
      pq

      1 Reply Last reply Reply Quote 0
      • KOM
        KOM last edited by

        If I try ask for it using nslookup, response is only Query refused.

        If your intranet is using RFC1918 addressing, which is likely, then you need to uncheck the Block private networks option on your WAN interface or it will reject all unsolicite dtraffic coming from 10.0.0.0/8. 192.168.0.0/16 and 172.16.0.0/12.

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

          Why are you natting internally I would ask.. There is almost zero reason to ever do such a thing.  Other than overlapping networks why would you need/want to nat your internal rfc1918 space to a different rfc1918 address?

          If you have network(s) behind pfsense in an internal network you should just connect pfsense "wan" to your network via a transit network to your upstream router and disable nat.. You can then just firewall what you want firewall vs having to nat.

          If you want pfsense dns to provide entries for stuff behind to your upstream network then sure you could all its dns to be queried from the wan side with a simple firewall rule.  And then your upstream networks would just need be designed to query pfsense IP to query those records.

          Keep in mind that unbound or dnsmasq that are part of pfsense are not really designed to be actual authoritative NS for domains you might be using internally.  Bind would be a package you could add to allow for authoritative name services and also would allow for zone transfers to your other internal name servers, etc.

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

            @KOM:

            If I try ask for it using nslookup, response is only Query refused.

            If your intranet is using RFC1918 addressing, which is likely, then you need to uncheck the Block private networks option on your WAN interface or it will reject all unsolicite dtraffic coming from 10.0.0.0/8. 192.168.0.0/16 and 172.16.0.0/12.

            Thank you for a tip.
            Checkbox was unchecked. I get response from DNS in pfSense, but response is "Refused".

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

              @johnpoz:

              Why are you natting internally I would ask.. There is almost zero reason to ever do such a thing.  Other than overlapping networks why would you need/want to nat your internal rfc1918 space to a different rfc1918 address?

              If you have network(s) behind pfsense in an internal network you should just connect pfsense "wan" to your network via a transit network to your upstream router and disable nat.. You can then just firewall what you want firewall vs having to nat.

              If you want pfsense dns to provide entries for stuff behind to your upstream network then sure you could all its dns to be queried from the wan side with a simple firewall rule.  And then your upstream networks would just need be designed to query pfsense IP to query those records.

              Keep in mind that unbound or dnsmasq that are part of pfsense are not really designed to be actual authoritative NS for domains you might be using internally.  Bind would be a package you could add to allow for authoritative name services and also would allow for zone transfers to your other internal name servers, etc.

              Our intranet is huge network, about 60 thousands PC in hundred localities. Many departments have there their own LAN, with their own rules. Intranet is on 10.x.x.x and local networks on 192.168.x.x.  Blocking private is unchecked in my pfSense .

              DNS service on my pfSense is now running on WAN. When I send DNS request on record written in host overrides from WAN network to WAN interface, I get response "Refused" (I am checking it with Wireshark, I'm sure it is DNS answer from pfSense.).  Later  Later I can arrange, that DNS queries from intranet users will come on WAN interface. Only problem is registering records and make unbound to use them. I need the resolver only for WAN interface. (I have MS Active Directory with DNS on MS AD in my LAN.)

              Can unbound or bind fulfill my needs?
              Thank you.

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

                And did you correct the unbound ACLs to allow query from where you want?

                "Many departments have there their own LAN"

                So Wild Wild Wild network - freaking fantastic….

                This is what IPAM fixes.. 60k nodes is nothing.. Nor is 100 locations.  You could give every one of those locations their own /16 to use out of the 10/8 - now no overlap..  Really simple to manage this sort of thing.  Each location could have 60K nodes... And you would still have plenty of room for 150 more locations using the same dead simple /16 design...


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

                  Wild? Only a litle bit. :-)  It is not departments, it is many state organizations from different parts of state administration, they have different management, different legislation, different systems…

                  Adding ACL helped me, now is it working. I am realy stupid I didn't realise this can be the reason.

                  Thank you very much, you are the best.

                  Have a nice day.
                  pq

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post

                  Products

                  • Platform Overview
                  • TNSR
                  • pfSense Plus
                  • Appliances

                  Services

                  • Training
                  • Professional Services

                  Support

                  • Subscription Plans
                  • Contact Support
                  • Product Lifecycle
                  • Documentation

                  News

                  • Media Coverage
                  • Press
                  • Events

                  Resources

                  • Blog
                  • FAQ
                  • Find a Partner
                  • Resource Library
                  • Security Information

                  Company

                  • About Us
                  • Careers
                  • Partners
                  • Contact Us
                  • Legal
                  Our Mission

                  We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                  Subscribe to our Newsletter

                  Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                  © 2021 Rubicon Communications, LLC | Privacy Policy