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


Occasional Visitor
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 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 running in my GCP instance.

What's wrong? How to fix this?

Thanks for your help.


Part of the Furniture
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

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


Occasional Visitor
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?


Part of the Furniture
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 ( 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.

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

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!