Can't ping pi-hole when connected via Wireguard VPN

Expected Behaviour:

I'm connecting to my home LAN via Wireguard VPN and should be able to ping the pi-hole server. Pi-hole is the only service running on a Raspberry Pi Model 2 B via hardwired Ethernet and the latest Raspberry Pi OS. Wireguard is running on another PC running Ubuntu Server and installed using PiVPN.

Pi-hole is configured with a static IP and is my DNS using Unbound and is also serving local DNS. Also currently set to allow all origins. I do not have a firewall active on the pi-hole. My home router is the DHCP server.

Actual Behaviour:

When connected locally on my LAN, everything works as expected. I can ping pi-hole at 192.168.0.15 and access the web admin page. Pi-hole is functioning properly as my DNS server.
When connected via Wireguard I can ping every single device on my network by IP address, except for my pi-hole server and my router @192.168.0.1. Since I can't see the pi-hole I also don't have a DNS, so I can't open any websites nor do my local domain names resolve. If I connect s using a DNS such as 1.1.1.1 in the client config then I can access websites, but of course I still can't ping the pi-hole.

I've tried a thousand different things and scoured the Internet for answers, but haven't been able to figure it out.

Why would I be able to ping everything on my network except the pi-hole server when connected via VPN?

Debug Token:

I'm typing this remotely so I can't access my pi-hole right now to get the debug info. LOL
But, I can provide this info later.

Pi-hole has its own WireGuard installation guide which gives you full control over what/how/where stuff is configured. I am unfamiliar with "PiVPN" but everything you describe seems to point to the issue being therein.

I fully agree with

What I do right now is assure you that Pi-hole itself does not mess around with any firewall, etc. settings during its regular installation via install.pi-hole.net. So the mere observation that you cannot even ping strongly suggests an issue outside of Pi-hole's sphere of influence.

A few questions (in random order) that came to my mind while reading your ticket:

  1. Are there are network topology differences between your Raspberry Pi and the other devices? Like an extra router or switch in between that isn't there for the other devices (vice versa: do they have extra devices between them and the VPN gateway server)?

  2. How did you setup your Wireguard network? Do remote devices get addresses from the same subnet (192.168.0.*) or do they have their own address range (like 10.0.0.*)? I guess the latter and that your client's config has something like AllowedIPs = ..., 192.168.0.0/24? Or do you force all network traffic through the Wireguard tunnel whilst being connected (AllowedIPs = 0.0.0.0/0)?

  3. How do the routes on your local Ubuntu server (the one that does VPN) look like (both ip route and ip rule)? Are there maybe any exceptions that affect routing to your Pi-hole?

  4. (put your phone into 5G (no WiFi!) and enable Wireguard tunnel for this test) Is it possible to ping devices in your Wirguard network from your local network? Is it possible to ping the same device from the Pi-hole?

  5. Your VPN server will need to have some firewall adjustments to allow traffic from the VPN to cross into the local network and backwards, are they there (what is the output of sudo iptables -t nat -L -v)?

  6. Is IP forwarding enabled on your VPN server (check the output of sudo sysctl -a | grep forwarding)?

Thank you for the detailed reply!
I'll try to answer your questions below.

  1. No network topology differences. All devices on the same network and the Raspberry PI with Pi-hole is hardwired to the same unmanaged switch that the Ubuntu server is connected to.

  2. Client setup:

[Interface]
PrivateKey = …..
Address = 10.54.26.2/24
DNS = 192.168.0.15
[Peer]
PublicKey = ….
PresharedKey = ….
AllowedIPs = 0.0.0.0/0
Endpoint = ….
  1. ip route:
default via 192.168.0.1 dev eno1 proto static
default via 192.168.0.1 dev wlp3s0b1 proto dhcp src 192.168.0.199 metric 600
10.54.26.0/24 dev wg0 proto kernel scope link src 10.54.26.1
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.20
192.168.0.0/24 dev wlp3s0b1 proto kernel scope link src 192.168.0.199 metric 600
192.168.0.1 dev wlp3s0b1 proto dhcp scope link src 192.168.0.199 metric 600
192.168.0.15 dev wlp3s0b1 proto dhcp scope link src 192.168.0.199 metric 600

ip rule:

