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

    Internal DNS Not Working

    Scheduled Pinned Locked Moved DHCP and DNS
    dnsresolverforwarderlocalhostwan
    51 Posts 4 Posters 13.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.
    • NightlySharkN
      NightlyShark @aiden21c
      last edited by

      @aiden21c Also, as per dig, all is OK. You just tried pinging from the LAN ip of PfSense, which isn't NATed (meaning, it can't reach the internet, only WAN can).

      1 Reply Last reply Reply Quote 0
      • NightlySharkN
        NightlyShark @aiden21c
        last edited by

        @aiden21c Next try
        e04a59e9-ddee-4b48-980a-8990ee6cfa17-image.png

        1 Reply Last reply Reply Quote 0
        • A
          aiden21c
          last edited by

          @nightlyshark No good unfortunately. I have done the following:
          14.png 13.png 12.png 11.png 10.png

          My network setup is a concurrent dual wan setup. This is where I route all traffic out of WAN2 (my main WAN connection) and only traffic directed to the networks specified in the routing rules will be routed through WAN1. I eventually want to have VPN traffic come down through WAN2 and be able to reach the network on WAN1.
          Blank diagram.png

          A NightlySharkN 3 Replies Last reply Reply Quote 0
          • A
            aiden21c @aiden21c
            last edited by

            @aiden21c I have now found another very weird issue. I have reset my settings to give the client device access to the internet, and it seems as though when I reset these settings, the DNS forwarder is working exactly as expected. Btw there is no DHCP on the LAN.
            It seems that with my testing, I am actually only able to use the diagnostics to ping only the IP addresses specified within the General setup page. It doesn't matter what IPs I set in here, but so long as they are assigned to a gateway I can ping these from any of the 3 interfaces (2 WAN and 1 LAN). Examples:
            General Setup
            8.8.8.8 - wan2 gw
            8.8.4.4 - wan1 gw
            ping success to 8.8.4.4 and 8.8.8.8 from all 3 interfaces
            ping failure to 1.1.1.1 and 1.0.0.1 from all 3 interfaces

            General Setup 2
            1.1.1.1 - wan2
            1.0.0.1 - wan1
            ping success to 1.1.1.1 and 1.0.0.1 from all 3 interfaces
            ping failure to 8.8.8.8 and 8.8.4.4 from all 3 interface

            S 1 Reply Last reply Reply Quote 0
            • A
              aiden21c
              last edited by

              Here are the traceroutes to the hostnames of the DNS servers which are specified in the general setup page. Traceroutes fail if I attempt any other hostnames. In general setup, for this to work I need to set both gateways to use the DNS pair from the same provider, otherwise the opposing WAN and LAN wont be able to reach. Below I used 1.0.0.1 on WAN2 an 1.1.1.1 on WAN1.
              When DNS servers from different providers are in General Setup, I can ping both IPs from any interface, but I can not traceroute to both hostnames, only the IPs.
              19.png 18.png 17.png

              1 Reply Last reply Reply Quote 0
              • S
                SteveITS Galactic Empire @aiden21c
                last edited by

                @aiden21c I suggest using the DNS lookup diag page to test DNS problems. While Google DNS should answer pings, testing by ping introduces another layer. One problem at a time . :)

                Re pinging DNS servers, I believe pfSense sets up routing entries for them specifically. Ensure you have a default route and/or routing is correct.

                Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                Upvote ๐Ÿ‘ helpful posts!

                A 1 Reply Last reply Reply Quote 0
                • A
                  aiden21c @SteveITS
                  last edited by

                  @steveits as is visible above, DNS lookup was actually working. I was able to lookup facebook.com and have repeatedly been able to lookup google.com and others. I think this is likely a firewall or NAT issue, or something else entirely.
                  I still can't get my head around why my LAN client is able to use pfSense as it's dns and everything works fine, but the pfsense itself is having DNS (and outgoing Ping) issues, as I'm not actually able to use the ping diag tool to ping any IPs other than those specified.

                  GertjanG 1 Reply Last reply Reply Quote 0
                  • GertjanG
                    Gertjan @aiden21c
                    last edited by

                    @aiden21c

                    My turn.
                    I left "Resolving mode" for 48 hours.
                    I've tested Forwarding for a while.

                    I chose "1.1.1.1" - so I went to to 1.1.1.1 set up instructions. I even added TLS support.

                    So : first :

                    e88010cd-4407-4b87-8e3c-135f8c8869ec-image.png

                    Take note : strictly speaking, I have just one WAN, but IPv4 and IPv6 are separate. Half of all my outgoing traffic is IPv6 these days.

                    Then : Unbound :

                    e744f580-0673-49f9-8465-69648b0c06f0-image.png

                    I made no changes to the Unbound Advanced page, neither the ACL page.

                    I have no floating rules.

                    A DNS NAT rule for a specific interface : I force the (captive) PORTAL network to use 127.0.0.1 : that's unbound. I might as will delete this rule, I'm not using it myself.

                    7a962716-400a-427b-96a9-a746a7395c67-image.png

                    And that's it.
                    This morning, I even forgot about the fact I was not resolving anymore.

                    Since the day before, unbound didn't restart.
                    No DNS interruptions as far as I know.
                    During breakfast this morning, no captive portal clients were complaining.

                    Btw : I'm using 23.01.
                    I've done an identical test during one week with 22.05
                    Same thing with 2.6.0, the CE version.
                    Using a SG-4100.
                    I was using VDSL before January, 15, 2023. Since then, fiber.

                    No "help me" PM's please. Use the forum, the community will thank you.
                    Edit : and where are the logs ??

                    NightlySharkN 3 Replies Last reply Reply Quote 0
                    • NightlySharkN
                      NightlyShark @Gertjan
                      last edited by NightlyShark

                      @gertjan @aiden21c Please remove all port forwards or firewall rules that redirect or block DNS. If you have such rules activated with recursive mode, you are essentially redirecting Unbound packets back to itself.

                      @Gertjan Happy it works, anyway. Sorry for the edits, rushed to answer without drinking my coffee, first ๐Ÿ˜„ .

                      1 Reply Last reply Reply Quote 0
                      • NightlySharkN
                        NightlyShark @Gertjan
                        last edited by

                        @gertjan I must confess I don't have your full network diagram, though. If you get a chance, just to help anyone researching this in the future, make us a mock-up.

                        GertjanG 1 Reply Last reply Reply Quote 0
                        • NightlySharkN
                          NightlyShark @aiden21c
                          last edited by

                          @aiden21c Show screenshots of your firewall rules (all of them, and remove any public IPv4's), all Port Forwards and your Gateways (System->Routing).

                          A 1 Reply Last reply Reply Quote 0
                          • NightlySharkN
                            NightlyShark @Gertjan
                            last edited by

                            @gertjan Perhaps you were missing the accompanying FW rule?

                            1 Reply Last reply Reply Quote 0
                            • A
                              aiden21c @NightlyShark
                              last edited by

                              @nightlyshark These are my current firewall rules. I am not nearby the device atm, however I dont understand how removing the IPv4 route rules will help with this. I have no firewall rules on WAN1 and on WAN2 i only have the default rule which is added by the OVPN server. I have tried moving the DNS rule from the bottom to the top of the list to no avail.
                              8.png
                              I have no port forwards at this stage. I have a static route to 10.118.32.0/20 via the 192.168.6.0/30 network.
                              I have tried this configuration with and without any DNS listed in General Setup.
                              I have 2 gateways with no "Default IPv4" or "Default IPv6" gateway set.
                              WAN1 - 192.168.6.1/30
                              WAN2 - 192.168.20.1/24
                              Let me know if you require any more info.

                              NightlySharkN 2 Replies Last reply Reply Quote 0
                              • NightlySharkN
                                NightlyShark @aiden21c
                                last edited by

                                @aiden21c The counters for your first 2 rules show no traffic, just pointing it out.
                                When I asked about the FW rules, I meant (mostly) Floating, WAN and WAN2.

                                1 Reply Last reply Reply Quote 0
                                • NightlySharkN
                                  NightlyShark @aiden21c
                                  last edited by

                                  @aiden21c If you have private IPs on WAN and WAN2, that means that PfSense is behind a NAT. Routers should not (generally) connect to each other via the private space or behind NAT.

                                  A 1 Reply Last reply Reply Quote 0
                                  • A
                                    aiden21c @NightlyShark
                                    last edited by aiden21c

                                    @nightlyshark I don't have any fw rules on either Wan interface, nor any floating rules. I believe this is the issue I'm having where I have a double NAT on each interface. As per my network diagram above I do have routers on both WANs which are acting as a gateway for the pfsense. How would I go about avoiding this issue as I don't really have any other option for my setup.

                                    NightlySharkN 2 Replies Last reply Reply Quote 0
                                    • NightlySharkN
                                      NightlyShark @aiden21c
                                      last edited by NightlyShark

                                      @aiden21c said in Internal DNS Not Working:

                                      I dont understand how removing the IPv4 route rules

                                      Your NZ_Office rule is before the others (including DNS) and covers everything, making those rules unusable. The more general rules (any->any) go after any rules with restrictions (443, 80, 53).
                                      Also, your second rule has a destination of 192.168.6.1/30. Is this correct? Maybe you meant 192.168.6.0/30?
                                      Also, also, you have two routing rules for WAN, but a single gateway. Each WAN that routes somewhere should get a gateway.
                                      Also, also, also you have a routing rule for a private IPv4, 10.118.32.0/20:
                                      a5fa5511-82c1-40ac-999e-35382e08af55-image.png
                                      Is that the office subnet? I didn't see an interface on PfSense with an address in that subnet.

                                      1 Reply Last reply Reply Quote 0
                                      • NightlySharkN
                                        NightlyShark @aiden21c
                                        last edited by

                                        @aiden21c Do you mean CPE routers when you say "routers"? If so, you must contact your ISP(s) and get them to activate PPPoE passthrough on their CPEs, in order for you to be able to connect with a public IPv4.

                                        1 Reply Last reply Reply Quote 0
                                        • NightlySharkN
                                          NightlyShark
                                          last edited by

                                          This is how I'm set up:
                                          bffc5b03-4353-445d-909a-4ec8248e2696-image.png

                                          1 Reply Last reply Reply Quote 0
                                          • NightlySharkN
                                            NightlyShark @aiden21c
                                            last edited by NightlyShark

                                            @aiden21c If you don't have administrative access to those routers, your only option (to sneak your network) would be using a VPN. If you have administrative access on the routers and they are DSL and FTTH, turn PPPoE passthrough on on the CPE modem (call your ISP's tech support) and use a switch where you connect the PON, PfSense WAN and CPE of the FTTH ISP. The FTTH ISP would have to remove ACL MAC restrictions on your line and give you 2 dynamic IPv4s, a CG-NATed one for the CPE (telephony, TV...) and a no NAT one for PfSense.

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