Pi-hole + Unbound + PiVPN = No ad blocking?

Expected Behaviour:

Rpi4b

To block ads while connected to my network or while connected to my VPN.

Actual Behaviour:

Ads are only being blocked if I am connected to my VPN. If I am just connected to my home network, I see ads.

Debug Token:

https://tricorder.pi-hole.net/zhb5eegawr

I appreciate any help! I've been beating my head against the wall. First I struggled to get the vpn working properly as a split tunnel, now I can't get the ads part figured out. Thanks in advance!

It would depend on your chosen protocol (IPSec, OpenVPN, Wireguard,..) and possibly on some settings in your chosen VPN software (PiVPN) as well how you'd inject Pi-hole as DNS into your VPN connection.

In earlier versions, PiVPN applied some incompatible settings to Pi-hole's configuration in an extra file under /etc/dnsmasq.d/.
I have no idea whether that was changed in more recent versions of PiVPN. Other users were successful by removing that extra file and/or changing Pi-hole's interface listening behaviour, you should search our forums for other PiVPN topics.

Meanwhile, as this is not a Pi-hole issue, I am moving this to the Community Help category.

1 Like

From a client in your local network please run

nslookup pi.hole

nslookup flurry.com
1 Like

Sure thing. Here is the output. Thanks!

C:\Users\conta>nslookup pi.hole
Server:  UnKnown
Address:  2600:<redacted>:6500::1

*** UnKnown can't find pi.hole: Non-existent domain

C:\Users\conta>nslookup flurry.com
Server:  UnKnown
Address:  2600:<redacted>:6500::1

Non-authoritative answer:
Name:    flurry.com
Addresses:  98.136.103.23
          74.6.136.150
          212.82.100.150

Your network isn't using Pi-hole as DNS server.
It's using the device at 2600:<redacted>:6500::1, likely your router, thus bypassing Pi-hole.

This may be the case because Pi-hole isn't aware of its correct IPv6 address because your IPv6 prefix has changed (likely by your ISP, from 2600:<redacted>:5800 at the time of Pi-hole's installation to 2600:<redacted>:6500 now):

*** [ DIAGNOSING ]: Setup variables
    IPV6_ADDRESS=2600:<redacted>:5800:<redacted>:f3d1

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve sm3na.com via Pi-hole (2600:<redacted>:5800:<redacted>:f3d1)

You could consider to Use IPv6 ULA addresses for Pi-hole.

1 Like

Ahhhhh! I've made some changes on the router end and reran the lookups. Does this look better?

C:\Users\conta>nslookup pi.hole
Server:  UnKnown
Address:  2600:2b00:7954:8400::1

Name:    pi.hole
Addresses:  2600:2b00:7954:5800:222c:c127:a8fd:f3d1
          192.168.50.17


C:\Users\conta>nslookup flurry.com
Server:  UnKnown
Address:  2600:2b00:7954:8400::1

Name:    flurry.com
Addresses:  ::
          0.0.0.0

Is there a way I can test if my split tunnel is working? Thanks for your help!

Yes, those nslookups produced the expected results, but it also shows your IPv6 prefix to have changed again.

If your ISP is habitually changing IPv6 prefixes, you'd probably lose DNS on the next prefix assignment, or probably worse, have your Pi-hole by-passed via an alternate IPv6 DNS server without you even noticing, at least not at first.

1 Like

Made another change. Look any better? Know a way to check if WireGuard is working in split tunnel like I set up?

C:\Users\conta>nslookup pi.hole
Server:  UnKnown
Address:  2600:2b00:7954:8c00:b9fd:2037:28b2:add3

Name:    pi.hole
Addresses:  2600:2b00:7954:8200:8e8c:af9b:da62:8e20
          192.168.50.17


C:\Users\conta>nslookup flurry.com
Server:  UnKnown
Address:  2600:2b00:7954:8c00:b9fd:2037:28b2:add3

Name:    flurry.com
Addresses:  ::
          0.0.0.0

No, just looks the same (so still good).

The fact that your ISP may change your ISP prefix is outside of your direct control.

As long as you keep using a public IPv6 (2000::/3 range) for Pi-hole, this will impact your IPv6 DNS resolution the moment the prefix changes.

Hence the above advice to switch to a ULA address (fd00::/8 range).
Alternatively, the linked topic also contains a user-provided script that tries to automate updating a changed prefix. However, it would do so only periodically.

As an extreme but also very effective measure, you could disable IPv6 completely - if your router allows that and you are not dependent on IPv6.

I'm not sure why you would need a split tunnel configuration for clients in your home network?
You'd normally have that for roaming devices outside of your network that use the tunnel for DNS only, while other traffic takes the usual route.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.