Hi Everyone, I have another wireguard question. I have configured wireguard on my pihole and clients and I am able to connect to the pi-hole via wireguard. The connected client has access to the internet through the wireguard server (pi-hole) and is using the pi-hole as the DNS server.
My problem is the following:
When I activate the wireguard interface on the server (my pi-hole), immediately none of the other machines on the LAN with my pi-hole can access the pi-hole for DNS requests. If I try to ping the pi-hole from a machine on the LAN that is not connecting through wireguard (because its on the LAN) it gets no response. If close the wireguard interface the issue immediately resolves. Additionally the problem starts as soon as the interface is opened on the server (pi-hole), clients do not need to be connected for the problem to manifest.
I was wondering if the server address should be the address of the pi-hole? Currently my pi-hole is 192.168.1.39 which is the address handed out by my router for the LAN DNS, but wireguard is configured to have the server interface of 192.168.2.1 on a different subnet. Changing this didnt seem to help but wondered if there was some additional configuration needed.
So I've confirmed that ip_forward=1 is reporting as 1. Ill try some of these client side tests, but I'm confused as to why the client configuration would affect the server when no clients are connected.
Just to make sure it wasn't misunderstood, my issue is that when wireguard is enabled using this command:
sudo wg-quick up wg0
No other PC's on the LAN are able to talk to the raspberry pi. The other computers are not trying to communicate over wireguard because they are already on the LAN and dont need a VPN. Once I disable wireguard with:
sudo wg-quick down wg0
All LAN PC's can again get responses from the pi-hole again. I can basically have all my remote wireguard clients working with no issues, or the local LAN machines working, but not both.
So checked with TCPDUMP and I'm seeing strange behavior. As soon as I enable the wireguard server I see the following over and over again (192.168.1.47 is another PC on the LAN not using wireguard which loses access as soon as wireguard is enabled):
If I observe the ping request from .1.47 to .1.39 it looks the same whether wireguard is on or off, however when wireguard is on the .1.47 never receives the reply that TCP Dump is showing
Thanks i think i better understand your issue now.
I would check your routing table before and after wg-quick up & wg-quick down
e.g.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 202 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
pi@piholezero:/etc/dnsmasq.d $ netstat -tulnp|grep -i list
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
Also tail -f /var/log/pihole.log while you do both tests to see if it shows replies as blocked
cat /etc/dnsmasq.d/01-pihole.conf |tail
log-async
# If a DHCP client claims that its name is "wpad", ignore that.
# This fixes a security hole. see CERT Vulnerability VU#598349
dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore
server=1.1.1.1
server=1.0.0.1
except-interface=nonexisting
Server is listed as follows because outgoing DNS requests to the upstream server are handled through dns crypt proxy before being forwarded on to 1.1.1.1. I dont think this would cause any issue because the wireguard clients have no problems with DNS requests when connected to the server.
Thanks for all the help. Ill give that a try. Yeah I checked the pihole log too and its constantly filling with this when the wireguard server is enabled:
I have been able to narrow down what the issue is. If I comment out the Peers in the server configuration file I am able to ping the pi-hole and make dns requests when the wireguard server is "up"
Ok I think I have resolved the issue. in the server's allowed IP's I had 192.168.1.1/24. This should have been in the client .conf file in the peers allowed IP's section, not the servers .conf file.