Windows 10 nslookup not working on 2.4 beta
-
I have two independent lans, one running 2.3.4, one running 2.4 beta. Both are identically configured with unbound.
I have windows 10 clients on both lans.
If I do nslookup on the 2.3.4 lan, it works properly.
If I do nslookup on the 2.4 beta lan, it fails.
Screen captures are attached.
Any idea what could be causing this?
 -
Well looks like your query was REFUSED!! So do you not have your acls setup for unbound to allow your query from where your doing the query?
-
Well looks like your query was REFUSED!! So do you not have your acls setup for unbound to allow your query from where your doing the query?
Say what?!? I have no idea what you are referring to. I compared the unbound settings on the 2.3.4 and 2.4 beta systems and I did not notice any differences. Please elaborate.
-
I am talking about the ACLs that are part of unbound - normally pfsense will auto create these for you. So either something went wrong with that or you disabled the automatic ACL creation and didn't create the acl or did it wrong.
You can see your getting REFUSED - not that it didn't answer you or timed out, or couldn't find what you were looking for (nxdomain) it REFUSED your query..
Your using ipv6, did you try via ipv4? Dig is also much better tool for debugging dns. You can install dig on windows without any issues.. It is a must have for me on any windows box ;)
What snapshot of 2.4 are you running.. I on purpose turn off the auto creation of the ACLs because I play with them all the time testing stuff, and don't want any auto created ACLs.. That is why you see my check mark disabling them, and then ACL created that allows snoop from my local networks.
-
I'm running the latest snapshot, which was built yesterday.
I have never touched any of the settings for ACLs. They are all unchecked and there is no access control list.
I wonder if there is a bug in the latest snapshot. I've never had this problem before.
There doesn't seem to be a way to choose the protocol with nslookup so I tried from a ubuntu server on the same lan. Here is the output from dig. Definitely a problem with ipv6.
root@ubuntu:~# dig -4 google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -4 google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26615 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 216.58.193.78 ;; Query time: 18 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Mon Jun 12 14:38:25 PDT 2017 ;; MSG SIZE rcvd: 55 root@ubuntu:~# dig -6 google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -6 google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7238 ;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; Query time: 0 msec ;; SERVER: 2001:a:b:e800:215:5dff:fe5c:e21e#53(2001:a:b:e800:215:5dff:fe5c:e21e) ;; WHEN: Mon Jun 12 14:38:30 PDT 2017 ;; MSG SIZE rcvd: 12Some of the dns resolver settings are attached. I tried to enable the setting you suggested. It did not result in an ACL being created and it did not change the behaviour of nslookup or dig. I was not able to access the internet after doing so, so I changed it back.
 -
