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

    23.01 Unable to answer DNS queries after upgrade

    Scheduled Pinned Locked Moved
    General pfSense Questions
    6
    29
    4.0k
    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
      thebear @Bob.Dig
      last edited by

      @bob-dig said in 23.01 Unable to answer DNS queries after upgrade:

      No problems here.

      What is still a problem is Query refused if using an ULA for LAN.

      *** UnKnown can't find reddit.com: Query refused

      Did you correct the ACL to allow these addresses to query DNS?

      Bob.DigB 2 Replies Last reply Reply Quote 0
      • Bob.DigB
        Bob.Dig LAYER 8 @thebear
        last edited by

        @thebear No, I changed nothing and the ULA is the only or lets say main IPv6 address on LAN.

        hn0.100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	description: LAN
	options=80000<LINKSTATE>
	ether 00:15:5d:09:1e:19
	inet6 fe80::215:5dff:fe09:1e19%hn0.100 prefixlen 64 scopeid 0x18
	inet6 fd7b:97bf:48b9:100:192:168:100:1 prefixlen 64
	inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
	groups: vlan GroupNTP
	vlan: 100 vlanproto: 802.1q vlanpcp: 0 parent interface: hn0
	media: Ethernet autoselect (10Gbase-T <full-duplex>)
	status: active
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        1 Reply Last reply Reply Quote 0
        • M
          michmoor LAYER 8 Rebel Alliance
          last edited by

          Update for everyone.

          So far the fix for this was to re-do the DoT settings again. I went into DNS Resolver settings. Unchecked and then rechecked the following options.

          48d41ae0-cdd1-4025-973e-65acc7028bf9-image.png

          2hrs later the firewall is still answering queries so that seems to have fixed it.

          Firewall: NetGate,Palo Alto-VM,Juniper SRX
          Routing: Juniper, Arista, Cisco
          Switching: Juniper, Arista, Cisco
          Wireless: Unifi, Aruba IAP
          JNCIP,CCNP Enterprise

          1 Reply Last reply Reply Quote 2
          • Bob.DigB
            Bob.Dig LAYER 8 @thebear
            last edited by

            @thebear For the record, manually creating an ACL solves the problem but it shouldn't be necessary to begin with.

            T 1 Reply Last reply Reply Quote 0
            • T
              thebear @Bob.Dig
              last edited by

              @bob-dig why? I also needed to add a IPv6 ACL next to my IPv4 ACL I got with 22.05. Somehow the behavior has changed with 23.01.

              Without the ACL's, where is the allow all option? If that not exists then the ACL is needed, right?

              Bob.DigB 1 Reply Last reply Reply Quote 0
              • Bob.DigB
                Bob.Dig LAYER 8 @thebear
                last edited by

                @thebear said in 23.01 Unable to answer DNS queries after upgrade:

                Without the ACL's, where is the allow all option?

                Here it is:
                Capture.PNG

                T 1 Reply Last reply Reply Quote 0
                • T
                  thebear @Bob.Dig
                  last edited by

                  @bob-dig Yeah I know, without the boxes checked pfSense should add the auto rules to unbound right?

                  And you confirming, my experiences, that is starts working after adding a manual IPv6 ACL.

                  Get my point there might be a bug involved in the default/auto ACL's for IPv6?

                  T 1 Reply Last reply Reply Quote 0
                  • T
                    thebear @thebear
                    last edited by thebear

                    Here is the proof, without ACL's IPv4 remains functional and IPv6 stops.

                    status: REFUSED

                    ~ % dig @172.16.1.1 forum.netgate.com

; <<>> DiG 9.10.6 <<>> @172.16.1.1 forum.netgate.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57847
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;forum.netgate.com.		IN	A

;; ANSWER SECTION:
forum.netgate.com.	1485	IN	A	208.123.73.199

;; Query time: 134 msec
;; SERVER: 172.16.1.1#53(172.16.1.1)
;; WHEN: Thu Feb 16 11:18:34 CET 2023
;; MSG SIZE  rcvd: 62

                    ~ % dig forum.netgate.com

; <<>> DiG 9.10.6 <<>> forum.netgate.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 58561
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; Query time: 43 msec
;; SERVER: 2a02:a469:<cut>#53(2a02:a469:<cut>)
;; WHEN: Thu Feb 16 11:18:40 CET 2023
;; MSG SIZE  rcvd: 12

                    With the ACL added:

                     ~ % dig forum.netgate.com

; <<>> DiG 9.10.6 <<>> forum.netgate.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44698
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;forum.netgate.com.		IN	A

;; ANSWER SECTION:
forum.netgate.com.	1267	IN	A	208.123.73.199

