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.
    • 4
      4o4rh @johnpoz
      last edited by

      @johnpoz i have IPv6 disabled on everything inc my clients

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

        so do either a debug on nslookp or grab dig and do a trace and see what is failing or just getting there?

        If I click what you posted I get

        Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

For online documentation and support please refer to nginx.org.
Commercial support is available at nginx.com.

Thank you for using nginx.

        So have no idea what you think is suppose to be there or what is suppose to get there?

        edit:
        Not sure what his issue was.. He rule to any to wan wouldn't of even allowed internet at all, etc. His domain resolved just fine as well - but again a nightmare of errors... cname mess as well

        Maybe he had qminimization on? Have no idea with the lack of info given.

        If pfsense resolves it fine, and client asks pfsense then pfsense will hand to client what it got... If you want help in finding your issue going to have to give a bit more than client can not resolve.. For all we know your clients using some proxy, etc. Do you get a time out from pfsense? Do you get a NX, etc. 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.8, 24.11

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

          Ha, seems legit! 🙄

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

            Yeah that any legit company would have such a NIGHTMARE MESS for their dns is just SAD!!!

            But it does resolve - so without some more info.. there is nothing can tell you. On what your actual issue might or might not be?

            You sure your pointing pfsense to itself.. See it all the time where clients point pfsense to some external when they are running resolver.. When you resolve you might have issue resolving if you can not actually talk to the NS for the domain, and with so many cnames your going to have to talk to many NS ;) failure or time out to any one of them in that chain could cause you grief in resolving.

            Do a simple +trace to see where you might be having issue.

            Here is trace - but its only 1st leg, since there are 2 more cnames!! Arrrggh

            $ dig download-c.huawei.com +trace                                                                                 
                                                                                                                   
; <<>> DiG 9.12.3-P1 <<>> download-c.huawei.com +trace                                                             
;; global options: +cmd                                                                                            
.                       450361  IN      NS      d.root-servers.net.                                                
.                       450361  IN      NS      k.root-servers.net.                                                
.                       450361  IN      NS      j.root-servers.net.                                                
.                       450361  IN      NS      l.root-servers.net.                                                
.                       450361  IN      NS      c.root-servers.net.                                                
.                       450361  IN      NS      f.root-servers.net.                                                
.                       450361  IN      NS      a.root-servers.net.                                                
.                       450361  IN      NS      i.root-servers.net.                                                
.                       450361  IN      NS      e.root-servers.net.                                                
.                       450361  IN      NS      m.root-servers.net.                                                
.                       450361  IN      NS      h.root-servers.net.                                                
.                       450361  IN      NS      g.root-servers.net.                                                
.                       450361  IN      NS      b.root-servers.net.                                                
.                       450361  IN      RRSIG   NS 8 0 518400 20190315140000 20190302130000 16749 . ShqK2j6F+OJAQI+
sTMG6oms moskB4VtcKYv+CwtAxmuWDnVAVJz35hcj4rkdXBv6Wz423JmuesZsl4j SUMl4xFUT42faNiHG/OZybi+uxwXSggIrQHhM9kg9WlamZ+Y+
5/i+ifoWJGMUZOXp0SIkJJGXHeFI2P2 vfReHTB6/QUQNMFPHGjMhvM37AFruXs0vktZWZ9aAjj+uXvA0kvgZYIO SKcRsbULeCQNlnvSncTZFCM+YE
phwQ==                                                                                                             
;; Received 525 bytes from 192.168.3.10#53(192.168.3.10) in 3 ms                                                   
                                                                                                                   
com.                    172800  IN      NS      a.gtld-servers.net.                                                
com.                    172800  IN      NS      b.gtld-servers.net.                                                
com.                    172800  IN      NS      c.gtld-servers.net.                                                
com.                    172800  IN      NS      d.gtld-servers.net.                                                
com.                    172800  IN      NS      e.gtld-servers.net.                                                
com.                    172800  IN      NS      f.gtld-servers.net.                                                
com.                    172800  IN      NS      g.gtld-servers.net.                                                
com.                    172800  IN      NS      h.gtld-servers.net.                                                
com.                    172800  IN      NS      i.gtld-servers.net.                                                
com.                    172800  IN      NS      j.gtld-servers.net.                                                
com.                    172800  IN      NS      k.gtld-servers.net.                                                
com.                    172800  IN      NS      l.gtld-servers.net.                                                
com.                    172800  IN      NS      m.gtld-servers.net.                                                
com.                    86400   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF 
com.                    86400   IN      RRSIG   DS 8 1 86400 20190316050000 20190303040000 16749 . FqDz8iA8R/26+mJO
5vVsdnr XEiNTUA+aO8xsAEzNfctse3SY7XLmTnMI4o/YgL4cfwLnQeUR+7fF1qj +pUvL5H+qXk3NRRWFkDhtYoaBEo4Vgg9yjZN2bSWThBelY/QD5
yWzrR5yLJfknD9OhewaHp120kCWxkn m0YnRtiZ0xUjlNm1IcmAv9CuliXTyMCTU41VqCFXfjFIoKRyVnEIMUos Q+wJ9gk1XRM4LUI3T+1+Jcobftk
3pA==                                                                                                              
;; Received 1181 bytes from 198.97.190.53#53(h.root-servers.net) in 35 ms                                          
                                                                                                                   
