DietPi-Software | PiVPN + Pi-hole connection issue

[dkdhanda8]

wireguard not showing in dietpi software install

[MichaIng]

@dkdhanda8
Thanks for your report. Which machine are you trying this?

Note that WireGuard is not yet supported for all SBCs, e.g. ARMv6 RPis are generally not supported, for Pine64 SBCs we didn't manage to fix a Python error on build process and for some NanoPi and others we simply didn't find the time the test the build process thoroughly.

[dkdhanda8]

I am currently using ARMv6 RPi B+ .

[dkdhanda8]

Instead of wireguard i have setup pivpn now but i am not able to connect to it on my laptop or phone , i have routed the port through router ( also installed pihole if thats causing conflict) , could you help me configer it ? , pivpn -d was showing forwarding disabled but now its enabled still , its not connection .

[MichaIng]

@dkdhanda8
Please paste:

ip a
ip r

[dkdhanda8]

@MichaIng

root@DietPi:~ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:4c:30:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.5/24 brd 192.168.2.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe4c:304e/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::2a9d:586e:8c8d:d918/64 scope link flags 800
       valid_lft forever preferred_lft forever
root@DietPi:~ip r
default via 192.168.2.1 dev eth0 onlink
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.5

[MichaIng]

@dkdhanda8
Looks good so far. OpenVPN is up without errors?

journalctl -u openvpn

And how do you try to connect from your clients? Any errors messages there, and can they ping the server via its external domain/IP?

[dkdhanda8]

root@DietPi:~# journalctl -u openvpn
-- Logs begin at Thu 2016-11-03 17:16:44 GMT, end at Thu 2019-06-20 15:47:52 BST. --
Jun 20 14:53:41 DietPi systemd[1]: Starting OpenVPN service...
Jun 20 14:53:42 DietPi systemd[1]: Started OpenVPN service.

[dkdhanda8]

Trying to connect via openvpn connect , it just shows waiting for server

[MichaIng]

@dkdhanda8
Since the VPN server itself is up, no errors, tun0 configured etc, it must be a network issue at some stage:

1. Try to ping the server from local network via local IP/hostname: ping 192.168.2.5
2. Try to connect to VPN from local network via local IP/hostname
3. Try to ping from outside local network via external IP/domain
4. Try to connect from outside local network via external IP/domain

[dkdhanda8]

Server is online , can be pinged locally.
How to connect to vpn via local ip/hostname ? I just know about importing .ovpn file

[MichaIng]

@dkdhanda8
In the .ovpn file change the line remote <your_public_IP> 1194 to remote <your_local_IP> 1194, before importing.

[dkdhanda8]

@dkdhanda8
In the .ovpn file change the line remote <your_public_IP> 1194 to remote <your_local_IP> 1194, before importing.

connecting locally but not outside network

[MichaIng]

@dkdhanda8
Hmm, but ping from outside local network works well? Did you assure that UDP (or both, TCP and UDP) port 1194 is/are forwarded to the VPN server?

[dkdhanda8]

i tried reinstalling pivpn with noip and pihole , now getting DNS_PROBE_FINISHED_BAD_CONFIG error

[MichaIng]

@dkdhanda8
Might be a DNS cache issue, try: pihole restartdns

You get this error on the server itself or on the VPN clients?

Verify as well that upstream DNS from the server is working, e.g. also by using other tools: curl dietpi.com
Check that /etc/resolv.conf contains 127.0.0.1 (loopback to pihole-FTL) and the configured DNS upstream is reachable.

[dkdhanda8]

I had to go on vacation and dont have access to my rpi , ty for the help ill check this next week.

[dkdhanda8]

root@DietPi:~# curl dietpi.com
curl: (6) Could not resolve host: dietpi.com

/etc/resolver.conf contains 127.0.0.1

[MichaIng]

@dkdhanda8

/etc/resolver.conf contains 127.0.0.1

You mean /etc/resolv.conf, right?

Is Pi-hole up without issues? journalctl -u pihole-FTL

[kamilmirza]

I had the same problem (few months back) and gave up after many tries, shifted OpenVPN on my ASUS router
thought pihole was the culprit - even tried PiVPN on fresh dietpi installs
tried it rpi 3B and 3B+ but alas
vpn server does not respond remotely, with port open and all
have spare rpi 3B lying around and can help you find the bug

[MichaIng]

Hmm I can't imagine this to be that difficult. Haven't tried with PiVPN for a longer time, but with OpenVPN and WireGuard. Basically the VPN server and Pi-hole should not affect each other, besides having localhost/127.0.0.1 as DNS nameserver entry required server side, and on the VPN clients it should be the VPN server IP, e.g. 10.8.0.1. Not sure which one is applied there by default, but 127.0.0.1 on the clients of course cannot work.

[kamilmirza]

as I recall correctly, the conf file used tun0 address not localhost

[MichaIng]

@kamilmirza
Okay, I have to run some local tests then.

EDIT

For reference: https://github.com/MichaIng/DietPi/issues/1245
And it makes sense to use the local network IP of the Pi-hole server as DNS for the VPN clients, instead of the tun0 IP, to prevent some forwarding. Of course after being connected this is available anyway.

[tey-tuason]

Experiencing the same issue except that I don't have pihole running in my system yet and /etc/resolv.conf only contains 192.168.1.1 (gateway of my network).

[Joulinar]

@tey-tuason
what issue you exactly experiencing. That your VPN clients not able to connect to the internet ??

[tey-tuason]

