[SOLVED] Weird DNS Problem

4o4rh

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

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

stephenw10

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

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

4o4rh

@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?

stephenw10

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

Steve

4o4rh

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

stephenw10

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

4o4rh

@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

stephenw10

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

4o4rh

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

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.

If i add the WAN to the outgoing interface, DNSLeakTest pulls my ISP IP address, but all lookups work
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.
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.

Gertjan

@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/

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.

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.

stephenw10

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

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

stephenw10

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

4o4rh

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

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.....

stephenw10

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

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

Steve