huawei.com.             172800  IN      NS      nsallsec.huawei.com.                                               
huawei.com.             172800  IN      NS      nsall.huawei.com.                                                  
huawei.com.             172800  IN      NS      nsall3rd.huawei.com.                                               
huawei.com.             172800  IN      NS      nsall4th.huawei.com.                                               
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY N
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20190308054542 20190301043542 16883 com. FgR1J
rnGB/qZQvAwOFwglFi sfO86z794cvm/6B4zzRDMFDLJKvhPyvYblmRCUCj2iMgZVksTqxDYbGR 2/2MFK9HwQpGr79itYpKMexrS1duvbogm/xNgiL
96PTCKH6PDT3DG589UG3MN0NA6LG5MTJ.com. 86400 IN NSEC3 1 1 0 - 96PU6P2QEB574VGKGIUQGM47GT2D04SQ NS DS RRSIG          
96PTCKH6PDT3DG589UG3MN0NA6LG5MTJ.com. 86400 IN RRSIG NSEC3 8 2 86400 20190309063008 20190302052008 16883 com. g36Vi
BL3b29EVq9rNyutbGT qdpfOBgD5JHsZHDf76qb0cKd7p+nzjee2UAFhd0Z5EgvRUv+3s0PM6qq evdbQx4tQA56b6NwLqipwe7SUduKpIhqAF7P0CY
;; Received 720 bytes from 192.35.51.30#53(f.gtld-servers.net) in 30 ms                                            
                                                                                                                   
download-c.huawei.com.  600     IN      CNAME   download-c.huawei.com.c.cdnhwc1.com.                               
;; Received 96 bytes from 122.96.104.66#53(nsall4th.huawei.com) in 255 ms

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

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

              the huawei site is the download site for their windows application that HiSuite that connects their phones.

              this is what i get on my linux client, with DNS forwarding enabled.

              nslookup download-c.huawei.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
download-c.huawei.com	canonical name = download-c.huawei.com.c.cdnhwc1.com.
download-c.huawei.com.c.cdnhwc1.com	canonical name = download-c.huawei.com.wscdns.com.
download-c.huawei.com.wscdns.com	canonical name = dp6opavwln80.cloudfront.net.
Name:	dp6opavwln80.cloudfront.net
Address: 143.204.208.172
Name:	dp6opavwln80.cloudfront.net
Address: 143.204.208.221
Name:	dp6opavwln80.cloudfront.net
Address: 143.204.208.117
Name:	dp6opavwln80.cloudfront.net
Address: 143.204.208.36

              this is what i get, if i uncheck DNS forwarding and no other changes.

              nslookup download-c.huawei.com
;; connection timed out; no servers could be reached

              to be clear, with forwarding unchecked, straight after the previous nslookup, i do a google and is ok.

              nslookup google.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	google.com
Address: 172.217.17.110
Name:	google.com
Address: 2a00:1450:400e:806::200e
              1 Reply Last reply Reply Quote 0
              • 4
                4o4rh
                last edited by 4o4rh

                @johnpoz said in [SOLVED] Weird DNS Problem:

                dig download-c.huawei.com +trace

                using your command, this is what i get with forwarding unchecked

                dig download-c.huawei.com +trace

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> download-c.huawei.com +trace
;; global options: +cmd
;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 m

                this is the result with forwarding checked, and i note the result is the same.

                dig download-c.huawei.com +trace

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> download-c.huawei.com +trace
;; global options: +cmd
;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0

                probably need some help from you with the commands, to do any deeper analysis. but seems very odd to me, that the nslookup fails simply by changing the forwarding mode

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

                  You seem to be testing against localhost. What do you have running on the client? How is that configured?

                  What do you see if you test against the pfSense interface IP?

                  Steve

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

                    that is what it returns. both the windows and linux clients are DHCP with the gateway pointing to the LAN interface address. for the DNS, the linux points to the LAN interface address and for windows, it has static comodo firewall servers defined.

                    on the pfsense box

                    NAT is
                    LAN UDP * * !LOCAL DNS 127.0.0.1 DNS
                    ** it didn't work at all when i used the LAN interface for the NAT IP. It only works if i use 127

                    Rules are
                    IPv4 TCP/UDP LAN * This Firewall DNS, VPN Gateway
                    ** if i change the gateway to default, the results are the same

                    the only thing strange i notice on the windows client, (forwarding enabled)

                    nslookup download-c.huawei.com
