HTTP(S) connections (without DNS) to certain hosts are blocked (by ISP?) about dietpi

[Joulinar]

From your mobile phone, you should see the DNS queries inside the PiHole log. Do you? Even for the website in question. If this is the case, DNS resolution is working fine.

[Joulinar]

usually, DNS setting in DietPi itself has no relation to PiHole. And best practice is not to change to a local DNS server like PiHole or AGH.

[MichaIng]

First of all, of course, when you disable the DNS setting (i.e. not use Pi-hole>Unbound>DoT) in the WireGuard config, you need to enable DoH in browsers. The idea was to test whether, when DoH is used, toggling the VPN alone toggles the issue. Since Pi-hole does not support DoH, you can test this with any upstream DoH provider, or test again with AdGuard Home.

Of course pi.hole is only available, when using Pi-hole for DNS resolution, hence this only works when enforcing Pi-hole as DNS via VPN config or without VPN via LAN/DHCP server, and DoH must be disabled. However, this is irrelevant for the pornhub issue.

When you remove the "DNS" setting and stop the VPN, it is possible that you need to disconnect and reconnect to your LAN network, to get the DNS server from the DHCP server. I am not sure whether it has the original DNS server still stored somewhere internally to recover it on VPN stop. However, this should be a one-time action, since the VPN won't touch /etc/resolv.conf anymore on startup now. This would explain why accessing any hostname, including Google, failed.

Regarding the traceroute, interesting to see the exact routes for the two test cases of my first sentence: VPN enabled + DoH, VPN disabled + DoH, both when connected to the home LAN
I assume that, while DoH is used, enabling the VPN breaks pornhub access, disabling the VPN fixes it. And the route (after home router) is the only difference I can think of, while I have no idea how using the VPN from within your home LAN can have an effect on it.

[Joulinar]

Cloudflared can be used with Quad9 as well. It's just an application that can be used with various upstream DNS provider.

[MichaIng]

They are wrong: Cloudflare does not respect country filtering, at least not in your case. We do already know that clients get the correct IP from Cloudflare, and the connection is blocked on HTTP(S) connection level to/from the true host instead.

Not sure whether it is really OOT at superuser, but I wouldn't know a better StackExchange site in this case. I left a comment to ask about this, and add the relevant info, let's see ...

[MichaIng]

https://meta.superuser.com/questions/15219/where-to-ask-questions-about-non-dns-based-country-based-website-http-blocking

[MichaIng]

No need to ask AdGuard about that: It is intended behaviour, to block ads and/or block traffic to malicious sites. But yes, you are right, bbc.com and medium.com should of course not be blocked, at best, in case, only ads embedded in these websites. And the DietPi system should not have been affected. So probably the AdGuard HTTPS filtering was only one part of the issue.

Filtering will be done locally on an automated level, hence your traffic is, of course, not sent to AdGuard servers where they could read it. Though, not impossible that bits of information are sent to be checked by a cloud block list or heuristic. At least in general this is how some anti virus software do/did it. Though for ads filtering such is surely overkill an not done.

So for me, the problem is not concerns or mistrust against AdGuard now, but the method of decrypting HTTPS traffic, and that way breaking end-to-end encryption as well as authentication (installing a generally trusted cert for a website that is not coming from this website), in general. Actors who are trustable now can change, be hacked, or whatever, so having such method installed and generally accepted as "security enhancement" IMO bears a general risk for the future. There may be edge cases, but not as by default enabled feature for common end user software, IMO.

I've looking for ways to encrypt traffic between client (PC) to DNS resolver (Pi-hole or Adguard Home).

Downstream DoH or DoT with AdGuard Home and/or WireGuard/VPN with Pi-hole/AGH as you were already doing.

[yuukiAme]

I have since reinstall Adguard.apk from their Adguard website. Installed their CA.crt again to my Xiaomi.

I did a bit more research. In Adguard app Settings > Filtering > Network > HTTPS Filtering > HTTPS-Filtered websites > turn OFF Filter websites with EV certificates.

This is the real reason why 3 out of the 5 websites mentioned above broke. Not sure why DietPi itself broke either. I guess I can close this issue now.

Thank you for your time and knowledge @MichaIng and @Joulinar . This has been a very productive week and a ton of learning experience for me.

[Joulinar]

We should clarify a few basic things at the beginning.

When using a VPN such as Wireguard (PiVPN is only an interface on the server for managing clients), all traffic between the VPN client and VPN server is always encrypted. It doesn't matter what it is. Therefore, all requests, including DNS, between your mobile phone and your server are encrypted.

Communication between PiHole and Unbound is always unencrypted. However, this does not matter, as this only takes place on the server.

DNS requests between Unbound and the upstream DoT server, on the other hand, are encrypted again via TLS protocol.

Normally there should be no difference for DNS requests between a mobile phone via VPN or a client in the local network, as all requests first go to the PiHole and then to Unbound.

The chain actually looks like this: Client > (VPN) > PiHole > Unbound > Upstream DNS (via DoT)

Translated with DeepL.com (free version)

[yuukiAme]

We should clarify a few basic things at the beginning.

When using a VPN such as Wireguard (PiVPN is only an interface on the server for managing clients), all traffic between the VPN client and VPN server is always encrypted. It doesn't matter what it is. Therefore, all requests, including DNS, between your mobile phone and your server are encrypted.

Communication between PiHole and Unbound is always unencrypted. However, this does not matter, as this only takes place on the server.

DNS requests between Unbound and the upstream DoT server, on the other hand, are encrypted again via TLS protocol.

Normally there should be no difference for DNS requests between a mobile phone via VPN or a client in the local network, as all requests first go to the PiHole and then to Unbound.

The chain actually looks like this: Client > (VPN) > PiHole > Unbound > Upstream DNS (via DoT)

Translated with DeepL.com (free version)

I understand all that. Thanks for the clarification. So my current VPN traffic should be encrypted. Only the traffics from Pi-hole and Unbound is unencrypted.

Then what exactly can I do to test and find out why my query fails to certain websites in my VPN? Yet my traffic in local network works as intended.

[Joulinar]

Check whether all traffic from the VPN client to the VPN server goes through the tunnel or whether only a split tunnel is active. AllowedIPs = 0.0.0.0/0 should be set in the Wireguard client configuration.

[MichaIng]

WireGuard (clients) have a setting DNS to enforce a different DNS server to query, which makes sense since a local one might not be reachable when traffic is forced through the tunnel. If your PiVPN is running on the same server which hosts Pi-hole, use the WireGuard-internal VPN server IP with this setting.

Note that this is only a client-side setting, same as whether all traffic is forced through the VPN, requests to the server-side LAN or the server itself only. So it is all about how the clients are configured.

Ah, and don't forget to allow "All origins" in Pi-hole for DNS queries. By default it allows queries only from the LAN/main interface of the server, hence blocks queries form any VPN interface.

EDIT: Use AllowedIPs = 0.0.0.0/0, ::/0 at best (if you really want all traffic to be passed through the VPN) to assure IPv6 is as well forced through the tunnel. Else, if IPv6 is enabled on the client, all traffic to IPv6-enabled hosts would bypass the VPN.

[yuukiAme]

Check whether all traffic from the VPN client to the VPN server goes through the tunnel or whether only a split tunnel is active. AllowedIPs = 0.0.0.0/0 should be set in the Wireguard client configuration.

From my Wireguard client conf

[Interface]
PrivateKey = iCHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHcHE=
Address = 10.9.82.2/24
DNS = 10.9.82.1

[Peer]
PublicKey = FkPLcT0Nyt3JJJJJJJJJ+TMJAPwxEaxYOrcNTs=
PresharedKey = P292QilxCCCCCCCCCCCCCCCCCru4pkHzzPqCpK4=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = example.domain.com:51820

Ignore the PrivateKey , PublicKey, and PresharedKey, I changed to hide the actual value. So I definitely have AllowedIPs = 0.0.0.0/0, ::/0

[yuukiAme]

WireGuard (clients) have a setting DNS to enforce a different DNS server to query, which makes sense since a local one might not be reachable when traffic is forced through the tunnel. If your PiVPN is running on the same server which hosts Pi-hole, use the WireGuard-internal VPN server IP with this setting.

Note that this is only a client-side setting, same as whether all traffic is forced through the VPN, requests to the server-side LAN or the server itself only. So it is all about how the clients are configured.

Ah, and don't forget to allow "All origins" in Pi-hole for DNS queries. By default it allows queries only from the LAN/main interface of the server, hence blocks queries form any VPN interface.

EDIT: Use AllowedIPs = 0.0.0.0/0, ::/0 at best (if you really want all traffic to be passed through the VPN) to assure IPv6 is as well forced through the tunnel. Else, if IPv6 is enabled on the client, all traffic to IPv6-enabled hosts would bypass the VPN.

It's a full tunnel, which allows access to everything within the network. I can use http://pi.hole/admin, even SSH into any VM or server I have in my local network, e.g. Nginx Proxy and Portainer, etc...

I checked the public IP address and it's the same as the one from the Local Network, not the coffee shop public IP address or LTE Public IP.
I also checked the dnsleaktest and they all reported that it is using Cloudflare DNS which is my upstream DNS inside of Unbound.

[MichaIng]

I also checked the dnsleaktest and they all reported that it is using Cloudflare DNS which is my upstream DNS inside of Unbound.

Hmm, then I do not understand what the issue is, when clients do in fact use that Pi-hole instance as DNS server through the VPN. If those are Linux/UNIX clients, can you check /etc/resolv.conf, whether 10.9.82.1 is really the only namesever entry?

[yuukiAme]

can you check /etc/resolv.conf

root@DietPi:~# cat /etc/resolv.conf
nameserver 1.1.1.1
nameserver 1.0.0.1

[MichaIng]

I mean on the client(s).

[yuukiAme]

I mean on the client(s).

RIP. it's an iPhone.
I also have an Android phone with Termux installed. Give me a few minutes to setup another pivpn client on that Android device.

