How to let Merlin use PiHole that's behing a OpenVPN connection on Google Cloud Platform?

[Rici]

Hi all,

I successfully set up an OpenVPN Server server on GCP and installed Pi-Hole there.
For testing purposes, I downloaded the OVPN file to my Android and ensured I could successfully connect to that OpenVPN server running on GCP and access my Pi-Hole admin site there. So I know this works.

Question: How to let my Asus Merlin router (acting as OpenVPN client then), successfully establish the connection to my OpenVPN Server instance on GCP and use the PiHole there for DNS purposes of my local network clients?

While I managed to configure OpenVPN client #2 (since my #1 OpenVPN client is already doing some country redirection for some of my LAN clients) on my Asus Merlin router, I am unable to reach my PI-Hole admin instance at 10.8.0.1/admin from any of my LAN clients.


As it looks like none of my LAN clients (that have an IP address in the 192.168.3.x range) is able to reach my PiHole at 10.8.0.1 running in my GCP instance.

What's wrong? How to fix this?

Thanks for your help.

 

[eibgrad]

Does it work if you temporarily disable the other OpenVPN client (#1)? If so, it could be an IP conflict between the two tunnels (e.g., each is using 10.8.0.0/24).

Make sure you NAT the tunnel of OpenVPN client #2 as well.

 

[Rici]

OpenVPN client #1 needs to stay alive all the time for a handful of clients in my LAN.
These do not need PiHole protection that OpenVPN Client #2 provides

It's just that all remaining clients in my LAN (the majority) should use PiHole of OpenVPN Client #2 as their DNS server.

How to accomplish that?

 

[eibgrad]

I understand that. That's why I said *temporarily* disable OpenVPN client #1, for the purposes of seeing if that is causing a conflict w/ OpenVPN client #2! If you disable it, and things now work wrt OpenVPN client #2, then presumably there is a conflict (e.g., perhaps both happen to be using the same IP network on their respective tunnels (10.8.0.0/24)). It's not unheard of.

IOW, we need to identify the source of the problem before we can correct it.

Wouldn't hurt to dump a few things as well and see if that reveals anything.

ifconfig
ip route
iptables -t nat -vnL
iptables -vnL INPUT
iptables -vnL FORWARD