;; Query time: 41 msec
;; SERVER: 2a02:a469:435b:<cut>#53(2a02:a469:<cut>)
;; WHEN: Thu Feb 16 11:22:13 CET 2023
;; MSG SIZE  rcvd: 62
                    Bob.DigB 1 Reply Last reply Reply Quote 1
                    • Bob.DigB
                      Bob.Dig LAYER 8 @thebear
                      last edited by Bob.Dig

                      @thebear I thought it would only be a "bug" with ULA but yours even look like a GUA.

                      T 1 Reply Last reply Reply Quote 0
                      • T
                        thebear @Bob.Dig
                        last edited by thebear

                        @bob-dig said in 23.01 Unable to answer DNS queries after upgrade:

                        @thebear I thought it would only be a "bug" with ULA but yours even look like a GUA.

                        Indeed. Glad we came to the same conclusion.

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          So to be clear you did not need those ACLs in 22.05? The auto added ACLs were passing v6 queries there?

                          Steve

                          T Bob.DigB 2 Replies Last reply Reply Quote 0
                          • T
                            thebear @stephenw10
                            last edited by

                            @stephenw10 well as IT expert you change a lot every week, I think the short answer is yes. We did not need the extra v6 ACL to get the IPv6 DNS queries flowing.

                            If you want I can BE boot to an older release tot verify, need to wait until later tonight.

                            1 Reply Last reply Reply Quote 0
                            • Bob.DigB
                              Bob.Dig LAYER 8 @stephenw10
                              last edited by

                              @stephenw10 I even had dns problems in Windows, it would prefer the IPv6 that is given by pfSense and then it doesn't worked. Only because of the DNS problem in Windows I had to look closer.
                              Later Windows switched to the IPv4 and DNS worked again "on its own". But I never encountered that problem before so my guess is, it must have worked before. And again, pfSense is giving this address... its interface address. Like seen here.

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                Ok, I'll try to replicate it.

                                1 Reply Last reply Reply Quote 1
                                • jimpJ
                                  jimp Rebel Alliance Developer Netgate
                                  last edited by

                                  We've had a couple threads with similar reports but I've never been able to trigger it in my lab. It could be a timing issue where at the moment it collects the networks for the ACLs they aren't on the interface (yet?) but then they appear later, but there is no interface event when the delegated prefix gets added to the LAN(s) so Unbound doesn't restart after to pick up the change in ACLs.

                                  No amount of fiddling with options is likely to have any more impact than simply saving in Unbound without changing anything, triggering it to rewrite its config files.

                                  Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                  Need help fast? Netgate Global Support!

                                  Do not Chat/PM for help!

                                  Bob.DigB 1 Reply Last reply Reply Quote 0
                                  • Bob.DigB
                                    Bob.Dig LAYER 8 @jimp
                                    last edited by Bob.Dig

                                    @jimp Is this regarding to OP or "to the rest", because OPs problem is gone as far as I can see.
                                    For me I have ULAs so no delegated prefix at all and unbound still only allows IPv4. Also I am rebooting my pfSense on a daily bases via cron. Restarting Unbound doesn't solves this. If it helps you could move my thread in an active forum.

                                    1 Reply Last reply Reply Quote 0
                                    • jimpJ
                                      jimp Rebel Alliance Developer Netgate
                                      last edited by

                                      Adding a manual ACL works around the issue but it doesn't solve the root cause of the problem.

                                      By default the IPv4 and IPv6 networks of all local (non-WAN) interfaces used by Unbound should be allowed through Unbound. If the list is incomplete in some way then the networks were not on the interface when the Unbound config was generated.

                                      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                      Need help fast? Netgate Global Support!

                                      Do not Chat/PM for help!

                                      Bob.DigB 1 Reply Last reply Reply Quote 0
                                      • Bob.DigB
                                        Bob.Dig LAYER 8 @jimp
                                        last edited by

                                        @jimp I will delete it manually if you tell a windows noob where to find it, I have not that much options set.

                                        1 Reply Last reply Reply Quote 0
                                        • jimpJ
                                          jimp Rebel Alliance Developer Netgate
                                          last edited by

                                          The ACLs are in /var/unbound/access_lists.conf so that's where I'd look.

                                          Even with your manual ACL entry the automatic ones will still be there.

                                          Anyone who sees this should check the file before touching anything else and then again after restarting Unbound to see if there is a difference.

                                          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                          Need help fast? Netgate Global Support!

                                          Do not Chat/PM for help!

                                          T Bob.DigB 2 Replies Last reply Reply Quote 0
                                          • T
                                            thebear @jimp
                                            last edited by thebear

                                            @jimp

                                            It seems only the loopbacks are in the auto config. I'm using DHCP-PD for my LAN.

                                            With my manual IPv6 ACL

                                            [23.01-RELEASE][admin@pfSense.high.local]/root: cat /var/unbound/access_lists.conf
access-control: 127.0.0.1/32 allow_snoop
access-control: ::1 allow_snoop
access-control: 10.10.10.0/24 allow
access-control: 10.81.240.0/22 allow
access-control: 10.110.1.0/24 allow
access-control: 10.110.2.0/24 allow
access-control: 127.0.0.0/8 allow
access-control: 172.16.1.0/24 allow
access-control: 172.16.2.0/24 allow
access-control: 172.16.6.0/24 allow
access-control: 172.16.7.0/24 allow
access-control: 172.16.8.0/24 allow
access-control: 172.16.26.0/24 allow
access-control: 172.16.27.0/24 allow
access-control: ::1/128 allow
#WireGuard
access-control: 10.10.10.0/24 allow
#IPv6
access-control: 2a02:a469:<cut>::/48 allow

                                            With the default auto generated ACL where the DNS request at the IPv6 address are REFUSED.

                                            [23.01-RELEASE][admin@pfSense.high.local]/root: cat /var/unbound/access_lists.conf
access-control: 127.0.0.1/32 allow_snoop
access-control: ::1 allow_snoop
access-control: 10.10.10.0/24 allow
access-control: 10.81.240.0/22 allow
access-control: 10.110.1.0/24 allow
access-control: 10.110.2.0/24 allow
access-control: 127.0.0.0/8 allow
access-control: 172.16.1.0/24 allow
access-control: 172.16.2.0/24 allow
access-control: 172.16.6.0/24 allow
access-control: 172.16.7.0/24 allow
access-control: 172.16.8.0/24 allow
access-control: 172.16.26.0/24 allow
access-control: 172.16.27.0/24 allow
access-control: ::1/128 allow
#WireGuard
access-control: 10.10.10.0/24 allow
                                            jimpJ 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post