The issue I am facing:
Certain websites refuse to load or load incompletely when using pihole with wireguard on Windows 10. I have noticed issues with Github, Reddit and Stack Overflow to name a few. When I use my android phone to browse the websites using the same pihole/wireguard server I have no problems. When I use a proxy server on the same VPS as the pihole/wireguard server I also have no issues browsing in windows. When I use Developer Tools in Firefox to view the network transfers of the problem sites most of the requests end with NS_ERROR_NET_TIMEOUT or NS_ERROR_ABORT
Details about my system:
Pihole/Wireguard is fully updated on an Oracle Cloud Ubuntu 22.04 VPS. Windows 10 and all the browsers I have tried, Chrome, Edge, Firefox are current versions. In researching this issue I came to think ipv6 was a source so I set the windows registry to Prefer IPv4 over IPv6 and disabled the analysis of AAAA queries in Pi-hole but that did nothing.
What I have changed since installing Pi-hole:
I made no memorable changes that would have affected the functionality of pihole. I only started noticing the issue when I had to start using windows exclusively after my Linux system failed. When I was using linux I do not remember having the issue and I do not have the issue with android.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Your debug log shows Pi-hole to be fully operational, but there are some irregularities regarding its connectivity (not necessarily related to your issue).
For IPv4, I notice that link-local IPv4 addresses (range 169.254.0.0/16) are present in your host's routing table as well as its list of DNS resolvers, even though all of your hosts's interfaces have acquired private range IP addresses.
This could be related to running on an Oracle Cloud instance. I can't tell whether it may even be expected for such a setup.
At the same time, I find it hard to think of ways how this would possibly contribute towards your observation, but mention it as unusual nevertheless.
For IPv6, your debug log shows that DNS resolution via your host's link local IPv6 (range fe80::/10)) fails:
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
(...)
[✗] Failed to resolve x04x6.mjt.lu on enp0s3 (fe80::17ff:fe12:a579)
This may suggest that port 53 is unreachable via IPv6.
In addition, I also notice that your wireguard wg0 interface only carries an IPv4 address.
This may support that some clients would be able to by-pass Pi-hole via alternative DNS server's IPv6 addresses.
Run from a Win10 client, what is the output of:
nslookup pi.hole
nslookup flurry.com
Also, from the same client, please share the DNS server section from the following command's output:
I think Oracle Cloud uses the 169.254.0.0/16 range for services such as iSCSI and instance metadata and warn specifically about not messing with that.
Please note that I have not configured the VPS to use IPv6 networking from the Oracle platform although it is an option. I have not altered the IPv6 networking in Ubuntu on the VPS and do not consciously use IPv6 on it. My ISP does not use IPv6 and I do not consciously use it on my windows machine. I say this to say that if either disabling or fully enabling IPv6 is solution I am willing to go either way.
Your nslookup results look fine, your cloud-base Pi-hole is used via VPN and filtering DNS requests.
The ipconfig output would suggest that your Win10 client is unaware of any IPv6 DNS servers, which is also good (though the output looks like you've typed it yourself, rather than copied it).
From your above results, it would seem that indeed your Win10 client has no IPv6 connectivity, or at least isn't using IPv6 for ist DNS requests.
When encountering NS_ERROR_NET_TIMEOUT or NS_ERROR_ABORT, would the DNS requests for the site you are trying to access register in Pi-hole's Query Log? Would those include requests for AAAA records?
Would you be able to verify whether your browser actually received an IP, and whether it would use the site's IPv6 address from an AAAA record reply?
I'm just guessing here: Maybe its trying to access that IPv6 address, and it times out as you actually don't have public IPv6 connectivity.
Also, would you run any Antivirus package on that Win10 machine, possibly with features like AVG Secure DNS or AVAST Real-Site enabled?
The output from ipconfig wasn't looking neat so I just removed the extra spaces and dots.
Yes the requests register in the Query Log and yes I am seeing AAAA requests (please note that I re-enabled analysis of AAAA queries). I believe the browser received an IP because the get request to github.com has status 200 in Firefox and the page partially loads but multiple requests to github.githubassets.com fail with NS_ERROR_NET_TIMEOUT (the very first request to github.githubassets.com says CORS_FAILED). I don't know if this is significant but I noticed in the Query Log that the request to github.githubassets.com appeared 5 minutes after trying to load the page and in Firefox the page has a Finish time of 4.48 min and a Load time of 10.27 min. I don't know if the browser is trying to use the AAAA reply.
Here is the output from the Query Log
2023-04-10 07:21:04 AAAA github.com winpb650.pivpn OK (cache)
INSECURE NODATA (0.0ms)
2023-04-10 07:21:04 A github.com winpb650.pivpn OK (cache)
INSECURE IP (0.0ms)
2023-04-10 07:21:04 A github.com winpb650.pivpn OK (answered by localhost#5335)
INSECURE IP (2.2ms)
This is the the output from pihole.log
Apr 10 07:21:04: query[A] github.com from 10.137.196.3
Apr 10 07:21:04: forwarded github.com to 127.0.0.1#5335
Apr 10 07:21:04: validation result is INSECURE
Apr 10 07:21:04: reply github.com is 140.82.112.4
Apr 10 07:21:04: query[A] github.com from 10.137.196.3
Apr 10 07:21:04: cached github.com is 140.82.112.4
Apr 10 07:21:04: query[AAAA] github.com from 10.137.196.3
Apr 10 07:21:04: cached github.com is NODATA-IPv6
On Reddit the page does not load at all and eventually times out and unlike github where there are numerous requests to github.githubassets.com that fail there is a single GET request to www.reddit.com that fails with NS_ERROR_NET_TIMEOUT. I have a similar experience with Stack Overflow.
Query Log
**Apr 10 08:01:53: query[A] www.reddit.com from 10.137.196.3**
Apr 10 08:01:53: cached www.reddit.com is <CNAME>
Apr 10 08:01:53: forwarded www.reddit.com to 127.0.0.1#5335
Apr 10 08:01:53: validation result is INSECURE
Apr 10 08:01:53: reply www.reddit.com is <CNAME>
Apr 10 08:01:53: reply reddit.map.fastly.net is 146.75.37.140
**Apr 10 08:01:53: query[A] reddit.map.fastly.net from 10.137.196.3**
Apr 10 08:01:53: cached reddit.map.fastly.net is 146.75.37.140
**Apr 10 08:01:53: query[AAAA] reddit.map.fastly.net from 10.137.196.3**
Apr 10 08:01:53: forwarded reddit.map.fastly.net to 127.0.0.1#5335
Apr 10 08:01:53: validation result is INSECURE
Apr 10 08:01:53: reply reddit.map.fastly.net is NODATA-IPv6
I am running Symantec Endpoint Protection but as far as I can tell the only feature it has that would interfere with DNS is to notify if changes have been made to the Windows host file but I stand to be corrected.
All of the AAAA requests you've shown have a NODATA-IPv6 reply (like above), i.e there is no IPv6 address for those respective domains.
This would invalidate my earlier guess that your browser would perhaps try to speak IPv6 with your sites despite the absence of public IPv6 connectivity.
Indeed, your Pi-hole log excerpt confirms that Pi-hole has answered those requests.
If this would also be true for other DNS requests related to the problematic sites (like github.githubassets.com), then that would suggest that your issue is not related to DNS resolution.
You may verify this by running the respective lookups from the Win10 client, e.g.
nslookup github.githubassets.com
That sounds as if something on that Win10 machine would be delaying DNS requests?
I really appreciate you sticking with this, thank you.
I probably should have mentioned this before, even though the requests to github, reddit and stackoverflow don't produce IPv6 results I have seen IPv6 addresses in pihole.log. I just did a test by googling IPv6 only websites and I was able to get this result when trying to load http://ipv6.google.com/:
Apr 10 15:52:33: query[A] www.google.com from 127.0.0.1
Apr 10 15:52:33: forwarded www.google.com to 127.0.0.1#5335
Apr 10 15:52:33: query[AAAA] www.google.com from 127.0.0.1
Apr 10 15:52:33: forwarded www.google.com to 127.0.0.1#5335
Apr 10 15:52:33: validation result is INSECURE
Apr 10 15:52:33: reply www.google.com is 142.251.16.104
Apr 10 15:52:33: reply www.google.com is 142.251.16.105
Apr 10 15:52:33: reply www.google.com is 142.251.16.99
Apr 10 15:52:33: reply www.google.com is 142.251.16.103
Apr 10 15:52:33: reply www.google.com is 142.251.16.147
Apr 10 15:52:33: reply www.google.com is 142.251.16.106
Apr 10 15:52:33: validation result is INSECURE
Apr 10 15:52:33: reply www.google.com is 2607:f8b0:4004:c17::93
Apr 10 15:52:33: reply www.google.com is 2607:f8b0:4004:c17::69
Apr 10 15:52:33: reply www.google.com is 2607:f8b0:4004:c17::63
Apr 10 15:52:33: reply www.google.com is 2607:f8b0:4004:c17::68
Apr 10 15:52:36: query[A] ipv6.cybernode.com from 127.0.0.1
Apr 10 15:52:36: forwarded ipv6.cybernode.com to 127.0.0.1#5335
Apr 10 15:52:36: query[AAAA] ipv6.cybernode.com from 127.0.0.1
Apr 10 15:52:36: forwarded ipv6.cybernode.com to 127.0.0.1#5335
Apr 10 15:52:36: dnssec-query[DS] cybernode.com to 127.0.0.1#5335
Apr 10 15:52:36: reply cybernode.com is DS keytag 2371, algo 13, digest 2
Apr 10 15:52:36: dnssec-query[DNSKEY] cybernode.com to 127.0.0.1#5335
Apr 10 15:52:36: reply cybernode.com is DNSKEY keytag 34505, algo 13
Apr 10 15:52:36: reply cybernode.com is DNSKEY keytag 2371, algo 13
Apr 10 15:52:36: validation result is SECURE
Apr 10 15:52:36: reply ipv6.cybernode.com is 104.21.11.8
Apr 10 15:52:36: reply ipv6.cybernode.com is 172.67.147.108
Apr 10 15:52:36: validation result is SECURE
Apr 10 15:52:36: reply ipv6.cybernode.com is 2606:4700:3031::6815:b08
Apr 10 15:52:36: reply ipv6.cybernode.com is 2606:4700:3032::ac43:936c
Apr 10 15:52:36: query[A] ajax.aspnetcdn.com from 127.0.0.1
Apr 10 15:52:36: forwarded ajax.aspnetcdn.com to 127.0.0.1#5335
Apr 10 15:52:36: query[A] cdn.cybernode.com from 127.0.0.1
Apr 10 15:52:36: forwarded cdn.cybernode.com to 127.0.0.1#5335
Apr 10 15:52:36: query[AAAA] ajax.aspnetcdn.com from 127.0.0.1
Apr 10 15:52:36: forwarded ajax.aspnetcdn.com to 127.0.0.1#5335
Apr 10 15:52:36: query[AAAA] cdn.cybernode.com from 127.0.0.1
Apr 10 15:52:36: forwarded cdn.cybernode.com to 127.0.0.1#5335
Apr 10 15:52:36: validation result is SECURE
Apr 10 15:52:36: reply cdn.cybernode.com is 172.67.147.108
Apr 10 15:52:36: reply cdn.cybernode.com is 104.21.11.8
Apr 10 15:52:36: validation result is SECURE
Apr 10 15:52:36: reply cdn.cybernode.com is 2606:4700:3031::6815:b08
Apr 10 15:52:36: reply cdn.cybernode.com is 2606:4700:3032::ac43:936c
Apr 10 15:52:36: query[A] ajax.googleapis.com from 127.0.0.1
Apr 10 15:52:36: forwarded ajax.googleapis.com to 127.0.0.1#5335
Apr 10 15:52:36: query[AAAA] ajax.googleapis.com from 127.0.0.1
Apr 10 15:52:36: forwarded ajax.googleapis.com to 127.0.0.1#5335
Apr 10 15:52:36: query[A] ajax.googleapis.com from 127.0.0.1
Apr 10 15:52:36: query[AAAA] ajax.googleapis.com from 127.0.0.1
Apr 10 15:52:36: validation result is INSECURE
Apr 10 15:52:36: reply ajax.googleapis.com is 142.251.167.95
Apr 10 15:52:36: query[A] platform.twitter.com from 127.0.0.1
Apr 10 15:52:36: forwarded platform.twitter.com to 127.0.0.1#5335
Apr 10 15:52:36: query[AAAA] platform.twitter.com from 127.0.0.1
Apr 10 15:52:36: forwarded platform.twitter.com to 127.0.0.1#5335
Apr 10 15:52:36: validation result is INSECURE
Apr 10 15:52:36: reply ajax.googleapis.com is 2607:f8b0:4004:c08::5f
Apr 10 15:52:36: dnssec-query[DS] aspnetcdn.com to 127.0.0.1#5335
Apr 10 15:52:36: validation result is INSECURE
Apr 10 15:52:36: reply platform.twitter.com is <CNAME>
Apr 10 15:52:36: reply cs472.wac.edgecastcdn.net is <CNAME>
Apr 10 15:52:36: reply cs1-apr-8315.wac.edgecastcdn.net is <CNAME>
Apr 10 15:52:36: reply wac.apr-8315.edgecastdns.net is <CNAME>
Apr 10 15:52:36: reply cs1-lb-us.8315.ecdns.net is <CNAME>
Apr 10 15:52:36: reply cs41.wac.edgecastcdn.net is 72.21.91.66
Apr 10 15:52:36: validation result is INSECURE
Apr 10 15:52:36: reply platform.twitter.com is <CNAME>
Apr 10 15:52:36: reply cs472.wac.edgecastcdn.net is <CNAME>
Apr 10 15:52:36: reply cs1-apr-8315.wac.edgecastcdn.net is <CNAME>
Apr 10 15:52:36: reply wac.apr-8315.edgecastdns.net is <CNAME>
Apr 10 15:52:36: reply cs1-lb-us.8315.ecdns.net is <CNAME>
Apr 10 15:52:36: reply cs491.wac.edgecastcdn.net is 2606:2800:220:131d:1d30:1f1d:238b:1e56
Apr 10 15:52:36: reply aspnetcdn.com is no DS
Apr 10 15:52:36: dnssec-query[DS] msecnd.net to 127.0.0.1#5335
Apr 10 15:52:36: reply msecnd.net is no DS
Apr 10 15:52:36: validation result is INSECURE
Apr 10 15:52:36: reply ajax.aspnetcdn.com is <CNAME>
Apr 10 15:52:36: reply mscomajax.vo.msecnd.net is <CNAME>
Apr 10 15:52:36: reply cs22.wpc.v0cdn.net is 152.199.4.33
Apr 10 15:52:36: validation result is INSECURE
Apr 10 15:52:36: reply ajax.aspnetcdn.com is <CNAME>
Apr 10 15:52:36: reply mscomajax.vo.msecnd.net is <CNAME>
Apr 10 15:52:36: reply cs22.wpc.v0cdn.net is NODATA-IPv6
Apr 10 15:52:36: query[AAAA] cs22.wpc.v0cdn.net from 127.0.0.1
Apr 10 15:52:36: cached cs22.wpc.v0cdn.net is NODATA-IPv6
Apr 10 15:52:37: query[A] apis.google.com from 127.0.0.1
Apr 10 15:52:37: forwarded apis.google.com to 127.0.0.1#5335
Apr 10 15:52:37: query[AAAA] apis.google.com from 127.0.0.1
Apr 10 15:52:37: forwarded apis.google.com to 127.0.0.1#5335
Apr 10 15:52:37: validation result is INSECURE
Apr 10 15:52:37: reply apis.google.com is <CNAME>
Apr 10 15:52:37: reply plus.l.google.com is 142.251.16.101
Apr 10 15:52:37: reply plus.l.google.com is 142.251.16.138
Apr 10 15:52:37: reply plus.l.google.com is 142.251.16.100
Apr 10 15:52:37: reply plus.l.google.com is 142.251.16.102
Apr 10 15:52:37: reply plus.l.google.com is 142.251.16.139
Apr 10 15:52:37: reply plus.l.google.com is 142.251.16.113
Apr 10 15:52:37: validation result is INSECURE
Apr 10 15:52:37: reply apis.google.com is <CNAME>
Apr 10 15:52:37: reply plus.l.google.com is 2607:f8b0:4004:c17::71
Apr 10 15:52:37: reply plus.l.google.com is 2607:f8b0:4004:c17::8b
Apr 10 15:52:37: reply plus.l.google.com is 2607:f8b0:4004:c17::65
Apr 10 15:52:37: reply plus.l.google.com is 2607:f8b0:4004:c17::66
Apr 10 15:52:37: query[A] accounts.google.com from 127.0.0.1
Apr 10 15:52:37: forwarded accounts.google.com to 127.0.0.1#5335
Apr 10 15:52:37: query[AAAA] accounts.google.com from 127.0.0.1
Apr 10 15:52:37: forwarded accounts.google.com to 127.0.0.1#5335
Apr 10 15:52:37: validation result is INSECURE
Apr 10 15:52:37: reply accounts.google.com is 172.253.62.84
Apr 10 15:52:37: validation result is INSECURE
Apr 10 15:52:37: reply accounts.google.com is 2607:f8b0:4004:c07::54
Apr 10 15:52:38: query[A] ssl.gstatic.com from 127.0.0.1
Apr 10 15:52:38: forwarded ssl.gstatic.com to 127.0.0.1#5335
Apr 10 15:52:38: query[AAAA] ssl.gstatic.com from 127.0.0.1
Apr 10 15:52:38: forwarded ssl.gstatic.com to 127.0.0.1#5335
Apr 10 15:52:38: validation result is INSECURE
Apr 10 15:52:38: reply ssl.gstatic.com is 172.253.115.94
Apr 10 15:52:38: validation result is INSECURE
Apr 10 15:52:38: reply ssl.gstatic.com is 2607:f8b0:4004:c06::5e
Apr 10 15:52:38: query[A] syndication.twitter.com from 127.0.0.1
Apr 10 15:52:38: gravity blocked syndication.twitter.com is 0.0.0.0
Apr 10 15:52:38: query[AAAA] syndication.twitter.com from 127.0.0.1
Apr 10 15:52:38: gravity blocked syndication.twitter.com is ::
Apr 10 15:52:40: query[A] ipv6.google.com from 127.0.0.1
Apr 10 15:52:40: forwarded ipv6.google.com to 127.0.0.1#5335
Apr 10 15:52:40: query[AAAA] ipv6.google.com from 127.0.0.1
Apr 10 15:52:40: forwarded ipv6.google.com to 127.0.0.1#5335
Apr 10 15:52:40: validation result is INSECURE
Apr 10 15:52:40: reply ipv6.google.com is <CNAME>
Apr 10 15:52:40: reply ipv6.l.google.com is NODATA-IPv4
Apr 10 15:52:40: query[A] ipv6.l.google.com from 127.0.0.1
Apr 10 15:52:40: cached ipv6.l.google.com is NODATA-IPv4
Apr 10 15:52:40: validation result is INSECURE
Apr 10 15:52:40: reply ipv6.google.com is <CNAME>
Apr 10 15:52:40: reply ipv6.l.google.com is 2607:f8b0:4004:c07::8b
Apr 10 15:52:40: reply ipv6.l.google.com is 2607:f8b0:4004:c07::66
Apr 10 15:52:40: reply ipv6.l.google.com is 2607:f8b0:4004:c07::64
Apr 10 15:52:40: reply ipv6.l.google.com is 2607:f8b0:4004:c07::65
In the browser I get
This page isn’t working ipv6.google.com didn’t send any data.
ERR_EMPTY_RESPONSE
I got some strange results running this command. Initially, I mistakenly did it in a wsl2 Ubuntu shell and got this result:
nslookup github.githubassets.com
;; communications error to 10.137.196.1#53: timed out
;; communications error to 10.137.196.1#53: timed out
;; communications error to 10.137.196.1#53: timed out
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: github.githubassets.com
Address: 185.199.110.154
Name: github.githubassets.com
Address: 185.199.109.154
Name: github.githubassets.com
Address: 185.199.111.154
Name: github.githubassets.com
Address: 185.199.108.154
;; communications error to 10.137.196.1#53: timed out
;; communications error to 10.137.196.1#53: timed out
;; communications error to 10.137.196.1#53: timed out
I have 3 resolvers in the resolv.conf, pihole, 1.1.1.1 and 8.8.8.8, in the Ubuntu shell so I am guessing it fell back to 1.1.1.1 when pihole wasnt giving it up. I then ran the command in the windows prompt and got this:
That's expected - Pi-hole dutyfully provides IPv6 addresses for AAAA as requested by clients:
As there is no IPv4, the browser failing to load ipv6.l.google.com would be in line with you having no public IPv6 connectivity.
Is that WSL Ubuntu running on your Win10 client?
Perhaps it is not part of your VPN then?
Did those 3 timed out requests register in Pi-hole's Query Log?
If so, the log could tell for which upstream's reply Pi-hole has been waiting, which may hint at an upstream resolver issue.
The WSL Ubunutu shell isn't part of my daily usage and not the cause of my issue as it occurs when WSL is fully uninstalled. I did not check if the errors were logged and I have been unable to reproduce that error using the Ubuntu shell.
Ok, if we can disregard those related irregularities from your earlier nslookups, I doubt even more that Pi-hole's DNS resolver would be involved.
You should refocus on your Win10 client.
Is your Wireguard connecting to your Pi-hole peer via a DynDNS domain?
If so, would the issue perhaps start occuring once your DynDNS entries have been updated?
Would restarting/reconnecting Wireguard on Win10 allow sites to load faster again?