0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default
  1. With WiFi OFF and phone connected to Wireguard VPN I can ping from phone to 10.54.26.1 (Wireguard server). I can also ping from Wireguard server to 10.54.26.3 (phone). I cannot ping 10.54.26.1 or .3 from the Pi-hole server or from my laptop.

  2. ip tables (I don't know what any of this means....):

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 6738 2863K DOCKER     all  --  any    any     anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  142 37639 DOCKER     all  --  any    any     anywhere            !localhost/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 6047 packets, 414K bytes)
 pkts bytes target     prot opt in     out     source               destination
  158 18099 MASQUERADE  all  --  any    eno1    10.54.26.0/24        anywhere             /* wireguard-nat-rule */
   32  2372 MASQUERADE  all  --  any    !docker0  172.17.0.0/16        anywhere
 1220  226K MASQUERADE  all  --  any    eno1    10.54.26.0/24        anywhere             /* wireguard-nat-rule */
    0     0 MASQUERADE  tcp  --  any    any     172.17.0.2           172.17.0.2           tcp dpt:9443
    0     0 MASQUERADE  tcp  --  any    any     172.17.0.2           172.17.0.2           tcp dpt:8000

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  docker0 any     anywhere             anywhere
   64  4156 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:9443 to:172.17.0.2:9443
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:8000 to:172.17.0.2:8000
  1. IP forwarding report:
net.ipv4.conf.all.bc_forwarding = 0
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.bc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.docker0.bc_forwarding = 0
net.ipv4.conf.docker0.forwarding = 1
net.ipv4.conf.docker0.mc_forwarding = 0
net.ipv4.conf.eno1.bc_forwarding = 0
net.ipv4.conf.eno1.forwarding = 1
net.ipv4.conf.eno1.mc_forwarding = 0
net.ipv4.conf.lo.bc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.veth90c8165.bc_forwarding = 0
net.ipv4.conf.veth90c8165.forwarding = 1
net.ipv4.conf.veth90c8165.mc_forwarding = 0
net.ipv4.conf.wg0.bc_forwarding = 0
net.ipv4.conf.wg0.forwarding = 1
net.ipv4.conf.wg0.mc_forwarding = 0
net.ipv4.conf.wlp3s0b1.bc_forwarding = 0
net.ipv4.conf.wlp3s0b1.forwarding = 1
net.ipv4.conf.wlp3s0b1.mc_forwarding = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.docker0.forwarding = 1
net.ipv6.conf.docker0.mc_forwarding = 0
net.ipv6.conf.eno1.forwarding = 1
net.ipv6.conf.eno1.mc_forwarding = 0
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.lo.mc_forwarding = 0
net.ipv6.conf.veth90c8165.forwarding = 1
net.ipv6.conf.veth90c8165.mc_forwarding = 0
net.ipv6.conf.wg0.forwarding = 1
net.ipv6.conf.wg0.mc_forwarding = 0
net.ipv6.conf.wlp3s0b1.forwarding = 1
net.ipv6.conf.wlp3s0b1.mc_forwarding = 0

I hope this helps diagnose the problem and thanks in advance!

Yeah, I guess it brings us closer - more questions:

  • Do you have wired Ethernet and WiFi connected at the same time? This may cause issues with packets going into your network being lost if they go over WiFi - there is only one MASQUERADE rule (well actually the same one is doubled due to some PiVPN issue) and this one operates on wired Ethernet.
    There is no point in being in the same subnet with two distinct interfaces. Please try disabling WiFi as the first thing you do while debugging this, it may easily solve the issue
  • Since your PiVPN configuration is rather different to, e.g., mine: you are "shielding" your Wireguard devices from your other network devices (instead of integrating them next to them as I'm doing, for instance), it is expected that non of the devices in your local network (except the VPN server) can ping any Wireguard devices. Please try to ping any further devices from your Wireguard-connected phone, e.g., the laptop
    If you are unable to do this even after disabling WiFi, we have to become creative again.

You nailed it! As soon as I disabled the WiFi I was able to ping the Pi-hole from my Wireguard connected phone (5G ON, WiFi OFF). Actually my stupid ISP modem/router is so locked-down I couldn't disable the WiFi, so I just changed the SSID temporarily so that no devices were connected.

Then I realized that maybe you were referring to WiFi on my Ubuntu server!
I didn't think of this at first, because I thought that I had turned the WiFi radio off already, but when I checked it was actually ON. So then I disabled the radio on the Ubuntu Server (running Wireguard) and everything worked perfectly!

I can't thank you enough!
I'm not sure I ever would've figured this out on my own.

Thank you so much for helping a stranger :slight_smile:

1 Like