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

    [SOLVED] Weird DNS Problem

    Scheduled Pinned Locked Moved General pfSense Questions
    34 Posts 6 Posters 10.9k 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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      Mmm, well that's fun!

      Check the Unbound logs when that fails. Might need to turn up the logging.
      Do you see any DNS traffic blocked anywhere?

      Steve

      4 2 Replies Last reply Reply Quote 0
      • 4
        4o4rh @stephenw10
        last edited by

        Lot of stuff means nothing to me.... port 53 shows pass for both source and destination ports

        Mar 3 19:38:32 	unbound 	47057:3 	debug: close fd 46
Mar 3 19:38:32 	unbound 	47057:3 	debug: close of port 27742
Mar 3 19:38:32 	unbound 	47057:3 	debug: comm point start listening 47
Mar 3 19:38:32 	unbound 	47057:3 	debug: opened UDP if=0 port=57612
Mar 3 19:38:32 	unbound 	47057:3 	debug: inserted new pending reply id=f6d7
Mar 3 19:38:32 	unbound 	47057:3 	debug: serviced query UDP timeout=752 msec
Mar 3 19:38:32 	unbound 	47057:3 	debug: EDNS lookup known=0 vs=0
Mar 3 19:38:32 	unbound 	47057:3 	debug: try edns1xx0 <ns1.hwclouds-dns.net.> 139.159.208.43#53
Mar 3 19:38:32 	unbound 	47057:3 	debug: timeout udp
Mar 3 19:38:32 	unbound 	47057:3 	debug: close fd 47
Mar 3 19:38:32 	unbound 	47057:3 	debug: close of port 58861
Mar 3 19:38:32 	unbound 	47057:3 	debug: comm point start listening 45
Mar 3 19:38:32 	unbound 	47057:3 	debug: opened UDP if=0 port=29679
Mar 3 19:38:32 	unbound 	47057:3 	debug: inserted new pending reply id=ef89
Mar 3 19:38:32 	unbound 	47057:3 	debug: serviced query UDP timeout=752 msec
Mar 3 19:38:32 	unbound 	47057:3 	debug: EDNS lookup known=0 vs=0
Mar 3 19:38:32 	unbound 	47057:3 	debug: try edns1xx0 <download-c.huawei.com.c.cdnhwc1.com.> 122.112.208.53#53
Mar 3 19:38:32 	unbound 	47057:3 	debug: timeout udp
Mar 3 19:38:31 	unbound 	47057:3 	debug: close fd 45
Mar 3 19:38:31 	unbound 	47057:3 	debug: close of port 45220
Mar 3 19:38:31 	unbound 	47057:3 	debug: svcd callbacks end
Mar 3 19:38:31 	unbound 	47057:3 	debug: cache memory msg=78665 rrset=134977 infra=24276 val=74535
Mar 3 19:38:31 	unbound 	47057:3 	info: 1RDdc mod1 rep download-c.huawei.com. A IN
        1 Reply Last reply Reply Quote 0
        • 4
          4o4rh @stephenw10
          last edited by 4o4rh

          @stephenw10 i have a further update.
          In the DNS Resolver, i had only the VPN enable for outgoing requests.
          If i include the WAN for outgoing requests, it works.
          But this defeats the purpose. I want to be sure the traffic can only go via the VPN.

          FFS...this 2.4.4 update has cost me so much time, when everything was working prior to it and no change of a rollback - which i would have already done days ago.

          1. If i add the WAN to the outgoing interface, DNSLeakTest pulls my ISP IP address, but all lookups work
          2. If i remove the WAN from the outgoing interface, DNSLeakTest only finds my VPN provider (but not my VPN address) but then i don't have all the routing e.g. the huawei address in this discussion.
          3. if i remove the WAN from the outgoing interface and use forwarding, DNSLeakTest only find my VPN provider (but not my VPN address) and all lookups work.

          for me, this has simply cost too much time.
          It is clear, the only option to go with is forwarding to Quad9/Cloudflare in the absence of a working DNS Resolver.

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

            @johnpoz said in [SOLVED] Weird DNS Problem:

            What a cluster of cnames

            ;; QUESTION SECTION:
;download-c.huawei.com.         IN      A

;; ANSWER SECTION:
download-c.huawei.com.  3598    IN      CNAME   download-c.huawei.com.c.cdnhwc1.com.
download-c.huawei.com.c.cdnhwc1.com. 3600 IN CNAME download-c.huawei.com.wscdns.com.
download-c.huawei.com.wscdns.com. 3600 IN CNAME dp6opavwln80.cloudfront.net.

            But not having any problems resolving that with unbound

            They have a HUGE mess!!
            http://dnsviz.net/d/download-c.huawei.com/dnssec/

            0_1551617424186_mess.png

            Thanks !
            👍 👍 👍

            I hope this "huawei" company doesn't include a lot of Internet usage in their business model. Because if they do, they have a problem.

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

            4 1 Reply Last reply Reply Quote 1
            • 4
              4o4rh @Gertjan
              last edited by 4o4rh

              @gertjan is the problem here, solving Huawei software update portal, or solving the problem with pfsense and unbound not being able to resolve all sites in resolver mode. I currently have to use forwarding mode as the only way to ensure all traffic goes over the VPN and all sites can work.

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

                Do you actually see port 53 traffic leaving over the VPN when it's seemingly getting no response there? In a packet capture?

                Are there actually any responses?

                Steve

                4 1 Reply Last reply Reply Quote 0
                • 4
                  4o4rh @stephenw10
                  last edited by 4o4rh

                  @stephenw10 when the WAN is enabled as an outgoing interface (it works - and clearly goes out the wan)

                  192.168.0.234.52023 > 139.159.208.46.53: [udp sum ok] 31124% [1au] A? download-c.huawei.com.c.cdnhwc1.com. ar: . OPT UDPsize=1472 DO (64)
