Windows 10 nslookup not working on 2.4 beta

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

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

bimmerdriver

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

I was away for a week and I forgot about this. While I was away, the system was completely idle. nslookup was not working before I left and aside from updating the pfsense snapshot when I got back, I made no changes to either pfsense or the client. Now nslookup is working again - at least for the moment.

C:\Users\User>nslookup google.com
Server: UnKnown
Address: 2001b:c::215:5dff:fe5c:e21e

*** UnKnown can't find google.com: Query refused

[the system was completely idle for over a week between the first command and the second command]

C:\Users\User>nslookup google.com
Server: pfSense.localdomain
Address: 2001b:c::215:5dff:fe5c:e21e

Non-authoritative answer:
Name: google.com
Addresses: 2607:f8b0:400a:800::200e
216.58.193.78

I really fail to understand what your not understanding here

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

What's with your snide tone of voice? Do you think I'm asking about this to be annoying or because I get off on you implying I'm stupid?!? Obviously the query was being refused, but the reason it was being refused is not obvious and it seems to have gone away.

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

I used dig because you recommended it. If it doesn't support ipv6 on windows, I'm not sure why you think dig is a "much better tool for debugging dns, that you can install it "without any issues" and why it's a "must have". Maybe it's good on *nix, but IMO if it doesn't support ipv6, it's utility on windows is debatable.

As I said before I went away, I followed your recommendation to set up an ACL. I further told you that after setting up an ACLs in the manner you described, it made no difference.

I also reinstalled pfsense 2.4 beta from scratch, using as few non-default settings as possible, which also made no difference.

I've never used ACLs before and had no previous dns problems.

I don't use ACLs on my 2.3.4 system and also have no dns problems (at least none that I'm currently aware of).

Before I went away, while this problem was occurring, I switched the windows 10 guest from the 2.3.4 system to the 2.4 beta system. It worked properly on the former, but not on the latter.

According to ipconfig /all, here are the dns addresses:

DNS Servers . . . . . . . . . . . : 2001b:c:215:5dff:fe5c:e21e
192.168.1.1

Both are pingable from the windows client.

Here are the default gateway addresses:

Default Gateway . . . . . . . . . : fe80::1:1%5
192.168.1.1

Also can ping the default gateway from the client.

Also can ping the client on all four of its ipv6 addresses using pfsense diagnostics ping.

So for some reason, on windows 10, ipv6 queries were being refused. Now they are are working. If it walks like a pfsense problem and quacks like a pfsense problem, it's probably a pfsense problem - one that seems to have gone away.

johnpoz

"If it doesn't support ipv6 on windows"

It does support ipv6 on windows - nobody ever said it didn't - there is just a bug currently with it pulling the IPv6 address from windows with the -6 option. As you saw I could query pfsense via ipv6 with it no problem just using @ipv6 address is all.

Your issue would of been easy to figure out of you could of just done some basic troubleshooting.. if it quacks like its stupid, and walks like its stupid and walks like its stupid - its most likely stupid ;) Sorry just couldn't help myself after you started the quack nonsense after doing zero actual troubleshooting to the problem as presented!!!

bimmerdriver

@johnpoz:

"If it doesn't support ipv6 on windows"

It does support ipv6 on windows - nobody ever said it didn't - there is just a bug currently with it pulling the IPv6 address from windows with the -6 option. As you saw I could query pfsense via ipv6 with it no problem just using @ipv6 address is all.

Your issue would of been easy to figure out of you could of just done some basic troubleshooting.. if it quacks like its stupid, and walks like its stupid and walks like its stupid - its most likely stupid ;) Sorry just couldn't help myself after you started the quack nonsense after doing zero actual troubleshooting to the problem as presented!!!

I misread your post about getting dig to work on windows, so I stand corrected about that. However, with regards to your "zero actual troubleshooting" remark, I'm still without words that wouldn't get me banned…