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

[yuukiAme]

Creating a bug report/issue

• [x] I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version

root@DietPi:~# cat /boot/dietpi/.version
cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=3
G_DIETPI_VERSION_RC=0
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN

root@DietPi:~# echo $G_DISTRO_NAME $G_RASPBIAN
bookworm 0

• Kernel version | uname -a

root@DietPi:~# uname -a
Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)

root@DietPi:~# echo $G_HW_MODEL_NAME
RPi 4 Model B (aarch64)

• Power supply used | (EG: 5V 1A RAVpower)

Raspberry Pi Power supply 5V 3A

• SD card used | (EG: SanDisk ultra)

SanDisk Ultra 64G

Additional Information (if applicable)

• Software title

PiVPN

• Was the software title installed freshly or updated/migrated?

Freshly installed

• Can this issue be replicated on a fresh installation of DietPi?

Not sure.

• Bug report ID | echo $G_HW_UUID

root@DietPi:~# echo $G_HW_UUID
c16aa61b-b23a-4d7c-adcd-91591412a10b

Steps to reproduce

1. install Dietpi image on RPi

2. apt update && apt upgrade -y

3. dietpi-launcher

4. install Pi-hole, Unbound, activate DoT with the conf from Dietpi Docs

5. install pivpn, wireguard, setup DNS support with Pi-Hole ,add user, scan QR code

6. add conf file to a device (e.g: an Android phone) to connect to pivpn OUTSIDE of the network

7. check for the websites that is KNOWN to be blocked like 18+ sites, see if it returns query on unbound, load the content on the browser within my Local Network, meaning the DoT is working because my DNS query is encrypted and returned to Unbound with no issue.

8. Turn on Wireguard VPN on the device in Step 6

9. check if the known blocked website works and contents are loaded in the browser.

Expected behaviour

It should load all the contents of the website in the browser.

Actual behaviour

The browser will not load any content and return an error like "Unable to connect". Like an unencrypt query was rejected by the ISP DNS.

Extra details

I can use Pi-Hole with Unbound (activated DoT (DNS over TLS)). I can browse normally to any websites I want other than the block list inside Pi-Hole. My country required ISP to blocks certain websites from their own DNS. So ISP will allow your network to query the website, but it will reject the content of the website.

Help me to troubleshoot if PiVPN is leaking the query because when I access my network over PiVPN, it behaves exactly like when I access the blocked websites WITHOUT Pi-Hole and Unbound DoT which mean my query to unencrypted and intercept by my ISP.

My question is:

How do I check/troubleshoot PiVPN whether it is encrypting my query to Pi-Hole and Unbound on port 5335 or leaving the query unencrypted like port 53?

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

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

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

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

[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: https://github.com/libressl/portable/issues/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