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

    Problems with pfSense IPV6 DNS function (does it exist!?)

    Scheduled Pinned Locked Moved CE 2.7.0 Development Snapshots (Retired)
    41 Posts 10 Posters 12.0k 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.
    • L
      louis2 @johnpoz
      last edited by

      @johnpoz

      My actual version is 2.7 built on Fri Jan 06 06:05:17 UTC 2023

      And even if the problem is only related to the 2.7 build, it is still a bug / something to be fixed.

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

        @louis2 said in Problems with pfSense IPV6 DNS function (does it exist!?):

        it is still a bug / something to be fixed.

        What snap are you on - for all we know it was already taken care of.. Your whole thread should of been in the dev section if your using a snapshot/beta..

        I agree it needs to be corrected if it an actual problem - but before going taking the time to report a "bug" I would bring up your issue in the dev section for 2.7, what snap are you using, etc.

        edit: should prob move this whole thread to here

        https://forum.netgate.com/category/88/ce-2-7-0-development-snapshots

        And you can add what snapshot your on, and see if anyone else seeing the problem - then they can fix it, etc. For all we know it was a temp issue on your specific snap

        edit: I moved this thread to 2.7 dev - could you post up your snapshot version your using, and update to the current snap and validate it still an issue with auto acls adding IPv6, etc.

        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.7.2, 24.11

        L 1 Reply Last reply Reply Quote 0
        • johnpozJ johnpoz moved this topic from DHCP and DNS on
        • L
          louis2 @johnpoz
          last edited by

          @johnpoz

          I do not know if the problem is only related to the 2.7 release. Perhaps I doubt.

          I also did not know if I did something stupid or that it was a bug in first instance.

          But If you think it should be in the def section two things:

          • be so kind to test first if it does work on a stable release
          • and if so be my guest move this thread to the dev section, that is something I can not do
          johnpozJ C 2 Replies Last reply Reply Quote 0
          • johnpozJ
            johnpoz LAYER 8 Global Moderator @louis2
            last edited by

            @louis2 I have moved it.. If it was an issue with stable I would think would of been reported long ago.. But sure I can test it on my 2.6 vm install and my 22.05 main setup.

            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.7.2, 24.11

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

              @louis2

              Not related .... but :

              b9b46713-e1a8-43c9-b9b1-e0c60cb05abe-image.png

              These are not comment fields for you own usage.
              If you fill them in, use the real host name.
              To find out :

              [22.05-RELEASE][root@pfSense.wth.net]/root: host 1.0.0.1
              1.0.0.1.in-addr.arpa domain name pointer one.one.one.one.
              [22.05-RELEASE][root@pfSense.wth.net]/root: host 8.8.8.8
              8.8.8.8.in-addr.arpa domain name pointer dns.google.
              etc.
              

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

              L 1 Reply Last reply Reply Quote 1
              • C
                cursixx @louis2
                last edited by

                @louis2 I'm having the same problem with dev plus 23.01 and dev CE 1/06.

                When using DNS Resolver (Enable Forwarding Mode on and off) to the LAN ipv6 address I get a query refused. ipv4 LAN address works fine

                If I switch to DNS Forwarder both ipv4 and ipv6 return results as expected.

                The symptoms I first noticed was, when loading sites in chrome I would get dns_probe_finished_nxdomain for 2-3 secs and then the site would load. ios and andriod devices would have problems too.

                My setup is pretty much default.

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

                  @cursixx you get a refused returned or dns just fails? Refused is indication that acls are not allowing your query, fail or timeout would point to possible other issue. I do believe there has been some issues related to unbound and using IPv6 in general.

                  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.7.2, 24.11

                  C 1 Reply Last reply Reply Quote 0
                  • C
                    cursixx @johnpoz
                    last edited by

                    @johnpoz yes unbound returns "query refused" only with ipv6 LAN address as the DNS. I'm not sure when this started but it has been going on for at least a few weeks for me. I update dev just about everyday but switch back to stable from time to time.

                    Anything you want me to test with this?

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

                      @gertjan

                      Thanx! I did enter that a while back not reading, just assuming what should be there 😥

                      At this moment I doubt a bit about what should be there

                      • 1.0.0.1.in-addr.arpa or
                      • one.one.one.one. (with or without ending dot !?)

                      For now I defined it as shown in the picture below.
                      nslookup one.one.one.one. with and without dot function both !??

                      77c3552a-de96-459a-8854-fd2c7dcb93df-image.png

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

                        @cursixx said in Problems with pfSense IPV6 DNS function (does it exist!?):

                        Anything you want me to test with this?

                        If you use unbound without pfBlockerng-devel, you could set Services > DNS Resolver > Advanced Settings log level to 4, 5 or even 6.
                        Be careful : don't leave your system in this sate forever. unbound now start to log a lot (like a huge load of a lot) log lines. These will get rotated very often, but still, see this as a test - and stay onto it.
                        Or, if you have unbound and pfBlockerng-devel, and you use the python mode, : go here : Firewall > pfBlockerNGLog > Browser and select the dns_reply.log.

                        As soon as you detect an issue, go check the log file and see if unbound received the DNS request (you have the domain name, so search for it) and see what unbound received the request, and what it did with it.

                        Check also your device's IPv6, which should match with what you find here : /var/unbound/access_lists.conf

                        Example :
                        I used nslookup to resolve :

                        nslookup www.google.es. 2001:470:1f13:beef:2::1
                        

                        where 2001:470:1f13:beef:2::1 is the LAN IPv6 of my LAN.
                        In the dns_reply.log I saw :

                        DNS-reply,Jan 9 16:29:34,reply,A,A,300,www.google.es,2001:470:1f13:5c0:2::88,74.125.140.94,US
                        DNS-reply,Jan 9 16:29:35,reply,AAAA,AAAA,300,www.google.es,2001:470:1f13:5c0:2::88,2a00:1450:4007:81a::2003,IE
                        

                        and that was correct, nslookup was asking for the A and the AAAA.

                        @louis2 said in Problems with pfSense IPV6 DNS function (does it exist!?):

                        nslookup one.one.one.one. with and without dot function both !??

                        Look in the dns_reply.log file and you have you answer ;)

                        When you do a :
                        nslookup somethingspecial.tld

                        You will see this (these) line(s) :

                        DNS-reply,Jan 9 16:36:43,reply,A,SOA,3600,somethingspecial.tld.my-pfsense-local-domain.net,192.168.1.2,SOA,unk
                        

                        If you don't stop with a dot, unbound (nslookup probably) will add the device's local network domain.

                        That why this works :

                        C:\Users\gwkro>nslookup gauche2
                        Serveur :   pfSense.my-pfsense-local-domain.net
                        Address:  192.168.1.1
                        
                        Nom :    gauche2.my-pfsense-local-domain.net
                        Addresses:  2001:470:1f13:beef:2::c7
                                  192.168.1.6
                        

                        "gauche2" is a PC in my pfSense LAN.

                        I could (should !) also ask :
                        gauche2.my-pfsense-local-domain.net.
                        which is de fully qualified host name of that device.

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

                        L C 2 Replies Last reply Reply Quote 0
                        • M
                          marcosm Netgate
                          last edited by

                          This sounds like a mis-configuration somewhere rather than a bug. For reference, the ACLs are stored in /var/unbound/access_lists.conf. It works correctly here:

                          #> nslookup google.com 2001:db8::1
                          Server:  gw.home.arpa
                          Address:  2001:db8::1
                          
                          Non-authoritative answer:
                          Name:    google.com
                          Addresses:  2607:f8b0:4023:1006::64
                                    2607:f8b0:4023:1006::65
                                    2607:f8b0:4023:1006::8a
                                    2607:f8b0:4023:1006::8b
                                    142.251.32.238
                          
                          L Bob.DigB 2 Replies Last reply Reply Quote 0
                          • L
                            louis2 @marcosm
                            last edited by

                            @marcosm

                            Yep thanks explaining where the config file is. However, yep there are no IPV6-entrys appart of the test one I entered manually.

                            [2.7.0-DEVELOPMENT][root@pfSense.lan]/root: cat /var/unbound/access_lists.conf
                            access-control: 127.0.0.1/32 allow_snoop
                            access-control: ::1 allow_snoop
                            access-control: 10.128.244.0/22 allow
                            access-control: 127.0.0.0/8 allow
                            access-control: 192.168.1.0/24 allow
                            access-control: 192.168.2.0/24 allow
                            access-control: 192.168.2.1/24 allow
                            access-control: 192.168.5.0/24 allow
                            access-control: 192.168.9.0/24 allow
                            access-control: 192.168.10.0/24 allow
                            access-control: 192.168.11.0/24 allow
                            access-control: 192.168.13.0/24 allow
                            access-control: 192.168.14.0/24 allow
                            access-control: 192.168.17.0/24 allow
                            access-control: 192.168.18.0/24 allow
                            access-control: 192.168.88.0/24 allow
                            access-control: 192.168.100.0/24 allow
                            access-control: 192.168.110.0/24 allow
                            access-control: 192.168.111.0/24 allow
                            access-control: 192.168.120.0/24 allow
                            access-control: 192.168.130.0/24 allow
                            access-control: ::1/128 allow
                            #IPV6-test
                            access-control: 2a02:xxxx:yyyy:11::/64 allow

                            1 Reply Last reply Reply Quote 0
                            • L
                              louis2 @Gertjan
                              last edited by

                              @gertjan

                              I am still confused. I did not have a look at the logging yet,

                              however:

                              • nslookup example.com dns.google AND
                              • nslookup example.com dns.google. AND
                              • nslookup example.com 2001:4860:4860::8844 AND
                              • nslookup example.com 8.8.8.8

                              Are all providing the same correct answer. And all provide the correct server name dns.google (without an domain added).
                              So that does not match your example .. / screen captures ....

                              The second column in the DNS entry screen say
                              Hostname
                              Enter the DNS Server Hostname for TLS Verification in the DNS Resolver (optional)

                              So that suggests a name not an address ....
                              Is 8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. a name or an address !? I would say an address

                              The documentations says
                              The FQDN of the DNS server, used to validate DNS server certificates when using DNS over TLS (DNS Resolver Configuration).

                              Further on:
                              https://www.nslookup.io/domains/dns.google/dns-records/ptr/

                              2001:4860:4860::8888 => 8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400 PTR dns.google
                              dns.google does not have any PTR records.
                              dns.google. does not have any PTR records.
                              dns.google.com does not have any PTR records.

                              So I will do some debugging, but to say that the page or documentation is helpful ..... hardly. One or more examples would help.

                              Then we have this setting
                              3c297336-077e-4efd-bd11-165796a89063-image.png

                              Showing IPV4 behavoir .... I assume that behavoir is also used for IPV6 ....

                              1 Reply Last reply Reply Quote 0
                              • C
                                cursixx @Gertjan
                                last edited by

                                @gertjan Here is the debug log. Let me know if you think I missed something (sorry for the picture. spam filter would not let me post it as code)

                                cb2e2f26-08b3-48ce-a8c4-aa74d18a3c65-image.png

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

                                  @louis2 said in Problems with pfSense IPV6 DNS function (does it exist!?):

                                  used to validate DNS server certificates

                                  this is big take away.. that fqdn is used on the cert to validate your talking to the right dot server..

                                  So for example if I do a dot query to 1.1.1.1 and tell it to validate everything then using something other than the CN or what is in the SAN of the cert would fail.. A normal dot query should be validating this..

                                  You can get all the info of CN and SANs that are in the cert with some use of openssl, notice the output below for the CN and SANs in that cert being used at 1.1.1.1 on port 853.

                                  But from a kdig asking for validation you can see it fails if I use a fqdn that is not CN or SAN.

                                  root@NewUC:/home/user# kdig -d @1.1.1.1 www.google.com +tls-ca
                                  ;; DEBUG: Querying for owner(www.google.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
                                  ;; DEBUG: TLS, imported 124 system certificates
                                  ;; DEBUG: TLS, received certificate hierarchy:
                                  ;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
                                  ;; DEBUG:      SHA-256 PIN: MnLdGiqUGYhtyinlrGTC4FZdDyDXv4NOWFGnXW3ur14=
                                  ;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
                                  ;; DEBUG:      SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM=
                                  ;; DEBUG: TLS, skipping certificate PIN check
                                  ;; DEBUG: TLS, The certificate is trusted. 
                                  ;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
                                  ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 30091
                                  ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
                                  
                                  ;; EDNS PSEUDOSECTION:
                                  ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
                                  ;; PADDING: 405 B
                                  
                                  ;; QUESTION SECTION:
                                  ;; www.google.com.              IN      A
                                  
                                  ;; ANSWER SECTION:
                                  www.google.com.         128     IN      A       142.250.191.132
                                  
                                  ;; Received 468 B
                                  ;; Time 2023-01-09 13:12:01 CST
                                  ;; From 1.1.1.1@853(TCP) in 61.0 ms
                                  root@NewUC:/home/user# 
                                  

                                  But if I tell it wrong host name..

                                  ;; From 1.1.1.1@853(TCP) in 61.0 ms
                                  root@NewUC:/home/user# kdig -d @1.1.1.1 www.google.com +tls-ca +tls-host=badname
                                  ;; DEBUG: Querying for owner(www.google.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
                                  ;; DEBUG: TLS, imported 124 system certificates
                                  ;; DEBUG: TLS, received certificate hierarchy:
                                  ;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
                                  ;; DEBUG:      SHA-256 PIN: MnLdGiqUGYhtyinlrGTC4FZdDyDXv4NOWFGnXW3ur14=
                                  ;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
                                  ;; DEBUG:      SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM=
                                  ;; DEBUG: TLS, skipping certificate PIN check
                                  ;; DEBUG: TLS, The certificate is NOT trusted. The name in the certificate does not match the expected. 
                                  ;; WARNING: TLS, handshake failed (Error in the certificate.)
                                  ;; ERROR: failed to query server 1.1.1.1@853(TCP)
                                  root@NewUC:/home/user#
                                  

                                  if I use correct hostname, see the below openssl output to what all the valid SANs are in that cert

                                  root@NewUC:/home/user# kdig -d @1.1.1.1 www.google.com +tls-ca +tls-host=one.one.one.one
                                  ;; DEBUG: Querying for owner(www.google.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
                                  ;; DEBUG: TLS, imported 124 system certificates
                                  ;; DEBUG: TLS, received certificate hierarchy:
                                  ;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
                                  ;; DEBUG:      SHA-256 PIN: MnLdGiqUGYhtyinlrGTC4FZdDyDXv4NOWFGnXW3ur14=
                                  ;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
                                  ;; DEBUG:      SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM=
                                  ;; DEBUG: TLS, skipping certificate PIN check
                                  ;; DEBUG: TLS, The certificate is trusted. 
                                  ;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
                                  ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 62622
                                  ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
                                  
                                  ;; EDNS PSEUDOSECTION:
                                  ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
                                  ;; PADDING: 405 B
                                  
                                  ;; QUESTION SECTION:
                                  ;; www.google.com.              IN      A
                                  
                                  ;; ANSWER SECTION:
                                  www.google.com.         289     IN      A       142.250.190.4
                                  
                                  ;; Received 468 B
                                  ;; Time 2023-01-09 13:14:10 CST
                                  ;; From 1.1.1.1@853(TCP) in 63.2 ms
                                  root@NewUC:/home/user# 
                                  

                                  As to your log - seems it pretty clear to why its refusing you, that "::/128 refused" where that is coming from not sure.. But that would explain why its refusing you.

                                  root@NewUC:/home/user# openssl s_client -connect 1.1.1.1:853 </dev/null 2>/dev/null | openssl x509 -noout -text
                                  Certificate:
                                      Data:
                                          Version: 3 (0x2)
                                          Serial Number:
                                              0d:1c:7a:f2:8e:5f:27:17:db:b2:7f:41:08:20:bd:f7
                                          Signature Algorithm: ecdsa-with-SHA384
                                          Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1
                                          Validity
                                              Not Before: Sep 13 00:00:00 2022 GMT
                                              Not After : Sep 13 23:59:59 2023 GMT
                                          Subject: C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
                                          Subject Public Key Info:
                                              Public Key Algorithm: id-ecPublicKey
                                                  Public-Key: (256 bit)
                                                  pub:
                                                      04:fc:3e:51:ef:74:1d:c6:da:78:ba:ae:a5:8a:4a:
                                                      dd:d9:0b:e6:e2:5b:57:31:57:de:d3:bf:b6:d9:8a:
                                                      3b:4f:d2:54:54:88:cf:bd:2e:65:e7:66:eb:c5:df:
                                                      d0:31:54:52:a7:2c:ee:12:86:a3:9a:66:c1:ea:06:
                                                      79:03:ba:1b:f0
                                                  ASN1 OID: prime256v1
                                                  NIST CURVE: P-256
                                          X509v3 extensions:
                                              X509v3 Authority Key Identifier: 
                                                  0A:BC:08:29:17:8C:A5:39:6D:7A:0E:CE:33:C7:2E:B3:ED:FB:C3:7A
                                              X509v3 Subject Key Identifier: 
                                                  D2:63:BA:94:D6:54:7F:4C:85:14:08:3A:1C:85:56:29:EF:59:8F:CC
                                              X509v3 Subject Alternative Name: 
                                                  DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, DNS:one.one.one.one, IP Address:1.0.0.1, IP Address:1.1.1.1, IP Address:162.159.36.1, IP Address:162.159.46.1, IP Address:2606:4700:4700:0:0:0:0:1001, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400
                                              X509v3 Key Usage: critical
                                                  Digital Signature
                                              X509v3 Extended Key Usage: 
                                                  TLS Web Server Authentication, TLS Web Client Authentication
                                              X509v3 CRL Distribution Points: 
                                                  Full Name:
                                                    URI:http://crl3.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl
                                                  Full Name:
                                                    URI:http://crl4.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl
                                              X509v3 Certificate Policies: 
                                                  Policy: 2.23.140.1.2.2
                                                    CPS: http://www.digicert.com/CPS
                                              Authority Information Access: 
                                                  OCSP - URI:http://ocsp.digicert.com
                                                  CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt
                                              X509v3 Basic Constraints: 
                                                  CA:FALSE
                                              CT Precertificate SCTs: 
                                                  Signed Certificate Timestamp:
                                                      Version   : v1 (0x0)
                                                      Log ID    : E8:3E:D0:DA:3E:F5:06:35:32:E7:57:28:BC:89:6B:C9:
                                                                  03:D3:CB:D1:11:6B:EC:EB:69:E1:77:7D:6D:06:BD:6E
                                                      Timestamp : Sep 13 22:48:42.079 2022 GMT
                                                      Extensions: none
                                                      Signature : ecdsa-with-SHA256
                                                                  30:44:02:20:13:E1:7D:A3:DD:99:5A:FF:0B:9F:41:A7:
                                                                  37:EA:F3:4D:82:23:03:09:43:DD:AC:2D:C8:9C:C8:4E:
                                                                  3C:34:32:F7:02:20:35:1A:CE:22:F9:06:48:3D:8D:0D:
                                                                  C9:EB:9D:6C:92:C2:03:BA:59:D6:94:EE:8F:71:38:E8:
                                                                  26:00:12:76:48:0F
                                                  Signed Certificate Timestamp:
                                                      Version   : v1 (0x0)
                                                      Log ID    : 35:CF:19:1B:BF:B1:6C:57:BF:0F:AD:4C:6D:42:CB:BB:
                                                                  B6:27:20:26:51:EA:3F:E1:2A:EF:A8:03:C3:3B:D6:4C
                                                      Timestamp : Sep 13 22:48:42.151 2022 GMT
                                                      Extensions: none
                                                      Signature : ecdsa-with-SHA256
                                                                  30:46:02:21:00:A2:B6:45:5D:DE:32:F8:03:3C:9C:BD:
                                                                  5F:49:1B:8B:79:1B:FB:39:68:73:53:43:83:4E:77:8A:
                                                                  37:D2:56:76:E2:02:21:00:84:92:F2:CA:5E:AB:16:F4:
                                                                  50:EC:8D:95:F0:84:36:B0:A8:99:B8:75:05:9E:A0:4A:
                                                                  F7:C2:16:F6:8E:23:1C:4F
                                                  Signed Certificate Timestamp:
                                                      Version   : v1 (0x0)
                                                      Log ID    : B3:73:77:07:E1:84:50:F8:63:86:D6:05:A9:DC:11:09:
                                                                  4A:79:2D:B1:67:0C:0B:87:DC:F0:03:0E:79:36:A5:9A
                                                      Timestamp : Sep 13 22:48:42.231 2022 GMT
                                                      Extensions: none
                                                      Signature : ecdsa-with-SHA256
                                                                  30:45:02:21:00:9A:01:8C:AF:2F:41:72:8B:57:0B:1C:
                                                                  1C:07:90:22:B1:C3:D7:FE:80:BB:FB:D2:B5:AA:CE:60:
                                                                  5F:0F:62:0E:DF:02:20:0A:8C:4B:CE:DB:26:DF:B8:5E:
                                                                  67:D6:9E:68:7C:CE:C4:D4:15:9A:53:3B:80:1F:07:F6:
                                                                  6B:80:6B:07:18:86:A0
                                      Signature Algorithm: ecdsa-with-SHA384
                                      Signature Value:
                                          30:65:02:30:19:d7:9a:79:6e:69:cc:19:6f:dd:c3:d0:36:c8:
                                          54:d0:4e:f4:6f:1d:46:c0:ca:2f:fb:22:19:95:f8:70:75:0b:
                                          59:d9:ad:16:31:6e:1a:26:1b:16:df:71:0d:55:cd:4a:02:31:
                                          00:ea:dc:2e:09:98:fe:b1:fb:07:f5:31:5f:b6:7c:1a:be:38:
                                          d9:c5:39:9a:6a:0b:9d:8f:54:67:13:4b:c1:12:86:26:2a:11:
                                          6d:98:d3:91:1d:02:eb:e1:77:76:71:37:8e
                                  root@NewUC:/home/user# 
                                  

                                  If you don't want to look through all that, the important info from the cert is this

                                  X509v3 Subject Alternative Name:
                                  DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, DNS:one.one.one.one, IP Address:1.0.0.1, IP Address:1.1.1.1, IP Address:162.159.36.1, IP Address:162.159.46.1, IP Address:2606:4700:4700:0:0:0:0:1001, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400

                                  big fan of dig, and use it pretty much everyday - but kdig is much better with working with dot and or doh. And with anything cert related use of openssl is your go to tool.

                                  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.7.2, 24.11

                                  C 1 Reply Last reply Reply Quote 0
                                  • C
                                    cursixx @johnpoz
                                    last edited by

                                    I did a factory reset of my config and set my WAN and LAN interfaces (dev 2.7 1/9). Never even logged in and I'm still getting query refused with ipv6. I just wanted to rule out any of my config changes as the issue.

                                    Then I loaded a clean install of stable 2.6 and it seems to be working as expected

                                    1 Reply Last reply Reply Quote 1
                                    • C cursixx referenced this topic on
                                    • Bob.DigB
                                      Bob.Dig LAYER 8 @marcosm
                                      last edited by

                                      @marcosm I can confirm this bug for 23.01.r.20230202.1645 too. At least for ULAs.

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

                                        I still can't reproduce this here. Fresh install, DHCPv6 WAN / Track6 LAN, it boots up and has the prefix for LAN allowed in Unbound, and a client on LAN gets an address and can query it properly.

                                        If that doesn't work I suggest first checking your WAN to make sure you have the correct settings there for DHCPv6 (especially the delegation size), and check to see what is present on the LAN interface(s) and in /var/unbound/access_lists.conf.

                                        There could be some kind of timing issue where the address gets added to LAN but unbound doesn't reload after that, but I'm not aware of anything that would have changed in that scenario specifically.

                                        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 1 Reply Last reply Reply Quote 0
                                        • W
                                          watkins13
                                          last edited by watkins13

                                          I seem to be running into this REFUSED query response issue as well—or at the least a very similar issue—on the current pfSense Plus 23.01-RC build running on my Netgate 6100.

                                          Refused IPv6 query output:

                                          Arashi ~ % dig @2600:1700:2320:5fcf:92ec:77ff:fe21:3f06 dns.google. AAAA
                                          
                                          ; <<>> DiG 9.10.6 <<>> @2600:1700:2320:5fcf:92ec:77ff:fe21:3f06 dns.google. AAAA
                                          ; (1 server found)
                                          ;; global options: +cmd
                                          ;; Got answer:
                                          ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 46011
                                          ;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
                                          ;; WARNING: recursion requested but not available
                                          
                                          ;; Query time: 57 msec
                                          ;; SERVER: 2600:1700:2320:5fcf:92ec:77ff:fe21:3f06#53(2600:1700:2320:5fcf:92ec:77ff:fe21:3f06)
                                          ;; WHEN: Mon Feb 13 13:26:40 PST 2023
                                          ;; MSG SIZE  rcvd: 12
                                          
                                          

                                          Working IPv4 query output:

                                          Arashi ~ % dig @10.13.1.1 dns.google. AAAA
                                          
                                          ; <<>> DiG 9.10.6 <<>> @10.13.1.1 dns.google. AAAA
                                          ; (1 server found)
                                          ;; global options: +cmd
                                          ;; Got answer:
                                          ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46994
                                          ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
                                          
                                          ;; OPT PSEUDOSECTION:
                                          ; EDNS: version: 0, flags:; udp: 1432
                                          ;; QUESTION SECTION:
                                          ;dns.google.			IN	AAAA
                                          
                                          ;; ANSWER SECTION:
                                          dns.google.		900	IN	AAAA	2001:4860:4860::8844
                                          dns.google.		900	IN	AAAA	2001:4860:4860::8888
                                          
                                          ;; Query time: 484 msec
                                          ;; SERVER: 10.13.1.1#53(10.13.1.1)
                                          ;; WHEN: Mon Feb 13 13:18:02 PST 2023
                                          ;; MSG SIZE  rcvd: 95
                                          
                                          

                                          From what I can tell so far, the issue seems to be that expected access-control lines for the LAN interface are not auto-added the lines for the IPv6 parts of the LAN interface and only generating access-control entries for the IPv4 LAN network.

                                          IPv4 queries function as expected on the LAN, and IPv6 DNS queries on the LAN interface are answered with a REFUSED status. I checked to see confirm that IPv6 DNS packets were reaching the router past the firewall rules. I further confirmed that by adding in an explicit firewall rule to allow it at the top of the LAN list to confirm that again.

                                          uname -v output:

                                          FreeBSD 14.0-CURRENT #0 plus-RELENG_23_01-n256016-ee43ebe4124: Wed Feb  8 14:43:16 UTC 2023     root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_01-main/obj/amd64/B5BT22YU/var/jenkins/workspace/pfSense-Plus-snapshots-23_01-main/sources/FreeBSD-src-plus-RELENG_23_01/amd64.amd64/sys/pfSense
                                          

                                          Current pfSense settings:

                                          1. My WAN interface is using DHCP6 for IPv6, and my LAN is in the Track Interface type with WAN set as the IPv6 Interface to track.
                                          2. The Disable Auto-added Access Control for the DNS Resolver is not checked.
                                          3. The DNS Resolver (unbound) daemon is configured to listen on ALL interfaces.
                                          4. DHCPv6 Server is enabled on the LAN with a delegated prefix length of 64, and the Router Advertisements mode is set to Assisted and Use same settings as DHCPv6 server is enabled/checked.
                                          5. Looking at the generated /var/unbound/access_lists.conf file, it appears to have only generated IPv4 access-control lines. I do not see any lines for the LAN IPv6 delegated prefix.
                                          [23.01-RC][root@pfSense-ng6100.home.arpa]/root: netstat -an | grep -E '\.53\b'
                                          tcp4       0      0 *.53                   *.*                    LISTEN     
                                          tcp6       0      0 *.53                   *.*                    LISTEN     
                                          udp4       0      0 *.53                   *.*                    
                                          udp6       0      0 *.53                   *.*                    
                                          
                                          [23.01-RC][root@pfSense-ng6100.home.arpa]/root: cat /var/unbound/access_lists.conf
                                          access-control: 127.0.0.1/32 allow_snoop
                                          access-control: ::1 allow_snoop
                                          access-control: 10.13.1.0/24 allow
                                          access-control: 127.0.0.0/8 allow
                                          access-control: ::1/128 allow
                                          
                                          W 1 Reply Last reply Reply Quote 0
                                          • W
                                            watkins13 @watkins13
                                            last edited by

                                            @jimp

                                            Is there a way I can enable/view logs for the generated auto-added access control items?

                                            For now, I can workaround the missing IPv6 access-control lines for the DNS access lists by adding a custom Allow access list entry in the DNS Resolver settings to cover my current /64 LAN delegated prefix, but that workaround is brittle and would break if my delegated prefix changes at any point.

                                            [23.01-RC][root@pfSense-ng6100.home.arpa]/root: cat /var/unbound/access_lists.conf
                                            access-control: 127.0.0.1/32 allow_snoop
                                            access-control: ::1 allow_snoop
                                            access-control: 10.13.1.0/24 allow 
                                            access-control: 127.0.0.0/8 allow 
                                            access-control: ::1/128 allow 
                                            #Custom IPv6 Allow Workaround
                                            access-control: 2600:1700:2320:5fcf::/64 allow
                                            

                                            Working query with workaround:

                                            Arashi ~ % dig @2600:1700:2320:5fcf:92ec:77ff:fe21:3f06 dns.google. AAAA
                                            
                                            ; <<>> DiG 9.10.6 <<>> @2600:1700:2320:5fcf:92ec:77ff:fe21:3f06 dns.google. AAAA
                                            ; (1 server found)
                                            ;; global options: +cmd
                                            ;; Got answer:
                                            ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6924
                                            ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
                                            
                                            ;; OPT PSEUDOSECTION:
                                            ; EDNS: version: 0, flags:; udp: 1432
                                            ;; QUESTION SECTION:
                                            ;dns.google.			IN	AAAA
                                            
                                            ;; ANSWER SECTION:
                                            dns.google.		900	IN	AAAA	2001:4860:4860::8844
                                            dns.google.		900	IN	AAAA	2001:4860:4860::8888
                                            
                                            ;; Query time: 378 msec
                                            ;; SERVER: 2600:1700:2320:5fcf:92ec:77ff:fe21:3f06#53(2600:1700:2320:5fcf:92ec:77ff:fe21:3f06)
                                            ;; WHEN: Mon Feb 13 13:31:02 PST 2023
                                            ;; MSG SIZE  rcvd: 95
                                            
                                            
                                            1 Reply Last reply Reply Quote 0
                                            • Bob.DigB Bob.Dig referenced this topic on
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.