Server:  UnKnown
Address:  156.154.70.22

Non-authoritative answer:
Name:    dp6opavwln80.cloudfront.net
Addresses:  143.204.98.14
          143.204.98.132
          143.204.98.156
          143.204.98.173
Aliases:  download-c.huawei.com
          download-c.huawei.com.c.cdnhwc1.com
          download-c.huawei.com.wscdns.com

                    forwarding disabled

                    nslookup download-c.huawei.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  156.154.70.22

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

                    in both cases, windows says server unknown...not sure if that is normal

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

                      @johnpoz said in [SOLVED] Weird DNS Problem:

                      Server: pi-hole.local.lan
                      I see in John's windows lookup above, he gets Server: pi-hole.local.lan returned, where as mine is unknown.

                      could it be something wrong, with my NAT or Rules above?

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

                        Well try dig @pfSense_interface and see how that changes between modes.

                        Steve

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

                          this is from forwarding enabled

                          dig @192.168.20.5

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @192.168.20.5
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20423
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			463269	IN	NS	a.root-servers.net.
.			463269	IN	NS	e.root-servers.net.
.			463269	IN	NS	l.root-servers.net.
.			463269	IN	NS	i.root-servers.net.
.			463269	IN	NS	j.root-servers.net.
.			463269	IN	NS	c.root-servers.net.
.			463269	IN	NS	k.root-servers.net.
.			463269	IN	NS	b.root-servers.net.
.			463269	IN	NS	m.root-servers.net.
.			463269	IN	NS	d.root-servers.net.
.			463269	IN	NS	h.root-servers.net.
.			463269	IN	NS	g.root-servers.net.
.			463269	IN	NS	f.root-servers.net.

;; Query time: 169 msec
;; SERVER: 192.168.20.5#53(192.168.20.5)
;; WHEN: Sun Mar 03 19:15:54 CET 2019
;; MSG SIZE  rcvd: 239

                          this is forwarding disabled.

                          $ nslookup download-c.huawei.com
;; connection timed out; no servers could be reached

$ dig @192.168.20.5

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @192.168.20.5
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12658
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518383	IN	NS	a.root-servers.net.
.			518383	IN	NS	b.root-servers.net.
.			518383	IN	NS	c.root-servers.net.
.			518383	IN	NS	d.root-servers.net.
.			518383	IN	NS	e.root-servers.net.
.			518383	IN	NS	f.root-servers.net.
.			518383	IN	NS	g.root-servers.net.
.			518383	IN	NS	h.root-servers.net.
.			518383	IN	NS	i.root-servers.net.
.			518383	IN	NS	j.root-servers.net.
.			518383	IN	NS	k.root-servers.net.
.			518383	IN	NS	l.root-servers.net.
.			518383	IN	NS	m.root-servers.net.

;; Query time: 3 msec
;; SERVER: 192.168.20.5#53(192.168.20.5)
;; WHEN: Sun Mar 03 19:18:05 CET 2019
;; MSG SIZE  rcvd: 239
                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            Sorry I meant to imply: dig @192.168.20.5 download-c.huawei.com

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

                              @stephenw10 said in [SOLVED] Weird DNS Problem:

                              dig @192.168.20.5 download-c.huawei.com

                              of course, sorry...brain-dead

                              forwarding enabled

                              dig @192.168.20.5 download-c.huawei.com

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @192.168.20.5 download-c.huawei.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36586
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;download-c.huawei.com.		IN	A

;; ANSWER SECTION:
download-c.huawei.com.	586	IN	CNAME	download-c.huawei.com.c.cdnhwc1.com.
download-c.huawei.com.c.cdnhwc1.com. 50	IN CNAME download-c.huawei.com.wscdns.com.
download-c.huawei.com.wscdns.com. 590 IN CNAME	dp6opavwln80.cloudfront.net.
dp6opavwln80.cloudfront.net. 50	IN	A	143.204.98.173
dp6opavwln80.cloudfront.net. 50	IN	A	143.204.98.14
dp6opavwln80.cloudfront.net. 50	IN	A	143.204.98.132
dp6opavwln80.cloudfront.net. 50	IN	A	143.204.98.156

;; Query time: 2 msec
;; SERVER: 192.168.20.5#53(192.168.20.5)
;; WHEN: Sun Mar 03 19:28:10 CET 2019
;; MSG SIZE  rcvd: 244

                              forwarding disabled

                              dig @192.168.20.5 download-c.huawei.com

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @192.168.20.5 download-c.huawei.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
                              1 Reply Last reply Reply Quote 0
                              • 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
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.