I tried to create an ACL. I used the prefix/64 for the network mask. When I clicked save, there was an error, saying I should have entered an ipv6 address. Am I missing something?!?
-
Stranger by the minute. Now nslookup is working on the windows 10 pc and dig is working on the linux server. The settings are unchanged.
-
you got refused on ipv6 and worked on ipv4.
Yeah you would have to create an ACL - and yes you would have to put in your correct prefix, etc..
-
you got refused on ipv6 and worked on ipv4.
Yeah you would have to create an ACL - and yes you would have to put in your correct prefix, etc..
I don't think so. nslookup on windows and dig on llinux both just started working. I just installed dig on windows and it's working also. I have not created an ACL or changed any settings. As I said, on my 2.3.4 system, the settings are the same and it was working all along. Now the 2.4 beta system is working as well.
-
You would have to create an ACL if your not using the auto configured ACLs..
What could of happened is your IPv6 range changed and the auto acl hadn't updated for ipv6 for some reason. I am not really a fan of auto stuff like that which is why I create my own acls. And if you had any downstream networks the auto stuff wouldn't work either.
-
You would have to create an ACL if your not using the auto configured ACLs..
What could of happened is your IPv6 range changed and the auto acl hadn't updated for ipv6 for some reason. I am not really a fan of auto stuff like that which is why I create my own acls. And if you had any downstream networks the auto stuff wouldn't work either.
Okay, understood. Makes sense. Cheers.
-
More dns6 strangeness today. I updated to the latest snapshot and no difference. dns4 is okay, but dns6 is not working. I restarted unbound, but it made no difference. I'll try the ACL.
This is from a windows 10 client:
C:\Users\User\Downloads\BIND9.10.5.x64>dig google.com ; <<>> DiG 9.10.5 <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50274 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 172.217.3.174 ;; Query time: 15 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Wed Jun 14 17:46:27 Pacific Daylight Time 2017 ;; MSG SIZE rcvd: 55 C:\Users\User\Downloads\BIND9.10.5.x64>dig -6 google.com ; <<>> DiG 9.10.5 <<>> -6 google.com ;; global options: +cmd ;; connection timed out; no servers could be reached C:\Users\User\Downloads\BIND9.10.5.x64>nslookup google.com Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: google.com Address: 172.217.3.174 -
ACL made no difference. I added my ipv6 prefix::/64 and my lan subnet 192.168.1.0/24. I checked the setting to Disable Auto-added Access Control. I applied the changes. It made no difference so I restarted unbound. That also made no difference.
-
Further info. On my pfsense 2.3.4 network, the first hop of tracert -4 google is the pfsense router. Here, it's skipped. I don't recognize the address of the first hop.
C:\Users\User\Downloads\BIND9.10.5.x64>tracert -4 google.com Tracing route to google.com [172.217.3.174] over a maximum of 30 hops: 1 8 ms 8 ms 6 ms 10.31.238.1 2 9 ms 9 ms 9 ms 154.11.10.11 3 10 ms 18 ms 9 ms 72.14.220.60 4 9 ms 9 ms 8 ms 108.170.245.113 5 9 ms 9 ms 8 ms 108.170.233.159 6 10 ms 8 ms 9 ms sea15s11-in-f174.1e100.net [172.217.3.174] Trace complete. C:\Users\User\Downloads\BIND9.10.5.x64>tracert -6 google.com Tracing route to google.com [2607:f8b0:400a:808::200e] over a maximum of 30 hops: 1 2 ms 15 ms 5 ms pfSense.localdomain [2001:x:y:e800:215:5dff:fe5c:e21e] 2 15 ms 15 ms 9 ms sttlwawbgr80.bb.telus.com [2001:568:1::50a] 3 10 ms 10 ms 11 ms 2001:4860:1:1:0:354:0:4 4 9 ms 9 ms 9 ms 2001:4860:0:1041::1 5 9 ms 9 ms 8 ms 2001:4860:0:1::9bf 6 9 ms 9 ms 11 ms sea15s11-in-x0e.1e100.net [2607:f8b0:400a:808::200e] Trace complete. -
"I don't recognize the address of the first hop."
"1 8 ms 8 ms 6 ms 10.31.238.1"
8 ms for a first hop is HORRIBLE!!! this is your lan??
If you do not recognize the first hop then your network is F'd up now isnt it ;)
-
"I don't recognize the address of the first hop."
"1 8 ms 8 ms 6 ms 10.31.238.1"
8 ms for a first hop is HORRIBLE!!! this is your lan??
If you do not recognize the first hop then your network is F'd up now isnt it ;)
Yah, doh. I think it's pretty clear something is effed up, but what? I wonder if I should reinstall pfsense. There's nothing else to the network. It's virtual.
-
that has nothing to do with pfsense if 10.31.238.1 is not pfsense.. 8ms that sure is not lan latency….
-
that has nothing to do with pfsense if 10.31.238.1 is not pfsense.. 8ms that sure is not lan latency….
I checked on my 2.3.4 system. That address must be my isp. It's the second hop on my 2.3.4 system. The first hop is pfsense. I downloaded the latest 2.4 beta snapshot and installed it from scratch without restoring any config files. I had snort and openvpn installed previously, but I did not reinstall them. The particular problem of pfsense not showing up in the first hop of traceroute is gone, but there is still some strange behaviour.
Windows 10
Note, dig -6 not working.
C:\Users\User>Downloads\BIND9.10.5.x64\dig -4 google.com ; <<>> DiG 9.10.5 <<>> -4 google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39144 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 260 IN A 172.217.3.174 ;; Query time: 15 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Jun 15 14:07:11 Pacific Daylight Time 2017 ;; MSG SIZE rcvd: 55 C:\Users\User>Downloads\BIND9.10.5.x64\dig -6 google.com ; <<>> DiG 9.10.5 <<>> -6 google.com ;; global options: +cmd ;; connection timed out; no servers could be reached C:\Users\User>tracert -4 google.com Tracing route to google.com [172.217.3.174] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms pfSense.localdomain [192.168.1.1] 2 6 ms 8 ms 6 ms 10.31.238.1 3 9 ms 8 ms 10 ms 154.11.10.11 4 9 ms 9 ms 11 ms 72.14.220.60 5 11 ms 10 ms 11 ms 108.170.245.113 6 10 ms 9 ms 11 ms 108.170.233.159 7 9 ms 8 ms 9 ms sea15s11-in-f174.1e100.net [172.217.3.174] Trace complete. C:\Users\User>tracert -6 google.com Tracing route to google.com [2607:f8b0:400a:808::200e] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms pfSense.localdomain [2001:a:b:d800:215:5dff:fe5c:e21e] 2 14 ms 6 ms 5 ms node-1w7jr9n36nixrvaceajc2pstq.ipv6.telus.net [2001:569:2:f::2e] 3 10 ms 10 ms 9 ms sttlwawbgr80.bb.telus.com [2001:568:1::50a] 4 9 ms 9 ms 9 ms 2001:4860:1:1:0:354:0:4 5 9 ms 10 ms 8 ms 2001:4860:0:1040::1 6 10 ms 11 ms 9 ms 2001:4860:0:1::9bd 7 9 ms 9 ms 9 ms sea15s11-in-x0e.1e100.net [2607:f8b0:400a:808::200e] Trace complete. C:\Users\User>ping -4 google.com Pinging google.com [172.217.3.174] with 32 bytes of data: Reply from 172.217.3.174: bytes=32 time=14ms TTL=57 Reply from 172.217.3.174: bytes=32 time=9ms TTL=57 Reply from 172.217.3.174: bytes=32 time=13ms TTL=57 Reply from 172.217.3.174: bytes=32 time=9ms TTL=57 Ping statistics for 172.217.3.174: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 9ms, Maximum = 14ms, Average = 11ms C:\Users\User>ping -6 google.com Pinging google.com [2607:f8b0:400a:808::200e] with 32 bytes of data: Reply from 2607:f8b0:400a:808::200e: time=9ms Reply from 2607:f8b0:400a:808::200e: time=10ms Reply from 2607:f8b0:400a:808::200e: time=11ms Reply from 2607:f8b0:400a:808::200e: time=11ms Ping statistics for 2607:f8b0:400a:808::200e: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 9ms, Maximum = 11ms, Average = 10msubuntu 16.04 lts
Note, dig -6 returns ipv4 address, traceroute -6 and ping6 fail.
root@ubuntu-vpn:~# dig -4 google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -4 google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18870 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 172.217.3.174 ;; Query time: 22 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Jun 15 14:12:06 PDT 2017 ;; MSG SIZE rcvd: 55 root@ubuntu-vpn:~# dig -6 google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -6 google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11834 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 288 IN A 172.217.3.174 ;; Query time: 1 msec ;; SERVER: 2001:a:b:d800:215:5dff:fe5c:e21e#53(2001:a:b:d800:215:5dff:fe5c:e21e) ;; WHEN: Thu Jun 15 14:12:19 PDT 2017 ;; MSG SIZE rcvd: 55 root@ubuntu-vpn:~# traceroute -4 google.com traceroute to google.com (172.217.3.174), 30 hops max, 60 byte packets 1 pfSense.localdomain (192.168.1.1) 0.773 ms 0.748 ms 0.736 ms 2 10.31.238.1 (10.31.238.1) 8.891 ms 9.802 ms 10.566 ms 3 ae0.100.STTLWAWBGR80.bb.telus.com (154.11.10.9) 10.924 ms 154.11.10.11 (154.11.10.11) 9.769 ms 10.162 ms 4 72.14.220.60 (72.14.220.60) 10.439 ms 10.836 ms 10.823 ms 5 108.170.245.97 (108.170.245.97) 11.669 ms 108.170.245.113 (108.170.245.113) 11.465 ms 11.454 ms 6 108.170.233.159 (108.170.233.159) 11.246 ms 108.170.233.157 (108.170.233.157) 9.978 ms 108.170.233.159 (108.170.233.159) 9.959 ms 7 sea15s11-in-f174.1e100.net (172.217.3.174) 10.232 ms 8.457 ms 9.346 ms root@ubuntu-vpn:~# traceroute -6 google.com traceroute to google.com (2607:f8b0:400a:808::200e), 30 hops max, 80 byte packets connect: Network is unreachable root@ubuntu-vpn:~# ping -c 3 google.com PING google.com (172.217.3.174) 56(84) bytes of data. 64 bytes from sea15s11-in-f174.1e100.net (172.217.3.174): icmp_seq=1 ttl=57 time=9.84 ms 64 bytes from sea15s11-in-f174.1e100.net (172.217.3.174): icmp_seq=2 ttl=57 time=9.75 ms 64 bytes from sea15s11-in-f174.1e100.net (172.217.3.174): icmp_seq=3 ttl=57 time=9.11 ms --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2168ms rtt min/avg/max/mdev = 9.112/9.569/9.847/0.345 ms root@ubuntu-vpn:~# ping6 -c 3 google.com connect: Network is unreachableThis was working before. No idea what's causing it other than pfsense.
-
Wasn't sure why the results were different on windows and linux so flushed dns on windows. Now dig -6 gives the same result, fail.
Something is causing dns6 to not work.
C:\Users\User>ipconfig /flushdns Windows IP Configuration Successfully flushed the DNS Resolver Cache. C:\Users\User>Downloads\BIND9.10.5.x64\dig -6 google.com ; <<>> DiG 9.10.5 <<>> -6 google.com ;; global options: +cmd ;; connection timed out; no servers could be reached -
Same result when I flushed the dns on the linux server.
root@ubuntu-vpn:~# /etc/init.d/networking force-reload [ ok ] Reloading networking configuration (via systemctl): networking.service. root@ubuntu-vpn:~# dig -6 google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -6 google.com ;; global options: +cmd ;; connection timed out; no servers could be reached root@ubuntu-vpn:~# dig -4 google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -4 google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10260 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 172.217.3.174 ;; Query time: 545 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Jun 15 16:12:06 PDT 2017 ;; MSG SIZE rcvd: 55
