Wireguard VPN connection not resolving local host names

Question

I have setup a Wireguard VPN on my raspberry pi and I can connect to it via client app on my mobile phone. I can access the internet though the phone and I confirm that the phone is using the same IP of the raspberry pi, so the VPN is working for the outer internet.

But I have a local webserver on my Pi, which I can access on the pi using a direct internal IP (192.168.1.50), using raspberrypi.local hostname, or by using a custom host defined in /etc/hosts file.

However, in the phone and over VPN I can only access that local webserver over the internal IP: raspberrypi.local or any other hostname defined in /etc/hosts does not work.

How can I resolve this?

Answer 1

I've indirectly solved this issue by installing Pi-Hole, setting up local hosts there and enabling it as the DNS server for all my clients. Now I can access my home network via VPN with local hostname resolution + added benefit of DNS level ad blocking.

Pi-Hole and Wireguard VPN play very nice with each other (Pi-Hole detected Wireguard and offered to do all configurations by itself).

Answer 2

I have a hostname that I can resolve as "hostname.local" while I am connected directly to my LAN.

When I am connected via wireguard, I can only reach the hostname by appending a period (or dot) after the hostname: i.e. "hostname."

While connected through wireguard:

ping hostname.local    (doesn't work)
ping hostname.         (works)

Answer 3

On my home network, my Vodafone router handles resolving the .local (and .broadband) hostnames, which works at home because my devices use the router as their DNS server.

So, to get this working on my Wireguard client, I just had to manually set the DNS server to my router's IP address in Wireguard settings (DNS servers on Android)

Screenshot of the Wireguard interface settings on Android

Pinging my Raspberry Pi (with hostname rpi) worked when using rpi, rpi. and rpi.broadband. While rpi.local didn't work when connected from my phone, the .local TLD often doesn't resolve properly on Android anyway, so this was expected.