Hi folks,
I’ve setup my Pi (armv6l) with pihole and pivpn using wireguard but after a week or so It stopped working. Digging a bit revealed that when trying to connect using a client the handshake fails, or at least never happens because the server doesn’t respond. I’ve tried to remove and readd the client but didn’t solve the issue. Rebooting the Pi doesn’t sort any effect and also every traffic that try to use the Pi as dns server doesn’t work. Any idea on where I can search for the culprit?
Hello,
What SBC and version of dietpi do you run?
Is the wireguard service still running?
How do you connect to you server? With your public IP (Is it still valid?) or via a DDNS service? Can you reach this address from the internet?
are you able to reach PiHole web interface? Can you check all LISTEN ports and running services
dietpi-services status
ss -tulpn | grep LISTEN
I’ve a Raspberry Pi Model B (armv6l). Dietpi is updated to the latest version. The update was done something like a week ago and everything was still working correctly afterwards.
I connect using my public address (which I verified and is still the same). I’ve also checked for pivpn in dietpi-software and tried the repair option but nothing changes.
sudo dietpi-services status
DietPi-Services
─────────────────────────────────────────────────────
Mode: status
[ OK ] DietPi-Services | avahi-daemon active (running) since Sat 2022-10-01 21:36:17 CEST; 27min ago
[ OK ] DietPi-Services | nmbd active (running) since Sat 2022-10-01 21:36:20 CEST; 27min ago
[ OK ] DietPi-Services | smbd active (running) since Sat 2022-10-01 21:36:22 CEST; 27min ago
[ OK ] DietPi-Services | php7.4-fpm active (running) since Sat 2022-10-01 21:36:24 CEST; 27min ago
[ OK ] DietPi-Services | apache2 active (running) since Sat 2022-10-01 21:36:25 CEST; 26min ago
[ OK ] DietPi-Services | mpd active (running) since Sat 2022-10-01 21:36:34 CEST; 26min ago
[ OK ] DietPi-Services | minidlna active (running) since Sat 2022-10-01 21:36:34 CEST; 26min ago
[ OK ] DietPi-Services | aria2 active (running) since Sat 2022-10-01 21:36:34 CEST; 26min ago
[ OK ] DietPi-Services | cron active (running) since Sat 2022-10-01 21:36:35 CEST; 26min ago
[ OK ] DietPi-Services | ssh active (running) since Sat 2022-10-01 21:36:14 CEST; 27min ago
[ OK ] DietPi-Services | pihole-FTL active (running) since Sat 2022-10-01 21:36:14 CEST; 27min ago
[ OK ] DietPi-Services | unbound active (running) since Sat 2022-10-01 21:36:14 CEST; 27min ago
[ INFO ] DietPi-Services | dietpi-vpn inactive (dead)
[ INFO ] DietPi-Services | dietpi-cloudshell inactive (dead)
[ OK ] DietPi-Services | dietpi-ramlog active (exited) since Sat 2022-10-01 21:36:11 CEST; 27min ago
[ OK ] DietPi-Services | dietpi-preboot active (exited) since Sat 2022-10-01 21:36:11 CEST; 27min ago
[ OK ] DietPi-Services | dietpi-postboot active (exited) since Sat 2022-10-01 21:36:12 CEST; 27min ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor inactive (dead)
tcp LISTEN 0 50 0.0.0.0:139 0.0.0.0:*
tcp LISTEN 0 1024 0.0.0.0:6800 0.0.0.0:*
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 256 127.0.0.1:5335 0.0.0.0:*
tcp LISTEN 0 256 127.0.0.1:8953 0.0.0.0:*
tcp LISTEN 0 50 0.0.0.0:445 0.0.0.0:*
tcp LISTEN 0 5 127.0.0.1:4711 0.0.0.0:*
tcp LISTEN 0 16 0.0.0.0:8200 0.0.0.0:*
tcp LISTEN 0 5 127.0.0.1:6600 0.0.0.0:*
tcp LISTEN 0 50 [::]:139 [::]:*
tcp LISTEN 0 1024 [::]:6800 [::]:*
tcp LISTEN 0 511 *:80 *:*
tcp LISTEN 0 32 [::]:53 [::]:*
tcp LISTEN 0 128 [::]:22 [::]:*
tcp LISTEN 0 50 [::]:445 [::]:*
tcp LISTEN 0 5 [::1]:4711 [::]:*
tcp LISTEN 0 5 [::1]:6600 [::]:*
Cabn you do sudo ss -tulpn | grep LISTEN, so we can see the users/processes which are listening on that port.
Do you have issues to use PiHole inside your local network as well or just outside of your network?
Here it is
sudo ss -tulpn | grep LISTEN
tcp LISTEN 0 50 0.0.0.0:139 0.0.0.0:* users:(("smbd",pid=597,fd=45))
tcp LISTEN 0 1024 0.0.0.0:6800 0.0.0.0:* users:(("aria2c",pid=699,fd=6))
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=473,fd=5))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=469,fd=3))
tcp LISTEN 0 256 127.0.0.1:5335 0.0.0.0:* users:(("unbound",pid=468,fd=4))
tcp LISTEN 0 256 127.0.0.1:8953 0.0.0.0:* users:(("unbound",pid=468,fd=5))
tcp LISTEN 0 50 0.0.0.0:445 0.0.0.0:* users:(("smbd",pid=597,fd=44))
tcp LISTEN 0 5 127.0.0.1:4711 0.0.0.0:* users:(("pihole-FTL",pid=473,fd=10))
tcp LISTEN 0 16 0.0.0.0:8200 0.0.0.0:* users:(("minidlnad",pid=696,fd=7))
tcp LISTEN 0 5 127.0.0.1:6600 0.0.0.0:* users:(("mpd",pid=691,fd=10))
tcp LISTEN 0 50 [::]:139 [::]:* users:(("smbd",pid=597,fd=43))
tcp LISTEN 0 1024 [::]:6800 [::]:* users:(("aria2c",pid=699,fd=7))
tcp LISTEN 0 511 *:80 *:* users:(("apache2",pid=623,fd=4),("apache2",pid=621,fd=4))
tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=473,fd=7))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=469,fd=4))
tcp LISTEN 0 50 [::]:445 [::]:* users:(("smbd",pid=597,fd=42))
tcp LISTEN 0 5 [::1]:4711 [::]:* users:(("pihole-FTL",pid=473,fd=11))
tcp LISTEN 0 5 [::1]:6600 [::]:* users:(("mpd",pid=691,fd=9))
It doesn’t seems that pi-hole have problem inside local network.
Ok, in this case we assume your local environment is working correctly. The challenge is with your VPN connection. As I understood you don’t see a handshake on Wireguard server side correct? And using wg command is not showing any connection correct? Usually such issues are related to an incorrect DDNS, external IP address or wrong port forwarding on the router. Pls double check that you are using correct connect details and maybe reconfigure router settings.
I’ve checked again IP address and port forwarding and they are correct (not have changed since when it was working). I don’t use DDNS.
I’ve only been able the check log using android app and no handshake is done, yes, basically server doesn’t respond.
You could check with netcat if your wireguard port is reachable from the internet:
nc -vz -u <YourPublicIP> <WireguardPort>
Connection to -- port [udp/*] succeeded!
Obviously I’ve hid the IP and wireguard port
Made some other tests and tried to delete all config for wireguard/pivpn. Results are that now I can connect to the VPN correctly (handshake and all) but still cannot surf the web when connected. So I’m start to think that pi-hole is the real problem.
Did you configured PiHole to Permit all origins? Otherwise PiHole will not accept request from VPN interface.
I’ll check but I suppose so because the all system comprehensive of pi-hole was working more or less a week or two ago. The thing that’s throwing me off is the fact that I’d only updated the system in between working and not working anymore situation but I’m not sure why an update could have make everything not working anymore…
Our update did not touch any of your software title. Maybe there where some apt managed packages updated in parallel.
Have you tried connecting to an external website by IP address, instead of URL?
How can I do that? I don’t know any website by is IP address
You can find a website’s IP address with the dig command. It is provided by the dnsutils package, which is commonly pre-installed on many Linux distributions (you could install on your DietPi box if you’d like with sudo apt-get install dnsutils).
dietpi@nanopiR5S:~$ dig google.com
; <<>> DiG 9.16.33-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15104
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4095
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.65.238
In this example I can see the IP address of google.com is 142.250.65.238. If you put 142.250.65.238 in the address bar of a web browser, you will see it loads https://www.google.com.
The benefit of trying to load a webpage by IP address through your VPN tunnel is if you are successful, then your issue is probably with DNS. If you cannot, then it is probably something else.
1 Like
An easy way is to open https://1.1.1.1/
It can’t be more easier 
2 Likes
Thanks I’ll try it and report back