[yuukiAme]

The Termux doesn't work with cat /etc/resolv.conf. Nevermind.

Any other methods?

[MichaIng]

Yes, especially check whether you see a query log entry for those cases, where a website is blocked, while you expect it to be accessible thanks to the VPN DNS.

Ah, and also check whether the related browser has DoH enabled, which would bypass the system DNS and VPN.

[yuukiAme]

From your mobile phone, you should see the DNS queries inside the PiHole log. Do you? Even for the website in question. If this is the case, DNS resolution is working fine.

@Joulinar Yes, I can access Pi-hole over the VPN, use the http://pi.hole/admin/, and log in the admin panel, see the query log with my client name called wireguard.pivpn. DNS resolution is definitely working. I even check with SSH into the pi (over VPN), use dig to check Unbound issues. I even checked the Pi-hole > Tools > Search Adlists, to make sure none of my blocklists blocked the exact domain I want to test.

@MichaIng For sure, the DoH, I always check that one off within the browser, on Android 13 and later, inside its Settings, it has Private DNS. I made sure to turn that off first, not even Automatic.

[Joulinar]

Question was if you see inside PiHole log the DNS request for the website not working. If this is the case, DNS resolution is not your problem.

[yuukiAme]

Question was if you see inside PiHole log the DNS request for the website not working. If this is the case, DNS resolution is not your problem.

@Joulinar
I used another Android device named ai, connected over VPN and test out an 18+ site

Pi-hole logged the query

Screenshot on my Tablet device named ai- ai.pivpn

On my PC, with pornhub.com cache, no VPN

[Joulinar]

yes DNS resolution is working, so it's something else. Like the browser escaping the VPN tunnel

[yuukiAme]

Like the browser escaping the VPN tunnel

And exactly like how my browser behaves when my query was unencrypted (without Unbound DoT) using 1.1.1.1 at port 53 so my ISP DNS rejects the query. So that's why I'm stuck here. Wondering if PiVPN is "leaking" the query. But I know it shouldn't be.

[Joulinar]

It's not a DNS issue as you see the query inside PiHole. As well it is forward to Unbound according your PiHole screen shot. It's not the DNS query escaping but somehow the browser not using to VPN to access the website.

[yuukiAme]

I thought it was a fluke with Firefox. So I installed Vivaldi Browser for Android. I went into Vivaldi Settings > Privacy and security > and disabled use secure DNS : Off

I deliberately clicked on a Vivaldi bookmark added that I know for sure is in the blocklist. It blocked it successfully. But I tried with pornhub.com and the content is never delivered like Firefox.

I think you're right, @Joulinar .

the browser not using to VPN to access the website.

The browser is clearly using the Pi-hole DNS inside the VPN, but the domains blocked by my country is not working inside it.

[MichaIng]

Can you check whether the IP address pornhub.com is resolved to, is the same when accessing from your PC (within your LAN) and when accessing from the VPN client? If both get the same IP address, and all traffic of the client is passed through the VPN, I have no idea how the client could behave any differently. The browser should not be able to bypass the VPN, at least not when using accessing public/routable IP address. Other than DNS, network traffic/routes are enforced at system level.

And you are sure that Unbound is configured to use DoT? Compare with our docs: https://dietpi.com/docs/software/dns_servers/#__tabbed_2_5

Btw, on your PC pornhub.com works since you use DoH there?

[yuukiAme]

Can you check whether the IP address pornhub.com is resolved to, is the same when accessing from your PC (within your LAN) and when accessing from the VPN client?

on PC - LAN
Result: Working as intended

on Tablet (Android) - VPN
Result : Blocked

It's using the same IP address. The Cache is from the first query from PC.

And you are sure that Unbound is configured to use DoT? Compare with our docs: https://dietpi.com/docs/software/dns_servers/#__tabbed_2_5

Yes. I was troubleshooting another problem with domain end in .site with NLnetLabs/Unbound yesterday on Github. Issue here

Btw, on your PC pornhub.com works since you use DoH there?

Yup. It works. Same with other 18+ sites and news sites that my countries blocked.

[MichaIng]

Interesting, the LAN client seems to send a DoH query to Pi-hole, which is forwarded to Unbound, if I understand the "HTTPS" query type correctly?

However, so the A type query is answered as intended, works for the LAN client, is cached as intended, and hence answered from cache to the VPN client, but does not work there.

Confusing, indeed. The Android tablet is currently also located in your LAN, just using the VPN (unnecessarily, for testing), right? So that really only enabling the VPN makes the difference?

[yuukiAme]

Interesting, the LAN client seems to send a DoH query to Pi-hole, which is forwarded to Unbound, if I understand the "HTTPS" query type correctly?

I don't have DoH enabled for this network at all. Only Pi-Hole with Unbound DoT. I understand the difference between them. Like how Adguard-DNS / Adguard Home using DNS-over-HTTPS with their SSL cert and privatekey in Encryption Settings.

The Android tablet is currently also located in your LAN, just using the VPN (unnecessarily, for testing), right? So that really only enabling the VPN makes the difference?

I have 3 different ways of connecting to the internet.

1. Network number 1 have Pi-Hole with Unbound DoT and PiVPN
2. Network number 2 for my family uses, have no DNS server, or anything. Just ISP modem/router combo. So ISP can see my unencrypted query easily and reject it.
3. 4G/LTE from my phones.

So I use the Tablet connected to Network number 2 and turn on Wireguard app to connect to PiVPN and it connected to Network number 1 and I open pornhub.com in my Firefox browser and it's blocked.

I tried the exact same thing with 4G/LTE network as above. Same result.

Which led me to the Title of the issue "Leak DNS query over VPN connection". I know it isn't true.
That's why I'm asking for help to find faults in my understanding with PiVPN and disprove the title.

EDIT: changed # to number because Github pinged other issue numbers.

[MichaIng]

PiVPN means a (regular) WireGuard server in your case. Might be important when you check for answers elsewhere. PiVPN is only the installer, and the CLI to create client configs, otherwise it has no effect on the VPN.

With AllowedIPs = 0.0.0.0/0, ::/0, leaking the DNS query or anything else should not be possible. This creates a route which forces every routable request through the VPN. Only requests to local/LAN range IP addresses can then bypass the VPN. A killswitch can be used to prevent that as well. So I think, whatever happens, it happens at the VPN server/LAN side. We see the DNS query at Pi-hole, so that does not seem to be the issue. Probably traffic from the pornhub.com IP is blocked, not the DNS query, but that should apply for any other request from LAN the same way.

Maybe best to use tcpdump at the server, so see which requests are coming and going from the VPN client. Also, when you temporarily switch to using Pi-hole as DNS resolver for the VPN/Pi-hole server itself (/etc/resolv.conf), does accessing pornhub.com via curl work?

[yuukiAme]

when you temporarily switch to using Pi-hole as DNS resolver for the VPN/Pi-hole server itself (/etc/resolv.conf), does accessing pornhub.com via curl work?

output

root@DietPi:~# nslookup pornhub.com
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   pornhub.com
Address: 66.254.114.41

follow up output with curl

root@DietPi:~# curl pornhub.com
<!DOCTYPE html>
<html>
<header><title>404 Page</title></header>
<body>
<font size="6"><b>We're sorry but the page you're looking for could not be found!!!!!</b></font>
</body>
</html>

which is expected because of the transparent DNS query.

I will do the tcpdump later because this will take a while to check.

[yuukiAme]

Wait.
Should I change the Static DNS in Dietpi-config from Cloudflare DNS to to Pi-Hole with unbound DoT itselfinstead?

[yuukiAme]

Background: I brought my Macbook Air to the coffee shop. It took a while to setup the Wireguard because of the newer Wireguard cannot be installed from App Store. I had to deal with brew, Wireguard-tools and, wireguard-go

Macbook output /etc/resolv.conf

mac@192 ~ % cat /etc/resolv.conf 
#
# macOS Notice
#
# This file is not consulted for DNS hostname resolution, address
# resolution, or the DNS query routing mechanism used by most
# processes on this system.
#
# To view the DNS configuration used by this system, use:
#   scutil --dns
#
# SEE ALSO
#   dns-sd(1), scutil(8)
#
# This file is automatically generated.
#
nameserver 10.9.82.1

Macbook output on curl pornhub.com

mac@192 ~ % curl pornhub.com
<html><body><h1>408 Request Time-out</h1>
Your browser didn't send a complete request in time.
</body></html>

Macbook requests after using curl pornhub.com being caputure with tcpdump on the Server (Pi-hole)

REMOVED

EDIT: I will remove the tcpdump.txt in a few hours. Because it contains a lot of public IP address that could reveal my location.

[MichaIng]

which is expected because of the transparent DNS query.

I am not sure about that: The DNS query and the actual connection to the resolved host are two different things. Usually, sites are blocked by ISP by spoofing the DNS response with none/invalid. The IP you get from the transparent DNS response however is correct. It seems that the response from the pornhub host itself is intercepted. curl pornhub.com should return a 301 to HTTPS. Can you test this:

curl -I https://www.pornhub.com/

Your tcpdump also shows the response from reflectededge.reflected.net.http, which is indeed the CDN pornhub uses, i.e. the same happens when I do a successful request here.

HTTPS responses cannot be spoofed without the client at least warning about a wrong certificate. So if above HTTPS call fails the same way for you, it is pornhub themselves, or their CDN, who deny to send you data, not the ISP.

The other 17.* IP which appears is from Apple, so I guess this is unrelated?

[yuukiAme]

@MichaIng

output of curl -I https://www.pornhub.com/

sh-3.2# curl -I https://www.pornhub.com
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.pornhub.com:443

[yuukiAme]

At this point, I am considering switching to another DNS, like Adguard Home and using my own SSL from my own domain.

It doesn't tunnel or change my public IP address, but at the very least, my traffic isn't blocked.

[MichaIng]

