DietPi-VPN in 7.1

General Discussion
1

Hi,

I’m currently running DietPi 7.0.2 on a Pi Zero (CLI / Headless). I have ProtonVPN installed using https://protonvpn.com/support/linux-vpn-tool/ method (community Python CLI Tool). Looking at the release notes for 7.1, I see that DietPi-VPN now natively supports ProtonVPN, so I am wondering if I should configure-purge then pip3-uninstall before running the update to 7.1? The Python tool takes a long time to connect/disconnect on the Pi Zero, so I am assuming that the native DietPi-VPN will be much more responsive?

Thanks in advance for any advice, and for such an awesome Linux distro! :slight_smile:

2

Hi,

basically DietPi-VPN is not using the ProtonVPN client tool. DietPi-VPN will setup a simple OpenVPN client and use ProtonVPN config file to connect. Therefore you can keep ProtonVPN client but would need to ensure it stays disabled. Otherwise you would have 2 clients trying to connect to ProtonVPN :slight_smile:

3

Hi,

Thank you for the quick reply. I thought it would be using OpenVPN rather than the Proton tool, but wanted to check first. :slight_smile:

4

Also the ProtonVPN CLI tool uses OpenVPN, just the configuration frontend is Python + command prompt based, instead of bash + whiptail dialogue based like ours.

The idea in our case was to have a slim generic transparent script for all OpenVPN-based public VPN provider connections, based on the DietPi-NordVPN script that we already had. So one is able to switch between different providers while keeping UI, setup, features the same. This is a good basis to add additional features like split-tunnelling (tunnel only specific applications/users and/or allow remote connections to that DietPi system while it’s connected to the VPN), regular server (or even provider-) rotation, and such, which are often difficult to achieve with the providers tools.

5

On the subject of additional features, do you think a toggle switch to enable/disable a ‘gateway’ from local traffic to vpn would be possible?

For example, my Pi is at 192.168.1.4, and the router gateway is 192.168.1.1. PiHole listens on 192.168.1.4 so that is set on other devices as their DNS server, with the gateway being 192.168.1.1.

If the toggle switch enabled something similar to (below is copy/paste from a tutorial):

sudo /bin/su -c “echo -e ‘\n#Enable IP Routing\nnet.ipv4.ip_forward = 1’ > /etc/sysctl.conf”
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -P FORWARD DROP
sudo iptables -P INPUT DROP
sudo iptables -L

So other devices on the network could have 192.168.1.4 set as both DNS & Gateway, and benefit from having their traffic routed via a single VPN connection on the Pi and easily enabled/disabled by a toggle switch in the DietPi-VPN software. As the DietPi-VPN software knows which interface is local (eth0, eth1, wlan0, etc), and which is VPN (tun0, etc) it could be set for a range of configurations, rather than using something like the above in a script file, edited to match the individual system.

It’s just a thought, and I appreciate you are all very busy with more important features, but I thought it was worth a mention. My bash scripting knowledge is almost zero, otherwise I would have had a go at coding the above.

Thanks again. :slight_smile:

6

Yes that is clearly a good feature. This is basically included when using the WiFi hotspot install option, but targeting the Ethernet interface as output instead of the VPN tun0 interface. Also when enabling the killswitch those rules are overridden, AFAIK.

Probably we can make DietPi-VPN detect an enabled WiFi hotspot and adjust the NAT rules to use the VPN + make the killswitch incorporating them.

Another task is the network setup rework (dietpi-config) to allow enabling not only a WiFi hotspot but an Ethernet gateway as well.

7

Following on from the above, I decided to have a look at the source-code to DietPi-VPN to see if I could figure out what it was doing, and a couple of things occurred to me, so I fired up the new 7.1 in a virtual machine. Sadly there are a couple of issues when setting up a ProtonVPN account.

With ProtonVPN, there are multiple levels of server access:
Free 0
Basic1
Plus 2
Visionary (but that is irrelevant to the VPN server choice)

