Yeah I have it set to listen on all interfaces and permit all origins
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.
I had the same problem, this fixed it
pihole -a -i all
longstory: despite netstat showing FTL listening on 0.0.0.0:53 -- it was not responding on the wg0 interface.
The above command fixed.
I tried this but I still seem to have the issue. If I try to ping the pi-hole from my desktop I still get no response (and DNS requests dont resolve).
It helps to first test with ping and listen with tcpdump to make sure wireguard is routing your traffic.
I've had a number of issues so here are some tips for configuration and testing
Common Issues
- Make sure ip_forward=1
sudo sysctl -w net.ipv4.ip_forward=1
- Make sure your client (e.g. mac or linux laptop) has the firewall turned off
- Make sure your vpn server doesn't have an external firewall (e.g. AWS security group)
- Make sure yoru vpn server kernel firewall is wide open for testing
- Make sure you've added the peer on the server properly. Adding it to the config and using
wg-quick up...does not add the peer . In my experience..
only add using wg set .. peer
sudo wg set wg0 peer XXXXXXXXX allowed-ips 192.168.4.0/24
Testing
Listen for ICMP (pings) on the server
tcpdump -ni any icmp
Ping from client to server
# on client
ping -c200 <ip-addr-of-server>
I added some steps to test that pihole is listening on both interfaces. make sure these work prior to testing over the vpn network
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):
IP 192.168.2.1 > 192.168.1.47 : ICMP host 192.168.1.47 unreachable, length 116
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
In this case make sure that allowed-ips is correct -- that is basically establishing the routing table from server back to client .
e.g.
sudo wg show |tail -n 5
peer: xxxxx
endpoint: xxxx:51820
allowed ips: 192.168.4.0/24
latest handshake: 1 hour, 3 minutes, 22 seconds ago
transfer: 1.32 MiB received, 6.72 MiB sent
here's the cmd I used to set up the peer. I've never had luck configuring the peer within the wg0.conf
sudo wg set wg0 peer xxx allowed-ips 192.168.4.0/24
can you post your ...
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
Routing table before:
root@raspberrypi:/etc/wireguard# sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
routing table after enabling wireguard:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
192.168.2.2 0.0.0.0 255.255.255.255 UH 0 0 0 wg0
192.168.2.3 0.0.0.0 255.255.255.255 UH 0 0 0 wg0
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.
root@raspberrypi:/etc/wireguard# cat /etc/dnsmasq.d/01-pihole.conf |tail
local-ttl=2
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=127.0.0.1#5354
except-interface=nonexisting
hmm to tell you the truth i'm stuck i'd have to do a session with you. A couple of thoughts
- see if you can simplify the route table with using a
/24address for the peer. - see if you can hit the
127.0.0.1:5354and/or replace with 1.1.1.1 while testing. you can use netcat e.g.
netcat -z -v -u localhost 53
netcat -z -v -u localhost 5354
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:
Apr 26 19:36:24 dnsmasq[3567]: failed to send packet: Destination address required
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.
Thanks again for all the help, learned alot!
1 Like
awesome great job debugging
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.