The DNS is irrelevant. The client does get the correct IP. AdGuard Home will behave exactly the same.

What do you mean with your "own SSL" from your "own domain"? Your client either has the IP of your home/location where the VPN server is located, or the mobile/public WiFi IP.

The strange thing is why visiting pornhub from the PC at the same location works, when using DoH, while the "actual connection" (not DNS) from the VPN server system and VPN clients (using DoT) is responded with fake error documents, even different ones for both.

sh-3.2# curl -I https://www.pornhub.com
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.pornhub.com:443

Hmm, this indeed looks like the connection is roughly intercepted and some other entity answers which does not accept HTTPS connections at all. But probably it is also a different issue: libressl/portable#369
Though I guess it is similar to this one: https://serverfault.com/questions/955667/https-connection-tls-hangs-and-eventually-fails-ssl-error-syscall

Other HTTPS connections with this curl work well, right?

curl -I https://dietpi.com/

Can you test this:

openssl s_client -connect pornhub.com:443

[yuukiAme]

What do you mean with your "own SSL" from your "own domain"? Your client either has the IP of your home/location where the VPN server is located, or the mobile/public WiFi IP.

The AdGuard Home can be used like Adguard-dns.io from AdGuard which is free up to 300k query per month. AdGuard Home is a self-host solution.

Screenshot of the Encryption settings for Private DNS can be reached over the internet with HTTPS