When DietPi-VPN gets a list of the ProtonVPN servers in:
110 G_EXEC curl -sSfLO ‘https://api.protonvpn.ch/vpn/logicals’

It then parses the file by Domain to create a list of servers to connect to:
114 sed ‘s/“Domain”:"/\n/g’ logicals | mawk -F" ‘NR % 2 == 0 {print $1}’ > $FP_PROTONVPN_SERVERS

For example, if you look in https://api.protonvpn.ch/vpn/logicals at #318, which is the NL#25 server, you will see the server name is listed in the drop-down as [nl-25.protonvpn.com]. If you have a free account then you will not be able to connect to this server, as shown in the ‘Tier’ section it is 1 (Basic). Also in the ‘Features’ it has 4 - which indicates it allows P2P traffic, and in ‘Load’ it indicates the current server load in %.

So the problem with selecting a server from the dropdown, is that unless you are a Plus or Visionary subscriber, then you will be taking a random guess if you can connect to that server from a choice of 1200+ servers.

To give a meaningful list of servers to select, you would need to ask the user what subscription plan they have and parse the list by Tier<=plan. That would give a list of connectable servers, but still not indicate what that server is capable of offering (P2P, TOR over VPN), so ideally it should parse the Features number to indicate server features too. Ideally adding Load would give even more information. The ideal server list (imho) would look something like (if you were a Plus subsciber):

[NL#25 Basic P2P 73%]
[NL#26 Plus P2P 25%]
[UK#17 Basic 54%]
[US-FREE#1 Free 98%]

or (if you were a Basic subscriber):
[NL#25 Basic P2P 73%]
[UK#17 Basic 54%]
[US-FREE#1 Free 98%]

and (free user):
[US-FREE#1 Free 98%]

I haven’t been through the server list to see what all the Feature numbers equate to in relation to server features, but 0 is nothing extra and 4 is P2P. If there’s a need, I can work out the others. I’ve written a couple of GUI monitoring programs for the ProtonVPN CLI tool in the past, but have never worked with Bash scripts.

8

so ideally it should parse the Features number to indicate server features too. Ideally adding Load would give even more information

This could be achieved with a script like this, where jq parses the output of the curl command

#!/bin/bash
curl -sL "https://api.nordvpn.com/v1/servers/recommendations?&filters\[servers_technologies\]\[identifier\]=wireguard_udp&limit=1" \
| jq -r '.[]|.hostname, .station, (.locations|.[]|.country|.city.name), (.locations|.[]|.country|.name), (.technologies|.[].metadata|.[].value), .load'

This particular example generates relevant wireguard parameters from Nordvpn for the recommended connection, including Load, e.g.:

  • nl927.nordvpn.com
    213.152.188.79
    Amsterdam
    Netherlands
    5p4RkybdRU5uaDi90eu4KZPTFif0lKCg4Qp6t1c4F30=
    5 (Load)

But I am not an expert, just groping in the dark looking to combine Nordvpn with my running DietPi/PiVPN/wireguard installation.

9

There shouldn’t be any conflict between your PiVPN/Wireguard installation and the DietPi VPN as both use complete different VPN methods. You install PiVPN using the Wireguard protocol, while DietPi VPN is using OpenVPN. Next to it, PiVPN is acting as server while DietPi VPN is a client who is going to connect to a public VPN provider.

Even if both are able to run next to each other, it could create challenges with the VPN interfaces. Incoming traffic (via your public internet IP/DDNS) will go a different way compare to outgoing traffic (via VPN provider). Usually there are tweaks inside iptables needed to be able to run both in parallel.

10

DietPi VPN is using OpenVPN

is indeed useful information. Thank you very much for your feedback and support!

while PiVPN is a client who is going to connect to a public VPN provider

I guess you mean NordVPN?

11

Sorry a typo or autocorrection on my mobile phone :rofl:

It should be DietPi VPN. I corrected my statement above