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?
    ![nslookup 2.3.4.PNG](/public/imported_attachments/1/nslookup 2.3.4.PNG)
    ![nslookup 2.3.4.PNG_thumb](/public/imported_attachments/1/nslookup 2.3.4.PNG_thumb)
    ![nslookup 2.4 beta.PNG](/public/imported_attachments/1/nslookup 2.4 beta.PNG)
    ![nslookup 2.4 beta.PNG_thumb](/public/imported_attachments/1/nslookup 2.4 beta.PNG_thumb)


  • Rebel Alliance Global Moderator

    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?



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


  • Rebel Alliance Global Moderator

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



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


  • Rebel Alliance Global Moderator

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




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


  • Rebel Alliance Global Moderator

    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.



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



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

  • Rebel Alliance Global Moderator

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



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


  • Rebel Alliance Global Moderator

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



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



  • 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
    
    

  • Rebel Alliance Global Moderator

    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.






  • @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:  2001🅰b: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:  2001🅰b: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 . . . . . . . . . . . : 2001🅰b: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.


  • Rebel Alliance Global Moderator

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



  • @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…