Windows 10 nslookup not working on 2.4 beta

johnpoz

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?

bimmerdriver

@johnpoz:

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.

johnpoz

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.

aclunbound.png_thumb

digtopfsenseforgoogleAAAA.png_thumb

ipv6snlookuptopfsense.png_thumb

bimmerdriver

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: 12

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

![Capture 1.PNG](/public/imported_attachments/1/Capture 1.PNG)
![Capture 1.PNG_thumb](/public/imported_attachments/1/Capture 1.PNG_thumb)
![Capture 2.PNG](/public/imported_attachments/1/Capture 2.PNG)
![Capture 2.PNG_thumb](/public/imported_attachments/1/Capture 2.PNG_thumb)

bimmerdriver

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

bimmerdriver

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.

johnpoz

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

aclunbund.png_thumb

bimmerdriver

@johnpoz:

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.

johnpoz

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.

bimmerdriver

@johnpoz:

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.

bimmerdriver

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

bimmerdriver

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.

bimmerdriver

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.

johnpoz

"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 ;)

bimmerdriver

@johnpoz:

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

johnpoz

that has nothing to do with pfsense if 10.31.238.1 is not pfsense.. 8ms that sure is not lan latency….

bimmerdriver

@johnpoz:

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 = 10ms

ubuntu 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 unreachable

This was working before. No idea what's causing it other than pfsense.

bimmerdriver

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

bimmerdriver

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

johnpoz

I really fail to understand what your not understanding here

";; connection timed out; no servers could be reached"

Seems pretty clear.. either unbound is not listing on your ipv6 address or your not able to talk to it on the address your client is using for ipv6 dns.. What address is that? And does dig even support that command in the version running on windows?

So why don't you do some basic troubleshooting - what IPv6 address is your client pointing to for dns? Can you ping this address. Do you see its mac in your ndp table? Is unbound set to listen on this interface? The link local address of that interface? Sniff to see if your query is even going out from your client via ipv6..
Quick test from linux shows that working fine..
But windows running latest version of dig seems to balk at that command, but if use @ipv6address working fine.. So seems more a bug in dig on windows with -6 than any issue with ipv6 dns queries.

nslookup is using ipv6 on windows to unbound on pfsense just fine.

edit: you might notice my query from windows to a different ipv6 prefix than from my linux query - this is because they are on 2 different /64s on my network.

digcommand.png_thumb

nslookupipv6.png_thumb