13:51:33.971911 34:2c:c4:11:12:b4 > 00:ab:ba:22:15:4c, ethertype IPv4 (0x0800), length 149: (tos 0x0, ttl 236, id 24993, offset 0, flags [none], proto UDP (17), length 135)
    139.159.208.46.53 > 192.168.0.234.52023: [udp sum ok] 31124*- q: A? download-c.huawei.com.c.cdnhwc1.com. 1/0/1 download-c.huawei.com.c.cdnhwc1.com. CNAME download-c.huawei.com.wscdns.com. ar: . OPT UDPsize=1472 DO (107)
13:51:33.972152 00:ab:ba:22:15:4c > 34:2c:c4:11:12:b4, ethertype IPv4 (0x0800), length 81: (tos 0x0, ttl 64, id 52665, offset 0, flags [none], proto UDP (17), length 67)

                  When the wan is disabled as an outgoing interface, i get the below on the VPN interface

                  (64)
13:57:06.359345 AF IPv4 (2), length 139: (tos 0x0, ttl 241, id 59054, offset 0, flags [none], proto UDP (17), length 135)
    159.138.17.59.53 > 10.64.0.122.22038: [udp sum ok] 11628*- q: A? download-c.huawei.com.c.cdnhwc1.com. 1/0/1 download-c.huawei.com.c.cdnhwc1.com. CNAME download-c.huawei.com.wscdns.com. ar: . OPT UDPsize=4096 DO (107)
13:57:06.359770 AF IPv4 (2), length 71: (tos 0x0, ttl 64, id 29014, offset 0, flags [none], proto UDP (17), length 67)
    10.64.0.122.55777 > 192.5.6.30.53: [udp sum ok] 52730% [1au] A? wscdns.com. ar: . OPT UDPsize=4096 DO (39)
13:57:06.382731 AF IPv4 (2), length 672: (tos 0x0, ttl 53, id 58872, offset 0, flags [none], proto UDP (17), length 668)
    192.5.6.30.53 > 10.64.0.122.55777: [udp sum ok] 52730- q: A? wscdns.com. 0/9/1 ns: wscdns.com. NS dns2.wscdns.info., wscdns.com. NS dns4.wscdns.info., wscdns.com. NS dns1.wscdns.org., wscdns.com. NS dns3.wscdns.org., wscdns.com. NS dns5.wscdns.org., CK0POJMG874LJREF7EFN8430QVIT8BSM.com. Type50, CK0POJMG874LJREF7EFN8430QVIT8BSM.com. RRSIG, RCDUE08JKJECE4UVVUUU7AUF8IBGKA4U.com. Type50, RCDUE08JKJECE4UVVUUU7AUF8IBGKA4U.com. RRSIG ar: . OPT UDPsize=4096 DO (640)

                  One thing i notice on the firewall logs, the request goes to both LAN addresses and the localhost.
                  Is that correct?

                  Mar 4 14:19:03 	GREEN 	Pass GREEN DNS to Firewall (1551369636) 	192.168.20.49:42006		192.168.21.5:53		UDP
	Mar 4 14:18:55 	GREEN 	Pass GREEN DNS to Firewall (1551369636) 	192.168.20.49:52424		192.168.20.5:53		UDP
	Mar 4 14:18:36 	GREEN 	Pass GREEN DNS to Firewall (1551369636) 	192.168.20.49:60957		127.0.0.1:53		UDP
                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Those are firewall logs on the client? I imagine that's checking local host data in addition to resolving against Unbound.

                    Hmm, certainly seems to be getting a response in that pcap. Nothing shown blocked in the firewall logs I assume?

                    Steve

                    4 1 Reply Last reply Reply Quote 0
                    • 4
                      4o4rh @stephenw10
                      last edited by

                      @stephenw10 nope. nothing blocked in relation to 53 or 853

                      1 Reply Last reply Reply Quote 0
                      • 4
                        4o4rh
                        last edited by 4o4rh

                        fixed almost all of the problems i have been having with the following expressvpn config
                        https://forum.netgate.com/topic/140931/expressvpn-down-on-pfsense-2-4-4

                        Now have DNS Resolver working as it should
                        i.e. without forwarding, without going over WAN and resolving download-c.huawei.com
                        packet trace on WAN shows only 1195 traffic.

                        Both Expressvpn interfaces are up in fail-over, everything is working except one thing.......

                        Linux Mint clients.
                        Most of the mirrors are unavailable or have super slow speeds.
                        This does not appear to be a problem if only one ExpressVPN interface is used.

                        from main tessa mirrors, there are less than 10 and none connectable.
                        from the base bionic mirrors, there are also much less and most have unreachable.

                        so still something not quite right.....

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

                          This seems unrelated, it should be in a new thread.

                          Please start a new topic and I'll moved these posts across.

                          Steve

                          1 Reply Last reply Reply Quote 0
                          • V
                            vjizzle
                            last edited by

                            Thanks Steve. I have opened a new topic here: link text

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