I recently installed openvpn on my rpi4 alongside pihole. - At the moment, I am only using it as a client and pointing it to my VPN provider (IPVanish). In the logs, I can confirm that the connection is automatically being created at startup. However, I wanted to see if there was an easy way to verify that all traffic on the rpi4 is being routed through the VPN tunnel (especially DNS).
Just for background information, here is the full setup that is running on the same rpi4: The OS is Raspbian Lite (buster), and all DNS requests are being forwarded from PiHole to Unbound (port 5353). In the event that Unbound needs to reach out to an external DNS server, it will use DNSCrypt (port 5354). - I ran the extended leak test on dnsleaktest.com and verified that only my preferred external DNS servers are being displayed (and not my ISP). - The three products (PiHole, Unbound, and DNSCrypt) used to reside on an Ubuntu Server 19.04 VM before the rpi4 purchase.
I at least verified that the external IP being reported by the rpi4 is different (via "curl ifconfig.me"), which at least confirms the vpn tunnel. However, I still need to verify DNS routing.
I doubt that your Pi-hole would take over as DNS once connected to a third party VPN provider, as the VPN provider pushes it’s own DNS settings to the (connected) clients.
A simple nslookup should tell you your DNS on the client ...
Local DNS (pihole) is responding. Since it is handling relay (forwarding), I won't actually see any of the backend components responding (i.e.: Unbound or DNSCrypt).
The pihole device itself is the vpn client in question. Meaning, it's connecting to a 3rd party VPN service (IPvanish) via openvpn.
I haven't attempted to setup any manual routes yet, but the goal is to make sure that outgoing (forwarded) DNS requests are being sent through the vpn tunnel (tun0), and not back through to router/gateway via eth0.
I think I achieved what I was looking for by setting up explicit routes within UFW. That, combined with explicit deny rules, should ensure that only port 53 leaves the VPN tunnel (tun0) and http/https traffic (originating from the rpi4) leaves eth0 (targeting my internal subnet).