I can reach AdGuard Home DNS from outside (internet) after I setup the SSL cert and private key. Then setup the Nginx Proxy Manager and point the proxy host to AdGuard Home (Local address - https://192.168.1.2/). So I can use the Adguard Home in the local network and outside the network with a URL like this

https://adguard.domain.com/dns-query/<-clientID->

after I put that into the Private DNS in the Android Settings or use the Adguard.apk.

---

output of curl -I https://dietpi.com/ on Macbook over VPN

sh-3.2# curl -I https://dietpi.com
HTTP/2 200 
date: Sat, 04 May 2024 13:04:52 GMT
content-type: text/html; charset=utf-8
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 0
x-robots-tag: all
x-permitted-cross-domain-policies: none
referrer-policy: no-referrer-when-downgrade
content-security-policy: upgrade-insecure-requests; frame-ancestors 'self'; base-uri 'self' https://dietpi.com/matomo/index.php https://dietpi.com/grafana/; default-src 'none'; object-src 'none'; style-src 'self' 'unsafe-inline'; font-src 'self' data:; img-src * data: blob:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdnjs.cloudflare.com; worker-src 'self' blob:; frame-src 'self'; manifest-src 'self'; connect-src 'self' https://api.github.com
permissions-policy: accelerometer=(), autoplay=(), browsing-topics=(), camera=(), display-capture=(), encrypted-media=(), fullscreen=(), geolocation=(), gyroscope=(), interest-cohort=(), magnetometer=(), microphone=(), midi=(), payment=(), usb=(), screen-wake-lock=()
cache-control: public, max-age=86399
strict-transport-security: max-age=31536000; includeSubDomains; preload
last-modified: Thu, 02 May 2024 20:56:15 GMT
vary: Accept-Encoding
content-language: en
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 87e8b1805e9b8508-HKG
alt-svc: h3=":443"; ma=86400

output of openssl s_client -connect pornhub.com:443

sh-3.2# openssl s_client -connect pornhub.com:443
CONNECTED(00000005)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G3
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
verify return:1
depth=0 C = CY, L = Dali, O = AYLO Freesites Ltd, CN = *.pornhub.com
verify return:1
---
Certificate chain
 0 s:/C=CY/L=Dali/O=AYLO Freesites Ltd/CN=*.pornhub.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G3
 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFYDCCBOagAwIBAgIQD837D4uUBWkl8BJGQLk/eTAKBggqhkjOPQQDAzBZMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMTMwMQYDVQQDEypEaWdp
Q2VydCBHbG9iYWwgRzMgVExTIEVDQyBTSEEzODQgMjAyMCBDQTEwHhcNMjQwMTE1
MDAwMDAwWhcNMjUwMjE0MjM1OTU5WjBRMQswCQYDVQQGEwJDWTENMAsGA1UEBxME
RGFsaTEbMBkGA1UEChMSQVlMTyBGcmVlc2l0ZXMgTHRkMRYwFAYDVQQDDA0qLnBv
cm5odWIuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEQ6ks4Tmx27FAmv5Q
nIaEaKhwKgu8WkvyoPfKw0eBlWoJVNXnZ/k5CCE2aGHIkNFDxlrmXJeJ6JTEbSuL
Fq+6GqOCA5YwggOSMB8GA1UdIwQYMBaAFIoj655r1/k3XfltITl2mqFn3hCoMB0G
A1UdDgQWBBQxgIgAP201gNmz1jNLbWA2DZniYTAlBgNVHREEHjAcgg0qLnBvcm5o
dWIuY29tggtwb3JuaHViLmNvbTA+BgNVHSAENzA1MDMGBmeBDAECAjApMCcGCCsG
AQUFBwIBFhtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwDgYDVR0PAQH/BAQD
AgOIMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjCBnwYDVR0fBIGXMIGU
MEigRqBEhkJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRHbG9iYWxH
M1RMU0VDQ1NIQTM4NDIwMjBDQTEtMi5jcmwwSKBGoESGQmh0dHA6Ly9jcmw0LmRp
Z2ljZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbEczVExTRUNDU0hBMzg0MjAyMENBMS0y
LmNybDCBhwYIKwYBBQUHAQEEezB5MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5k
aWdpY2VydC5jb20wUQYIKwYBBQUHMAKGRWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEdsb2JhbEczVExTRUNDU0hBMzg0MjAyMENBMS0yLmNydDAM
BgNVHRMBAf8EAjAAMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdQBOdaMnXJoQ
wzhbbNTfP1LrHfDgjhuNacCx+mSxYpo53wAAAY0OszvZAAAEAwBGMEQCICjsK2WY
EOkPh/wBbK60CUBzu2qDHbIiCs3/hDsBF4i2AiBxuiRkC8GkxS/T4oo1CPwqBft2
h8LnZycZLSeZR7Fh+AB2AH1ZHhLheCp7HGFnfF79+NCHXBSgTpWeuQMv2Q6MLnm4
AAABjQ6zO88AAAQDAEcwRQIhANTUYn0Ua0Zx1w3Ju8gwFatPDbb8wYYi32PdsP/j
BCdjAiBmsmAiW8X4WpK9qab80BhS4Esy+yRi5z4k0Rl9HN2dHAB3AObSMWNAd4zB
EEEG13G5zsHSQPaWhIb7uocyHf0eN45QAAABjQ6zO+8AAAQDAEgwRgIhAKAgZVsr
jqJPnBbSJMN6xIyL1tf5BLfHygeLS8Lur1m0AiEA2bKqrWYxlACFjCiLS17cKBwH
LAEMNEH9kWqn20PfJGMwCgYIKoZIzj0EAwMDaAAwZQIxAPeg/ejap9Xz+8T3Z1wF
jUcMl/izEmHDnejDnQ9HO++AyQHxhZj6FTL5Xza4OOaDdQIwLYF0jUxVQvn91kgo
rbBCC8XORT7VpX1bQHzivSXaleqtUJcmu1s+zdakOVdnfgBy
-----END CERTIFICATE-----
subject=/C=CY/L=Dali/O=AYLO Freesites Ltd/CN=*.pornhub.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 3663 bytes and written 289 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES128-GCM-SHA256
    Session-ID: 9D587A951F76E0908615C4EBF7D78BA8B89E92DEB84B4B4E704466D3FF00E49D
    Session-ID-ctx: 
    Master-Key: 353B64A3B428EA5FEBCCE70C991353081D3358F531E9C4E665E64C8FEA756BB9A0E2E00DBF678E5D17345ED3DDB72AF8
    TLS session ticket lifetime hint: 43200 (seconds)
    TLS session ticket:
    0000 - 2b be fa e1 2d 56 37 e6-f5 9a 9d 3e 6f 34 1d ee   +...-V7....>o4..
    0010 - ea 51 7d 45 3f c8 15 82-60 10 10 04 4c 81 ce 3d   .Q}E?...`...L..=
    0020 - 4d 16 dd c5 00 6b 41 d4-f9 23 df 82 9a 77 2d 60   M....kA..#...w-`
    0030 - 76 6c b9 83 4b f8 22 d0-d6 8d f7 36 3e 72 bb 7d   vl..K."....6>r.}
    0040 - bc 50 75 5d df 17 5d 58-22 06 f9 4a 94 26 0f 35   .Pu]..]X"..J.&.5
    0050 - a5 1d 0e 7e 30 7f 29 5d-10 b5 f6 a3 5e 07 68 9e   ...~0.)]....^.h.
    0060 - f6 48 93 6f 93 3c d0 51-2d 4c e3 6f 1d c7 4c a6   .H.o.<.Q-L.o..L.
    0070 - 7c 0d 94 63 94 2d 3d 87-5e 65 e8 c3 30 af df 70   |..c.-=.^e..0..p
    0080 - ba 98 11 37 7e f0 f5 f6-4a e2 a7 e3 7b c1 1f 37   ...7~...J...{..7
    0090 - 42 3b c3 70 dc d6 3d d2-e1 23 04 ba 5e 2f 95 b7   B;.p..=..#..^/..

    Start Time: 1714827957
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
HTTP/1.1 408 Request Time-out
Content-length: 110
Cache-Control: no-cache
Connection: close
Content-Type: text/html

<html><body><h1>408 Request Time-out</h1>
Your browser didn't send a complete request in time.
</body></html>
closed

[yuukiAme]

@MichaIng

I just checked in on my AdGuard Home Upstream DNS. I found this. The default DNS already changed to Pi-Hole for my entire network which is why AdGuard Home was using Pi-Hole as one of the upstream DNS.

screenshot below

It seems that the AdGuard Home was using the Pi-hole DNS without Unbound

192.168.16.2:53

That's my Pi-Hole local IP Address. Shouldn't it be 192.168.16.2:5335 ?

[Joulinar]

Nope, Pihole will ask Unbound not the client

And as stated more than once, DNS is not the issue. You are running into wrong direction. Still.

[yuukiAme]

Okay. I will trust you on that. I only here to help troubleshooting the problem. I haven't gotten a clue if it's the update or browser or anything here.

We can rule out it's not DNS or PiVPN or Wireguard.

[MichaIng]

The AdGuard Home can be used like Adguard-dns.io from AdGuard which is free up to 300k query per month. AdGuard Home is a self-host solution.

Yes, exactly like Pi-hole. But what you mean it probably that AGH supports downstream DoT and DoH, i.e. browsers can query it via DoH. Since you connect to your Pi-hole via VPN, it should not make a difference. But since somehow the VPN made the difference, worth to give it a try. But please do not run your AGH as open resolver. I am not sure whether DoH/DoT-only servers can be misused for DNS amplification attacks, but to rule out being abused for any bad things, or even just get overloaded from public access, configure AGH to accept connections only form your known clients. Since their IP changes with location, I am actually not sure right now how to even achieve that. If it is not possible, try first with VPN only (not forwarding DoH port), and see whether DoH over VPN works. For testing, however, you can just test it from within LAN with known IPs and without forwarding. Still not sure how it can even make a difference with all DNS traffic within our LAN or encrypted.

The pornhub certificate is the original one. Actually, the timeout response is no fake. When I run that openssl command at let it just wait, I get the same after a while. Probably curl on Apple devices behaves a little different, or indeed the connection to the pornhub CDN is flaky/slow for whatever reasons. Or the VPN for whatever reasons slows down the connection. But that would affect not only pornhub then ...

[yuukiAme]

But please do not run your AGH as open resolver.

I don't think I'm running AGH as open resolver. It has long string of ClientID for each of my devices. Unless I'm misunderstanding what you are talking about "open resolver".

I am not sure whether DoH/DoT-only servers can be misused for DNS amplification attacks, but to rule out being abused for any bad things, or even just get overloaded from public access, configure AGH to accept connections only form your known clients.

I will have to do more research on that. Thanks for the tip. Ooh. Scary stuffs.

The pornhub certificate is the original one. Actually, the timeout response is no fake. When I run that openssl command at let it just wait, I get the same after a while. Probably curl on Apple devices behaves a little different, or indeed the connection to the pornhub CDN is flaky/slow for whatever reasons. Or the VPN for whatever reasons slows down the connection. But that would affect not only pornhub then ...

Are we on the "right" track? I'm still not sure what we are nailing down here yet. But I am willing to keep troubleshooting. Just let me know.

[MichaIng]

I don't think I'm running AGH as open resolver. It has long string of ClientID for each of my devices. Unless I'm misunderstanding what you are talking about "open resolver".

But port 443 is still forwarded, so anyone can theoretically connect directly to your AGH, isn't it? Bots earlier or later scan and find all open ports.

Are we on the "right" track? I'm still not sure what we are nailing down here yet. But I am willing to keep troubleshooting. Just let me know.

I am not sure either and wouldn't have any explanation. But if I understood your earlier posts correctly, using DoH with any upstream DoH resolver from within your LAN without VPN, it works, but once enabling WireGuard to use Pi-hole>Unbound>DoT (and disable DoH in browser), it does not work. So either the VPN or DoH seem to make the difference. We know that you get the correct IP, so it is not the DNS response, but just in theory, when you have an ISP router which tracks DNS traffic within your LAN ... that would be so shady, but since we have no other explanation ... EDIT: Client > VPN > Pi-hole > Unbound > DoT ... actually no plain/unencrypted DNS traffic ever leaves the VPN/Pi-hole/Unbound server, so that router theory doesn't make sense either 😄.

[yuukiAme]

the port 443 is port forwarded to reverse proxy with Nginx. I also use Cloudflare domain. So Cloudflare themselves reverse proxy my domain behind their servers.

But if I understood your earlier posts correctly, using DoH with any upstream DoH resolver from within your LAN without VPN, it works

That's correct.

but once enabling WireGuard to use Pi-hole>Unbound>DoT (and disable DoH in browser), it does not work. So either the VPN or DoH seem to make the difference.

That's also correct.

We know that you get the correct IP, so it is not the DNS response, but just in theory, when you have an ISP router which tracks DNS traffic within your LAN ... that would be so shady,

My router is a TP-Link Archer one. There is no modem. I use XZ000-G3 as the GPON converter. Between the GPON converter and TP-Link Router, they handle the PPPoE authentication for my internet access. Within PPPoE, they uses their own ISP DNS there,

[MichaIng]

the port 443 is port forwarded to reverse proxy with Nginx. I also use Cloudflare domain. So Cloudflare themselves reverse proxy my domain behind their servers.

A proxy only hides the IP for clients who know/access the hostname. But it does not help against bots scanning for open ports across plain IP ranges. At a very minimum, you must keep port 53 closed. But as said, probably open DoT and DoH resolvers can be misused just the same or similar way. Assure that before running your AGH like that. These kind of attacks cause real damage to others!
EDIT: When only port 443 is open/forwarded, it is probably really not such a high risk, since bots probably will see it as webserver. But still, theoretically one could just try sending a DoH request to know whether there is an open DoH resolver.

My router is a TP-Link Archer one. There is no modem. I use XZ000-G3 as the GPON converter. Between the GPON converter and TP-Link Router, they handle the PPPoE authentication for my internet access. Within PPPoE, they uses their own ISP DNS there,

As of my edit above, the router should not even see any plain DNS traffic from VPN clients, as everything which reaches and leaves this very VPN/Pi-hole/Unbound server is/should be encrypted. However, since we do not have any other explanation so far, to test DoH with AGH, you could just do that within your LAN and keep the port closed. On the VPN client, you can add the public hostname of the VPN server to /etc/hosts with its LAN IP (or macOS/iOS has an own mechanism to add host entries). Or did you already test it while the port was open?

[yuukiAme]

I didn’t port forwarding port 53 at all. How do I check if I open port 53 in the local network of AGH?

and the test for /etc/hosts/

[MichaIng]

How do I check if I open port 53 in the local network of AGH?

By using it as DNS with some client, e.g. However, if port 53 is not forwarded, it should be fine.

and the test for /etc/hosts/

It is a file, not a directory. On macOS it is indeed used, hence could be edited like this form a terminal:

sudo nano /etc/hosts

Then you could add a line like that:

192.168.1.2 adguard.domain.com

However, I just recognised that it does not work like that, since the AdGuard proxy just redirects requests in the /dns-query/<clientID> path. And your AdGuard host does not react on this path. So I am currently not sure how to test this with closed port 443 bypassing the proxy.

Btw, does it work when using the WireGuard VPN as well as DoH with the AdGuard proxy?

[yuukiAme]

@MichaIng

It is a file, not a directory. On macOS it is indeed used, hence could be edited like this form a terminal:
sudo nano /etc/hosts
Then you could add a line like that:
192.168.1.2 adguard.domain.com
However, I just recognised that it does not work like that, since the AdGuard proxy just redirects requests in the /dns-query/ path. And your AdGuard host does not react on this path. So I am currently not sure how to test this with closed port 443 bypassing the proxy.

I guess I will skip this test for now. Until you come up with method to test.

Btw, does it work when using the WireGuard VPN as well as DoH with the AdGuard proxy?

I will make a new persistent ClientID just for the Wireguard VPN under [Interface] - DNS = 10.9.82.1 to DNS = adguard.domain.com/dns-query/<ClientID>

I did the test on Macbook and changed its Wireguard conf DNS = 10.9.82.1 to DNS = https://adguard.domain.com/dns-query/<ClientID>

The outcome was

** Error : The parameters were not valid.

when I ran sudo wg-quick up wg0.

so I changed its Wireguard conf DNS = 10.9.82.1 to DNS = adguard.domain.com/dns-query/<ClientID>

this time the output was normal, but the query log in AGH did not show the ClientID in the log at all. None showed up.

So the DNS wireguard is using 192.168.97.1 which is the coffee shop default DNS.

I also redid the test again after clearing the dns cache on the Macbook with sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

What else should I test?

[MichaIng]

** Error : The parameters were not valid.

This is expected. A full URL as DNS nameserver is valid only for DoH. WireGuard accepts a hostname only, not https:// URLs. Please remove this setting completely and try to just use DoH in your browser with this URL.

[yuukiAme]

Please remove this setting completely and try to just use DoH in your browser with this URL

Okay. Here are what I did.

I changed the wg0.conf back to the DNS : 10.9.82.1. Turned on Wireguard. Changed the DNS in Firefox to Max Protection : adguard.domain.com/dns-query/<ClientID>.

I tested with 3 domains.

• google | working as intended
• pornhub | never loaded
• medium | PR_connection_reset

All query above are found in AGH Query log. All of the query was Processed.

[MichaIng]

Please remove (or comment) the "DNS" setting completely, just to be sure/rule this out. It is optional.

The client is currently in the same LAN as the server? Then see whether disabling the VPN (with removed "DNS" setting) fixes pornhub access, enabling the VPN breaks it again. If so, we can basically rule out the DNS resolution and the way/protocol this is done with, and all that matters is whether the pornhub access itself (to the already resolved IP) is done from/through the VPN server system or not. No idea how this can make a difference, since in both cases, traffic is routed through the router and NAT, so the ISP and remote host should not be able to differentiate between requests from different clients behind the same NAT. pornhub is IPv4-only, and the HTTP protocol version is defined by client and remote server, so the VPN has no effect on this.

A traceroute might be interesting from the client. From macOS terminal:

traceroute www.pornhub.com
traceroute 66.254.114.41

Once with once without VPN enabled. So we see whether from the VPN server on, the route is exactly the same or not, and again that the preceding DNS resolution has no effect on this in either case.

[yuukiAme]

Please remove (or comment) the "DNS" setting completely, just to be sure/rule this out. It is optional.

Done.

The client is currently in the same LAN as the server?

The client here is Macbook. I tried using my network with Pi-Hole and Unbound. It fails to use www.pornhub.com now. Which is strange. So I used another daily driver PC - O11. It works with Vivaldi browser and Firefox browser. so I went back and tried Safari browser on Macbook with www.pornhub.com again but it fails with 408 Request Time-out

Summary table - on Pi-Hole and Unbound DoT network

#	Device	Browser	Status
1	PC	Firefox, Vivaldi	Working as intended
2	Macbook	Firefox	Secure Connection Failed - PR_END_OF_FILE_ERROR
3	Macbook	Safari	408 Request Time-out

Then see whether disabling the VPN (with removed "DNS" setting) fixes pornhub access, enabling the VPN breaks it again. If so, we can basically rule out the DNS resolution and the way/protocol this is done with, and all that matters is whether the pornhub access itself (to the already resolved IP) is done from/through the VPN server system or not.

I removed the entry DNS = 10.9.82.1 completed. Saved the config. Turned off DNS over HTTPS : Off in Firefox on Macbook. Turned on Wireguard VPN. Open Firefox brower.

Summary table - macbook with Wireguard VPN after removing DNS entry

#	test	status	note
1	Firefox - www.pornhub.com	"trouble finding that site"	not surprised
2	Firefox - www.google.com	"trouble finding that site"	that's weird
3	Firefox - http://pi.hole/admin	"trouble finding that site"	so it could not find pi-hole over VPN
4	Firefox - local gateway - 192.168.1.1	working as intended	so the local network works but not the internet

Checked with Safari browser. Same thing.

I will address the traceroute at the later comment. Because I know the traceroute will reveal a lot of public IP address that might compromise my real location. So it will takes me some time to redact certain IP Addresses.

[yuukiAme]

the result is too long so I will put it upload a .txt file instead.
I already redacted IP address that could reveal my location.

Text file below

traceroute.txt

Summary table

#	device	test	note	status
1	macbook	traceroute www.pornhub.com	with no VPN on coffee internet - default ISP DNS	Failed
2	macbook	traceroute 66.254.114.41	same as above	Failed
3	macbook	traceroute www.pornhub.com	with VPN on - no DNS entry in the config	Failed
4	macbook	traceroute www.pornhub.com	with VPN on - with 10.9.82.1 added back to DNS entry	Failed
5	macbook	traceroute 66.254.114.41	same as above	Failed
6	PC	traceroute www.pornhub.com	on PC - Pi-hole with Unbound DoT - no VPN	Success - Trace complete

[yuukiAme]

when you disable the DNS setting (i.e. not use Pi-hole>Unbound>DoT) in the WireGuard config, you need to enable DoH in browsers. The idea was to test whether, when DoH is used, toggling the VPN alone toggles the issue.

Well, I redid the test like you suggested above,

• deleted DNS entry in conf file and saved the file
• change Firefox Settings > DNS over HTTPS > Max protection > custom > my own AGH with ClientID

outcome:

• Browser cannot use the internet (i.e. www.google.com)
• Browser can access local network like the coffee shop's internet default Gateway (192.168.1.1)
• AGH query log has no entry from Macbook ClientID at all.
• using nslookup www.google.com in Terminal returned a google public IP address (141.251.220.14).

changed Max protection > Cloudflare (default)

• Browser cannot use the internet (i.e. www.google.com)
• Browser can access local network like the coffee shop's internet default Gateway (192.168.1.1)

Same outcome.

Since Pi-hole does not support DoH, you can test this with any upstream DoH provider, or test again with AdGuard Home.

It seems like without the DNS entry in the config file, the VPN will use the default DNS by the router which has the ISP DNS and block my query immediately if it's banned in my country.

I have nothing else to add related to matters above.

But one interesting tidbits, my country blocked https://store.steampowered.com this entire time since April 2024 - now, but I never noticed it because of Pi-hole, Unbound DoT, they unblock everything for me. I'm so glad to be using DietPi to assist me with all this.

I didn't believe it until I tried nslookup https://store.steampowered.com with default DNS provided by my ISP and it returned 127.0.0.1 . But with PiVPN on Macbook, nslookup https://store.steampowered.com returned the Steam Public IP.

I guess my ISP is cracking down harder on www.pornhub.com traffics than https://store.steampowered.com. But I still have no idea why my PC (O11) is working as intended but my other devices cannot access www.pornhub.com.

[MichaIng]

It seems like without the DNS entry in the config file, the VPN will use the default DNS by the router which has the ISP DNS and block my query immediately if it's banned in my country.

Hmm, yes, the "system" uses the default DNS from the ISP or whatever you configured in your LAN. However, with DoH enabled, the browser overrides this/does not use the system DNS. Hence if you cannot access Google with whichever DoH you configured, then your system seems to have no Internet access at all. Does pinging or curling the plain Google IP 141.251.220.14 work?

What I cannot derive from your info is whether you had WireGuard enabled or not in which case. I guess all tests were with VPN enabled, while with VPN disabled (and DoH) it works? If Internet access itself is broken once the VPN is enabled, then probably IP forwarding is missing at the VPN server? Can you check this on the VPN server system:

sysctl net.ipv4.conf.wg0.forwarding net.ipv4.conf.eth0.forwarding
iptables -L FORWARD
iptables -L POSTROUTING -t nat

And to verify that the VPN client really is connected:

wg

However, this did work before (all but pornhub), didn't it? Probably best to test from home LAN, to take out differences of the coffee shop Internet for now.

[yuukiAme]

Hmm, yes, the "system" uses the default DNS from the ISP or whatever you configured in your LAN. However, with DoH enabled, the browser overrides this/does not use the system DNS. Hence if you cannot access Google with whichever DoH you configured, then your system seems to have no Internet access at all. Does pinging or curling the plain Google IP 141.251.220.14 work?

Yeah. I couldn't figure it out either. So I rebooted the Macbook just to be sure nothing was misconfigured.

Steps I did:

1. removed the DNS entry again from the conf file and saved the file
2. change Firefox Settings > DNS over HTTPS > Max protection > Cloudflare

outcome:

• I have internet again.
• google.com works
• nslookup google works
• curl 142.250.207.78 works > https://www.google.com
• local gateway works in the browser

it might have been a bad cache or improper setting during the whole up/down from the wg0 interface.

If Internet access itself is broken once the VPN is enabled, then probably IP forwarding is missing at the VPN server? Can you check this on the VPN server system:

root@DietPi:~# sysctl net.ipv4.conf.wg0.forwarding net.ipv4.conf.eth0.forwarding
iptables -L FORWARD
iptables -L POSTROUTING -t nat
net.ipv4.conf.wg0.forwarding = 1
net.ipv4.conf.eth0.forwarding = 1
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.9.82.0/24         anywhere             /* wireguard-nat-rule */

I don't see the wg you're referring to in the output. But I can confirm that 10.9.82.0/24 is used by my PiVPN WG

I'm back at home. I will use my secondary WAN (no Pi-hole, unbound DoT, AGH) as an outside network to VPN if you want. Or should I use the 1st network (with Pi-hole, etc) to test the VPN and www.pornhub.com again?

[yuukiAme]

Extra comment related to this test above

Steps I did:

removed the DNS entry again from the conf file and saved the file
change Firefox Settings > DNS over HTTPS > Max protection > Cloudflare
outcome:

I have internet again.
google.com works
nslookup google works
curl 142.250.207.78 works > https://www.google.com/
local gateway works in the browser

All this over PiVPN Wireguard without the DNS entry in the conf file.

nslookup www.pornhub.com
Address: 127.0.0.1
which is blocked by default DNS (expected)

nslookup store.steampowered.com
Address: 127.0.0.1

nslookup xhamster.com
Address: 127.0.0.1

Firefox browser - enabled Max Protection > Cloudflare

website	status
pornhub.com	timed out
xhamster.com	working as intended
store.steampowered.com	working as intended

So my ISP really did something to pornhub.com

[MichaIng]

Okay, so now everything but pornhub works with VPN enabled and DoH. And when you disable the VPN now, can pornhub be accessed via browser?

What I want to find out is whether the VPN alone, taking DNS out of the game, has an effect on whether pornhub can be accessed or not.

wg is a command from WireGuard to see which clients was or is connected.

[yuukiAme]

And when you disable the VPN now, can pornhub be accessed via browser?

Steps I did:

sudo wg-quick down wg0 - so VPN is down.

nslookup google.com to confirm it's the DNS switched back to Default DNS by ISP. It did and returned 142.250.66.142

Good. I have internet.

Back to Firefox with DNS over HTTPS > Cloudflare

outcome - it timed out and never loaded on Firefox browser.

Just to be sure, I checked with xhamster.com and store.steampowered.com. They both working as intended in the browser.

as for the wg command, I turned on Wireguard again (Macbook)

ran the command, output below

sh-3.2# wg
interface: utun2
  public key: +REDACTED_LONG_STRING=
  private key: (hidden)
  listening port: 65446

peer: REDACTED_LONG_STRING=
  preshared key: (hidden)
  endpoint: <PUBLIC IP network 1 with Pi-Hole>:51820
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 12 seconds ago
  transfer: 40.92 KiB received, 20.14 KiB sent

wg on Server

peer: +REDACTED_LONG_STRING=
  preshared key: (hidden)
  endpoint: <PUBLIC IP from Network 2>:65446
  allowed ips: 10.9.82.3/32
  latest handshake: 3 minutes, 18 seconds ago
  transfer: 15.73 MiB received, 164.20 MiB sent

[MichaIng]

Hmm, so pornhub is not accessible on the Mac? Was it every accessible there? So instead of comparing VPN with no VPN, we should probably compare Mac and PC, as the PC is the only device where pornhub was ever accessible?

[yuukiAme]

so pornhub is not accessible on the Mac?

True. But if I use Proton VPN, it will work.

Was it every accessible there?

Not sure what this comment means.

we should probably compare Mac and PC, as the PC is the only device where pornhub was ever accessible?

I can confirm that my Xiaomi (Android) and Samsung Tablet (Android) did open www.pornhub.com in Firefox browser on BOTH LAN and VPN connection. Work just like my PC (Windows).

Ignore this.

Test: Devices on Pi-Hole network with Unbound, 3 websites being tested - pornhub, steam, xhamster

Device	Status
O11(Windows)	Pornhub✔Steam✔Xhamster✔
iPhone 10(iOS)	Pornhub❌Steam✔Xhamster✔
iPhone 14(iOS)	Pornhub❌Steam✔Xhamster✔
Xiaomi(Android)	Pornhub✔Steam✔Xhamster✔
Samsung(Android)	Pornhub❌Steam✔Xhamster✔
Macbook(MacOS)	Pornhub❌Steam✔Xhamster✔

Note: Earlier today, Xiaomi could not open www.pornhub.com. But it opens Steam just fine because I use the Steam app on Android.
OMG. I hate these tests. Why is it full of variety? It's so fickle. So much inconsistent.

I only have a laptop that is a Mac and it uses similar commands to Linux and I can move it around to different locations so that's why I chose it to test out VPN vs no VPN.

[MichaIng]

True. But if I use Proton VPN, it will work.

Makes sense, as your ISP then does not see any traffic from your home to pornhub (IP).

Not sure what this comment means.

I mean whether pornhub was ever accessible on the Mac (when not using ProtonVPN or any other public provider).

I only have a laptop that is a Mac and it uses similar commands to Linux and I can move it around to different locations so that's why I chose it to test out VPN vs no VPN.

Good, so we know the (home) VPN is not the reason for the issue, but it also does not prevent it. And encrypted DNS does not resolve it either, since it is the HTTP(S) connection itself which fails. And for now, based on earlier curl and openssl output, pornhub themselves get and answer the request, but the TLS handshake it is somehow not successful.

EDIT: Okay, some more devices are affected, interesting that one Android works, the other one not. Also the DietPi server is affected, getting a 404 response with curl, instead of a redirect. However, so we need to find out what the difference between requests from those devices is.

Can you run the traceroute on Windows like this:

tracert www.pornhub.com

And on the Mac and/or DietPi like this:

apt install mtr
mtr www.pornhub.com

and paste the results? I want to see whether the routes differ at any point. You can mask IPs/hostnames from your LAN, of course.

mtr instead of traceroute on Linux, since in my case the latter has issues finding the route to pornhub, while mtr and tracert (on Windows) succeed, and curl delivers the fill pornhub HTML document successfully.

[yuukiAme]

I mean whether pornhub was ever accessible on the Mac (when not using ProtonVPN or any other public provider).

Never. I hardly ever use this laptop. It's an older Macbook. It has like 4 GB of RAM and Intel duo cores. Super slow. So I never used it to access pornhub.com before yesterday.

traceroute on Windows

C:\Users\PC>tracert www.pornhub.com

Tracing route to pornhub.com [66.254.114.41]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  tplinkwifi.net [192.168.16.1]
  2    21 ms    19 ms    19 ms  O11 [2x.xx.xxx.xxx]
  3     2 ms     1 ms     1 ms  10.255.39.245
  4    21 ms    21 ms    21 ms  O11 [2x.xx.xxx.xxx]
  5    20 ms    24 ms    22 ms  O11 [2x.xx.xxx.xxx]
  6    21 ms    20 ms    20 ms  O11 [2x.xx.xxx.xxx]
  7    46 ms    44 ms    44 ms  O11 [2x.xx.xxx.xxx]
  8    40 ms    40 ms    75 ms  125.xxx.xxx.xxx.isp.domain.com  [125.xxx.xxx.xxx]
  9    39 ms    39 ms    39 ms  213.248.97.50
 10     *        *        *     Request timed out.
 11    40 ms    40 ms    40 ms  62.115.137.243
 12    76 ms    76 ms    76 ms  hnk-b4-link.ip.twelve99.net [62.115.112.223]
 13   245 ms   245 ms   245 ms  tky-b3-link.ip.twelve99.net [62.115.134.187]
 14   242 ms   240 ms   241 ms  lax-b23-link.ip.twelve99.net [62.115.137.108]
 15   241 ms   240 ms   240 ms  lax-b22-link.ip.twelve99.net [62.115.143.39]
 16   245 ms   245 ms   245 ms  haproxy-ic-328269.ip.twelve99-cust.net [213.248.75.179]
 17   230 ms   230 ms   229 ms  cust-reflected-svc11502.ip.reflected.net [64.210.157.119]
 18   245 ms   245 ms   244 ms  reflectededge.reflected.net [66.254.114.41]

Trace complete.

mtr www.pornhub.com

Wow. that's a cool application/software. I like it a lot. Thanks for introducing me to mtr.

output

DietPi (192.168.16.2) -> www.pornhub.com (66.254.114.41)                                       2024-05-08T02:38:53+0700
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                               Packets               Pings
 Host                                                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.16.1                                                              0.0%     5    0.4   0.6   0.4   0.6   0.1
 2. localhost                                                                 0.0%     5    2.0   1.8   1.4   2.0   0.2
 3. 10.255.39.245                                                             0.0%     5    1.7   1.9   1.6   2.6   0.4
 4. localhost                                                                20.0%     5   20.1  21.5  20.1  24.6   2.1
 5. localhost                                                                 0.0%     5   22.0  24.1  20.7  27.5   3.0
 6. localhost                                                                 0.0%     4   20.3  20.5  20.3  20.9   0.3
 7. localhost                                                                 0.0%     4   44.4  44.8  44.4  45.0   0.3
 8. 125.xxx.xxx.xxx.isp.domain.com                                           0.0%     4   40.1  47.8  40.1  70.0  14.8
 9. (waiting for reply)
10. (waiting for reply)
11. 62.115.137.243                                                            0.0%     4   40.3  40.3  40.0  40.5   0.2
12. hnk-b4-link.ip.twelve99.net                                               0.0%     4   76.6  76.9  76.5  77.2   0.4
13. tky-b3-link.ip.twelve99.net                                               0.0%     4  245.7 245.7 245.6 245.8   0.1
14. lax-b23-link.ip.twelve99.net                                              0.0%     4  241.1 241.1 241.0 241.2   0.1
15. lax-b22-link.ip.twelve99.net                                              0.0%     4  245.6 245.4 245.2 245.6   0.2
16. haproxy-ic-328269.ip.twelve99-cust.net                                    0.0%     4  245.8 245.7 245.4 246.1   0.3
17. cust-reflected-svc11502.ip.reflected.net                                  0.0%     4  229.9 232.6 229.8 240.3   5.2
18. reflectededge.reflected.net

They both seem to work.
Note: When I ran mtr on dietpi, the 125.xxx.xxx.xxx.isp.domain.com entry has a high rate of Loss - hovering around 75%-80%. No clue what that means.

Another test mtr on DietPi if I leave it on longer than 30 seconds

                                                 My traceroute  [v0.95]
DietPi (192.168.16.2) -> www.pornhub.com (66.254.114.41)                                       2024-05-08T03:08:42+0700
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                               Packets               Pings
 Host                                                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.16.1                                                              0.0%    27    0.5   0.6   0.4   4.5   0.8
 2. localhost                                                                 0.0%    27    2.3   3.8   1.4  47.8   8.8
 3. 10.255.39.245                                                             0.0%    27    2.0   1.8   1.5   2.4   0.2
 4. localhost                                                                 0.0%    27   21.4  20.9  19.8  21.9   0.6
 5. localhost                                                                 0.0%    27   19.9  22.8  19.5  25.8   2.1
 6. localhost                                                                 0.0%    27   20.6  20.6  20.2  21.6   0.3
 7. localhost                                                                 0.0%    27   44.6  45.0  44.1  46.3   0.7
 8. 125.xxx.xxx.xxx.isp.domain.com                                             0.0%    26   40.2  40.1  39.7  40.9   0.3
 9. 213.248.97.50                                                            84.0%    26   39.5  39.5  39.4  39.7   0.1
10. sng-b7-link.ip.twelve99.net                                              96.0%    26   40.4  40.4  40.4  40.4   0.0
11. 62.115.137.243                                                            0.0%    26   40.4  40.4  39.8  42.9   0.6
12. hnk-b4-link.ip.twelve99.net                                               0.0%    26   76.5  77.3  76.2  81.4   1.5
13. tky-b3-link.ip.twelve99.net                                               0.0%    26  241.6 241.5 241.2 242.0   0.2
14. lax-b23-link.ip.twelve99.net                                              0.0%    26  241.0 241.1 240.6 243.5   0.7
15. lax-b22-link.ip.twelve99.net                                              0.0%    26  241.5 241.1 240.7 241.5   0.2
16. haproxy-ic-328269.ip.twelve99-cust.net                                    0.0%    26  240.9 247.2 240.9 255.9   3.8
17. cust-reflected-svc11502.ip.reflected.net                                  0.0%    26  227.8 227.7 225.1 258.2   6.4
18. reflectededge.reflected.net                                               0.0%    26  241.2 244.7 240.9 245.3   1.1

[yuukiAme]

After brew install mtr and dealing with mtr command not found - I had to create ~/.zshrc to deal with it. I'm good

output for Macbook - without VPN on Pi-Hole network

mac.192 (192.168.16.32) -> www.pornhub.com (66.254.114.41)       2024-05-08T02:50:42
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                      Packets               Pings
 Host                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. tplinkwifi.net                                   0.0%    16    2.2   1.6   1.2   2.3   0.3
 2. localhost                                        0.0%    16    3.2  13.9   2.5  62.3  16.9
 3. 10.255.39.245                                    0.0%    16    3.3   3.2   2.6   4.9   0.5
 4. localhost                                        0.0%    16   21.7  22.4  21.3  23.6   0.7
 5. localhost                                        0.0%    15   28.3  26.1  22.3  28.6   1.9
 6. localhost                                        0.0%    15   21.8  21.8  21.3  23.1   0.5
 7. localhost                                        0.0%    15   47.0  47.1  45.8  52.3   1.6
 8. 125.xxx.xxx.xxx.isp.domain.com                  0.0%    15   45.6  46.6  45.1  56.4   2.7
 9. 213.248.97.50                                   57.1%    15   44.9  45.1  44.9  45.2   0.1
10. (waiting for reply)
11. 62.115.137.243                                   0.0%    15   45.2  42.0  41.0  45.3   1.4
12. hnk-b4-link.ip.twelve99.net                      0.0%    15   77.5  78.5  77.4  84.4   1.8
13. tky-b3-link.ip.twelve99.net                      6.7%    15  246.4 243.5 242.4 247.4   1.7
14. lax-b23-link.ip.twelve99.net                     6.7%    15  246.2 246.4 245.9 247.2   0.4
15. lax-b22-link.ip.twelve99.net                     0.0%    15  242.9 242.2 241.5 243.0   0.4
16. haproxy-ic-328269.ip.twelve99-cust.net           0.0%    15  247.7 250.3 246.1 276.6   8.0
17. cust-reflected-svc11502.ip.reflected.net         0.0%    15  226.3 228.3 226.3 234.9   3.1
18. reflectededge.reflected.net                      0.0%    15  246.0 243.0 241.8 246.3   1.6

output for Macbook - with VPN on Pi-Hole network

mac.192 (10.9.82.3) -> www.pornhub.com (66.254.114.41)              2024-05-08T02:51:57
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                         Packets               Pings
 Host                                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. pi.hole                                             0.0%    12    2.0   2.5   2.0   3.2   0.4
 2. tplinkwifi.net                                      0.0%    12    3.1   2.7   2.3   3.5   0.3
 3. localhost                                           0.0%    12    3.8   5.5   3.6  15.7   3.4
 4. 10.255.39.245                                       0.0%    12    4.2   4.2   3.7   4.9   0.4
 5. localhost                                           0.0%    12   24.3  23.6  22.1  24.6   0.7
 6. localhost                                           0.0%    12   29.1  27.0  22.7  29.9   1.9
 7. localhost                                           0.0%    12   23.1  23.0  22.4  23.7   0.4
 8. localhost                                           0.0%    11   46.8  47.5  46.1  48.9   0.9
 9. 125.xxx.xxx.xxx.isp.domain.com                     0.0%    11   42.2  42.9  41.7  43.9   0.7
10. 213.248.97.50                                      90.0%    11   46.0  46.0  46.0  46.0   0.0
11. (waiting for reply)
12. 62.115.137.243                                      0.0%    11   49.8  47.8  46.6  52.1   1.7
13. hnk-b4-link.ip.twelve99.net                         0.0%    11   78.7  80.6  78.5  90.7   3.8
14. tky-b3-link.ip.twelve99.net                         0.0%    11  257.1 249.0 247.6 257.1   2.7
15. lax-b23-link.ip.twelve99.net                        0.0%    11  245.6 243.6 242.9 245.6   0.7
16. lax-b22-link.ip.twelve99.net                        0.0%    11  243.1 243.4 242.9 243.9   0.3
17. haproxy-ic-328269.ip.twelve99-cust.net              0.0%    11  281.5 251.3 247.6 281.5  10.1
18. cust-reflected-svc11502.ip.reflected.net            0.0%    11  228.8 228.1 227.2 229.4   0.6
19. reflectededge.reflected.net                         0.0%    11  247.3 247.2 247.0 247.7   0.2

[yuukiAme]

Extra tests from Macbook

Test 3: mtr number 3 on network number 2 (not Pi-hole) no VPN - default DNS

192.168.1.106 (127.0.0.1) -> www.pornhub.com (127.0.0.1)                          2024-05-08T03:00:37
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                  Packets               Pings
 Host                                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. localhost                                                    0.0%    15    0.3   0.2   0.1   0.5   0.1

Test 4: mtr number 4 network number 2 with vpn no dns entry in conf file

192.168.1.106 (127.0.0.1) -> www.pornhub.com (127.0.0.1)                            2024-05-08T03:01:31
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                    Packets               Pings
 Host                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. localhost                                                      0.0%    11    0.1   0.1   0.1   0.2   0.0

Test 5 : mtr number 5 network number 2 with vpn with dns entry 10.9.82.1

mac.local (10.9.82.3) -> www.pornhub.com (66.254.114.41)               2024-05-08T03:02:46
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                    Packets               Pings
 Host                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. pi.hole                                                        0.0%    11    3.4   3.8   3.4   4.7   0.5
 2. tplinkwifi.net                                                 0.0%    11    4.2   4.2   3.5   5.1   0.4
 3. localhost                                                      0.0%    11    4.8  12.2   4.4  42.8  11.6
 4. 10.255.39.245                                                  0.0%    11    5.3   5.5   5.0   7.2   0.6
 5. localhost                                                      0.0%    11   24.0  24.6  23.6  25.9   0.9
 6. localhost                                                      0.0%    11   26.6  27.6  23.5  32.3   2.6
 7. localhost                                                      0.0%    11   23.9  24.2  23.5  26.0   0.7
 8. localhost                                                      0.0%    10   44.6  44.9  44.0  45.7   0.5
 9. 125.xxx.xxx.xxx.isp.domain.com                                 0.0%    10   49.4  51.0  47.6  71.9   7.4
10. 213.248.97.50                                                 88.9%    10   42.9  42.9  42.9  42.9   0.0
11. (waiting for reply)
12. 62.115.137.243                                                 0.0%    10   44.8  45.5  43.6  49.4   2.3
13. hnk-b4-link.ip.twelve99.net                                    0.0%    10   82.2  81.0  80.0  85.0   1.5
14. tky-b3-link.ip.twelve99.net                                    0.0%    10  249.0 249.2 248.5 250.0   0.5
15. lax-b23-link.ip.twelve99.net                                   0.0%    10  248.7 248.7 248.5 249.2   0.2
16. lax-b22-link.ip.twelve99.net                                   0.0%    10  248.8 249.0 248.4 250.2   0.5
17. haproxy-ic-328269.ip.twelve99-cust.net                         0.0%    10  244.5 244.9 244.3 246.0   0.5
18. cust-reflected-svc11502.ip.reflected.net                       0.0%    10  229.5 234.4 228.8 262.5  10.7
19. reflectededge.reflected.net                                    0.0%    10  248.0 248.3 247.9 249.1   0.4

[MichaIng]

Ah sorry, right, on Mac of course the apt install was nonsense. However, not bad to have the result from the DietPi/Linux system as well.

Yeah, mtr seems to be better than the classic traceroute, not only as it continues to monitor all nodes to get averages, but also since at least in this particular case, from the systems I can test this, traceroute was simply not able to find the route to pornhub.

ISP DNS blocks *.pornhub.com, hence all ends at localhost, makes sense. With any other DNS, the VPN adds the VPN/Pi-hole server as first hop, otherwise has no effect. And also the routes on all devices without VPN are identical. So that is not the difference. Probably it is not even the ISP which blocks this in a way, but the TLS libraries used on those systems somehow have an issue in your particular case. But I am pretty much out of ideas how to further debug.

Just one last test, on the DietPi system, which seem to have been affected as well. Can you test again with curl as well as wget? Both use different TLS libraries. If not the case, use Pi-hole for DNS resolving, as we know it is otherwise blocked by ISP DNS:

cp -a /etc/resolv.conf{,.bak}
echo 'nameserver 127.0.0.1' > /etc/resolv.conf
curl -L https://www.pornhub.com
wget -O- https://www.pornhub.com
mv /etc/resolv.conf{.bak,}

In case of success, both return the full HTML document, which is huge, so do not wonder, and no need to paste that 😄. If it ends with </html>, it was a success, that is all we need to know.

Not sure whether someone on our forum has further ideas how to debug, or in general how requests can be (made) fail in such a way. Otherwise, probably people on some StackExchange site, like https://superuser.com/, have an idea. In case, it makes sense to leave the (home) VPN out of the game. It was a reasonable idea to test whether it helps, but we showed that it is irrelevant in regards of the issue. But that using an encrypted public DNS (like DoH in browser) is required in any case, as the ISP DNS blocks it, is of course important, and that using a public VPN provider fixes the issue on the affected systems, is relevant as well. So it is somehow these particular systems or clients sending the HTTP(S) request through this particular ISP route, having issues, while other systems/clients, sending the same request through the same route, succeed.
EDIT: Ah, you said the Mac fails as well when trying from the coffee shop internet access, right? So the same clients are affected as well when sending from other access points in the same region (?).

An interesting case, so in case you're doing to further debug, I am interested about the outcome. You can ping me on superuser as well (same username).

[yuukiAme]

Just one last test, on the DietPi system, which seem to have been affected as well. Can you test again with curl as well as wget? Both use different TLS libraries. If not the case, use Pi-hole for DNS resolving, as we know it is otherwise blocked by ISP DNS:

cp -a /etc/resolv.conf{,.bak}
echo 'nameserver 127.0.0.1' > /etc/resolv.conf
curl -L https://www.pornhub.com
wget -O- https://www.pornhub.com
mv /etc/resolv.conf{.bak,}

Output on DietPi

root@DietPi:~# cp -a /etc/resolv.conf{,.bak}
echo 'nameserver 127.0.0.1' > /etc/resolv.conf
curl -L https://www.pornhub.com
wget -O- https://www.pornhub.com
mv /etc/resolv.conf{.bak,}
curl: (35) Recv failure: Connection reset by peer
--2024-05-08 04:13:11--  https://www.pornhub.com/
Resolving www.pornhub.com (www.pornhub.com)... 66.254.114.41
Connecting to www.pornhub.com (www.pornhub.com)|66.254.114.41|:443... connected.
GnuTLS: The TLS connection was non-properly terminated.
Unable to establish SSL connection.

With a blinking cursor. Should I Ctrl+C to cancel the operation?

What now? I certainly could make a superuser account and ask a question there. I don't think anyone else other than you, @MichaIng is willing to debug/troubleshooting this far into an issue.

Thank you so much for your help.

[yuukiAme]

Ah, you said the Mac fails as well when trying from the coffee shop internet access, right? So the same clients are affected as well when sending from other access points in the same region (?).

Yup. Mac fails at the Coffee Shop too. Another problem you happened to remind me is my country has 3 major ISP so their DNS and DNS Filter implementation are all different. That could be why my results are varies.

What a pain. All I want is to self-host and be in control of my data yet. To have privacy. Apparently it's too much to ask in my country. Super lame.

[MichaIng]

Okay, so OpenSSL and GnuTLS both run into the same issue. So the TLS library is unrelated as well. EDIT: Fits to the 404/408 response you got with curl pornhub.com, where no TLS was involved yet, but a redirect expected.

What now? I certainly could make a superuser account and ask a question there. I don't think anyone else other than you, @MichaIng is willing to debug/troubleshooting this far into an issue.

There is no guarantee, of course, and on StackExchange sites it is a bit RNG and timing, whether someone with interest and knowledge sees the question or not while it is new/highlighted. But there are certainly people around willing to help/answer questions, with much more knowledge/experience than me. So it is worth an attempt, if you do not mind the time to create an account, read a bit into how to ask a question properly and sort/sum up the relevant results we found.

What a pain. All I want is to self-host and be in control of my data yet. To have privacy. Apparently it's too much to ask in my country. Super lame.

Well, DNS and probably packet filtering by ISP is not directly related to whether you can self-host things or not? You can self-host a VPN and a DNS for DoT or DoH perfectly fine. So you can bypass DNS filtering that way, or use DoH with a public provider instead. Just sadly it does not help with the HTTPS request issue, whatever is causing this.

However, yeah, any kind of Internet filtering can be nasty. I was in China for a week, and it was interesting how many websites were blocked, not only raw.githubusercontent.com, while github.com works well (same in India, as far as I read, weird somehow), but also all Google services, including Gmail, Cloudflare, and even DuckDuckGo (my default search machine), for whatever reason. Microsoft services and Bing however do work. One can bypass the issue with a VPN, which is not strictly forbidden, especially for western visitors who often simply require it (our DietPi mails go through Gmail, currently). But even then, for some reasons, some websites are suspiciously slow, nearly unusable (when using DoH to bypass DNS block), while others work perfectly fine. Whether intended or not, at least I had the impression that it was intended, and your issue reminded me about this.

[yuukiAme]

@MichaIng I’m reading up on StackExchanger Superuser rules and tags.

Which tags do you think this issue belongs to? Because I know their mods will remove issues or could straight up ban me if I tried to resubmit and commit a “spam” offense against their site.

[yuukiAme]

@MichaIng

Superuser question posted

They closed it really quick with off-topic. The 2nd comment gave me some thoughts.
Is Cloudflare respecting my country content filtering as well? How do I switch all my query to Quad9 to test DNS-over-HTTPS properly?

[Joulinar]

How do I switch all my query to Quad9 to test DNS-over-HTTPS

I guess you would need to use cloudflared instead of Unbound. https://docs.pi-hole.net/guides/dns/cloudflared/

[yuukiAme]

@Joulinar
Thanks. That was my thoughts after that answer. Been researching through our DietPi old issues. Someone mentioned in 2018, Cloudflared was being shaddy with their CDN and bad for privacy. I'm not sure if their opinion changed since 2018.
I'm also looking into DNScrypt-proxy and ODOH.

[yuukiAme]

Yes. I understood that. The pi-hole Docs did mentioned the https upstream that is using Cloudflare DNS. Of course I could change it over to Quad9. I'm just making sure I'm learning all of the other options as well.

[yuukiAme]

Update: It seems that after I switched everything to Quad9, from the DietPi-Config, to the Cloudflared, set up with Quad9 DoH as upstream DNS, Wireguard app into my PiVPN, www.pornhub.com still doesn't work over the VPN.
So I installed Intra on my Android Tablet, selected Quad9 as the DNS over HTTPS server , erased the history and cache on my browser. I can access www.pornhub.com now.

Now I'm not sure what to think now. The issue can be closed I guess.

[yuukiAme]

@MichaIng @Joulinar

Good news.

I went nuts after drinking too many cups of coffee. So I did a factory reset on an Android device (Xiaomi) to reduce all variables.
So the phone is fresh. Only using network number 2 so no Pi-hole and Cloudflared. Only Default DNS from ISP.

I installed 1.1.1.1 app from Google Play Store. Install VPN profile, uses the Google Chrome that came with phone. To switch to DNS-over-HTTPS. Checked with 1.1.1.1/help to confirm that it is using cloudflare DoH.
I tested the five websites mentioned in the Superuser question.

They all work now. No delays. Instant content delivery.

I formed a hypothesis it could the Adguard.apk and maybe its the adguardca.crt.
I uses Adguard app on all my devices. Except for my PC because everything works on it, I have uBlock Origin on Firefox to deal with ads and Pi-Hole to block the domains completely.

Background:
The AdGuard app requires the user to install a CA certificate provided by AdGuard to enhanced the ad blocks and DNS filters. Otherwise, Firefox browser will throw HSTS / SSL errors.
It required the same on MacOS with a custom user cert added in the Keychain.
I think I found the problem.

To test out the hypothesis, I removed the CA cert from my Samsung tablet and uninstalled the Adguard.apk. Reboot the device. Install 1.1.1.1 app, install VPN profile. This device nows can open the 5 websites above as well.

Big progress.

Now that solves half the issue. Because MacOS and iPhone are still failing to open www.pornhub.com and sometimes with medium.com even without Adguard and its VPN profile. No clue why. It's not iCloud+ private relay.

Either Pornhub SSL/TLS certificate has a problem verify its identity with Adguard CA cert. Not too sure on the traffic and route from the ISP side.

Do you have any methods to debug related to SSL/TLS cert instead?
Should I ask the expert over in the Unbound issues for help? He was pretty good at looking at my unbound journalctl log.

I can finally close this issue. Looks like I will have to remove all Adguard app and its CA from the trusted CA.

EDIT: I forgot. I need to test this over VPN as well. Before closing this issue.

[MichaIng]

Okay that is a very good explanation: Note that HTTPS filtering/inspection means that AdGuard decrypts, filters and in case blocks all traffic/packets between you and the website you want to access. This includes porn, online banking (aside of some hardcoded exceptions), etc. So I am quite sure that this AdGuard HTTPS filter/firewall rates some pornhub content as malicious, block it, hence replaces it with these weird 404/408 HTML documents I was wondering about. The only thing I am wondering about, is why the DietPi system was affected by this as well.

The way this is implemented, basically compromises HTTPS at its core. It is like a MITM, which HTTPS normally prevents against, but in this case you are explicitly asked to trust the AdGuard certificate which re-encrypts traffic. I mean, AdGuard software is (mostly or completely?) open source, and we have no reason to mistrust them (now). But IMO the principle to break the essential security of HTTPS in the name of security is just wrong. And I am not alone with this opinion.

We are using Cloudflare as proxy/CDN/cache/DDoS protection for HTTP(S) traffic to our website, which basically does the same. However, it does so transparently, i.e. resolving dietpi.com gives you IP addresses from the known Cloudflare Edge servers, the related TLS certificate is controlled by use, can be enabled/disabled/revoked, it adds request and response headers to tell clients what they are connecting to etc. And most importantly, DietPi is not a sensitive/privacy concerning topic, and everything you can do on our website is/will be public anyway. Bug report and survey uploads, done via SFTP, bypass Cloudflare, btw. But I would be at least concerned about an app/actor which decrypts/reads really all traffic to any website/web service 😉.

[yuukiAme]

This includes porn, online banking (aside of some hardcoded exceptions), etc. So I am quite sure that this AdGuard HTTPS filter/firewall rates some pornhub content as malicious, block it, hence replaces it with these weird 404/408 HTML documents I was wondering about.

This might explain it. If this is true, when I reinstall Adguard.apk, install the adguard-ca.crt, I turn off the dns filtering and firewall, it should allow my devices to start opening the HTTPS to the 5 websites I mentioned above and content delivery should work as intended.

But the weird part in this is why bbc.com and medium.com fails as well. Their websites shouldn't be on their DNS filtering, right? I only my ISP DNS is interested in blocking those traffic.

The way this is implemented, basically compromises HTTPS at its core. It is like a MITM, which HTTPS normally prevents against, but in this case you are explicitly asked to trust the AdGuard certificate which re-encrypts traffic. I mean, AdGuard software is (mostly or completely?) open source, and we have no reason to mistrust them (now). But IMO the principle to break the essential security of HTTPS in the name of security is just wrong. And I am not alone with this opinion.

I will email their support and create a ticket asking for clarification on their ca crt and dns filtering. Decrypting my HTTPS traffic on their end and see my query is obvious concerning. But I understand why it had to be done. How else Adguard suppose to know if that specific traffic needed to block and not delivery to client device.

But I would be at least concerned about an app/actor which decrypts/reads really all traffic to any website/web service 😉.

Viewing the traffic is just one problem. If they are storing customer traffic and still linking it to me, and my government happens to required them by law to hand it over is another problem.

I've looking for ways to encrypt traffic between client (PC) to DNS resolver (Pi-hole or Adguard Home). The internet pointed me to dnscrypt.info and there are so many implentation between the client implementation vs server implementation that I don't know which one to uses. Any suggestions?