Similar to the issue here , I have piVPN and WireGuard both set-up and port forwareded but the clients are unable to connect if outside the same network.

[Joulinar]

Ok do you have an issues with both VPN Server? Or is one of them working?

[tey-tuason]

Both of them are having the same problem

[Joulinar]

would that be an option to remove PiVPN. Than we could try fixing WireGuard? Usually both should be independent. But let's stay on safe side 😄

[tey-tuason]

Tried removing piVPN but to no avail

[Joulinar]

what was the error massage?

[MichaIng]

@tey-tuason
Lets investigate one-by-one, although most likely the issue with both VPNs is the same.

You installed both, WireGuard and PiVPN via dietpi-software?
To debug WireGuard for now:

ip a
ip r
journalctl -u wg-quick@wg0

[tey-tuason]

@MichaIng
Yep, used dietpi-software to install both but I have piVPN uninstalled for now but would like to have both installed soon in production. The results for the commands are as follows:

root@home:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:1f:6f:a8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.110/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.9.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever
root@home:~# ip r
default via 192.168.1.1 dev eth0 
10.9.0.0/24 dev wg0 proto kernel scope link src 10.9.0.1 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.110 
root@home:~# journalctl -u wg-quick@wg0
-- Logs begin at Thu 2019-02-14 18:11:58 PST, end at Mon 2020-01-06 11:15:15 PST. --
Jan 05 21:34:43 home systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Jan 05 21:34:43 home wg-quick[654]: [#] ip link add wg0 type wireguard
Jan 05 21:34:43 home wg-quick[654]: [#] wg setconf wg0 /dev/fd/63
Jan 05 21:34:43 home wg-quick[654]: [#] ip -4 address add 10.9.0.1/24 dev wg0
Jan 05 21:34:43 home wg-quick[654]: [#] ip link set mtu 1420 up dev wg0
Jan 05 21:34:43 home wg-quick[654]: [#] sysctl net.ipv4.conf.wg0.forwarding=1 net.ipv4.conf.$(sed -n 3p /DietPi/dietpi/.network).forwarding=1
Jan 05 21:34:43 home wg-quick[654]: net.ipv4.conf.wg0.forwarding = 1
Jan 05 21:34:43 home wg-quick[654]: net.ipv4.conf.eth0.forwarding = 1
Jan 05 21:34:43 home wg-quick[654]: [#] sysctl net.ipv6.conf.$(sed -n 3p /DietPi/dietpi/.network).accept_ra=2
Jan 05 21:34:43 home wg-quick[654]: net.ipv6.conf.eth0.accept_ra = 2
Jan 05 21:34:43 home wg-quick[654]: [#] sysctl net.ipv6.conf.wg0.forwarding=1 net.ipv6.conf.$(sed -n 3p /DietPi/dietpi/.network).forwarding=1
Jan 05 21:34:43 home wg-quick[654]: net.ipv6.conf.wg0.forwarding = 1
Jan 05 21:34:43 home wg-quick[654]: net.ipv6.conf.eth0.forwarding = 1
Jan 05 21:34:43 home wg-quick[654]: [#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o $(sed -n 3p /DietPi/dietpi/.network) -j MASQUERADE
Jan 05 21:34:43 home wg-quick[654]: [#] ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o $(sed -n 3p /DietPi/dietpi/.network) -j MASQUERADE
Jan 05 21:34:43 home systemd[1]: Started WireGuard via wg-quick(8) for wg0.

[tey-tuason]

Sorry, I don't know how to make the terminal output appear neat so I just attached a screenshot

[Joulinar]

@tey-tuason
the port you forwarded on your internet router is UDP or TCP?

[tey-tuason]

@Joulinar
Both

[Joulinar]

pls use UDP only for VPN connections. Default port for WireGuard is 51820 UDP but maybe you changed it.

[tey-tuason]

@Joulinar Changed it to UDP only but the problem is still there.
I'm afraid I might be hijacking the thread. Please let me know if I should just open a new issue

[MichaIng]

@tey-tuason

I'm afraid I might be hijacking the thread. Please let me know if I should just open a new issue

No worries, lets stay here.

So the WireGuard service starts up pretty well. Did I understand it correctly above that connections from inside the same local network to the WireGuard server work fine?

To debug, the wg command shows all peers and connection state, does it show an updated timestamp when you try to connect from a peer outside the local network?
If not, could you check if actually anything is reaching the server, e.g. via iftop or iptraf-ng?

[tey-tuason]

@MichaIng

Yes. As long as I'm connected to the same network, I'm able to connect to the WireGuard server.

I'm not that familiar with iftop or iptraf-ng but I tried connecting to the WireGuard server from outside the network and tried to see if I could see any connections corresponding to the port the server is running and sad to say that I didn't see any

[Joulinar]

hmm that could indicate that there is an issue with port forwarding on your internet router or some client config issues. As well MTU size could be an issue.

Question: if you try to connect from outside network, are you able to see the connection established using wg command on your WireGuard Server or is there no connection visible at that time?

[MichaIng]

I also bet either port is not correctly forwarded (UDP) or some firewall/filter on router or proxy (if used) or ISP (?) side blocking it. Changing the port would be another try.

[tey-tuason]

It seems that the issue really lies with the forwarding. I've tried with other services and they too are not being reached outside my network. Tried to upgrade and reset my router but to no avail. I'll report back as soon as I settle this issue seeing that the problem might be on my network and not on my DietPi installation

[MichaIng]

Closing this in favour of #1245, generally implementing some whiptail-based GUI to configure the VPNs correctly for purposed use would be the solution IMO.