[SOLVED] Weird DNS Problem
-
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
-
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 127Rules are
IPv4 TCP/UDP LAN * This Firewall DNS, VPN Gateway
** if i change the gateway to default, the results are the samethe 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
-
@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?
-
Well try dig @pfSense_interface and see how that changes between modes.
Steve
-
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
-
Sorry I meant to imply:
dig @192.168.20.5 download-c.huawei.com
-
@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
-
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
-
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
-
@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. -
@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.
-
@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.
-
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
-
@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
-
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
-
@stephenw10 nope. nothing blocked in relation to 53 or 853
-
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-4Now 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.....
-
This seems unrelated, it should be in a new thread.
Please start a new topic and I'll moved these posts across.
Steve
-
Thanks Steve. I have opened a new topic here: link text