dietpi-nordvpn "killswitch" feature ?

General Discussion
1

Hello all

I just put up the dietpi-norvpn module on my dietpi-raspberrypi3.
First thing I checked is wether it keeps the configuration and re-establishes automatically the connection upon reboot and yes, it does it :sunglasses: Good start.

What I would also like is a “killswitch” feature much like the windows client has.
The purpose of the game is making sure at least that certain processes, if not the entire machine, are “killed” if the nordvpn connection goes down, is disabled, or its process is killed.

The idea is being able to “rely” on the fact that this machine is “behind a vpn” and leave it working unattended, knowing that if the vpn “goes down” the machine (or at least some services inside it, e.g. torrent etc) “stops communicating”.

Anyone has developed something already?

2

uga
Many thanks for your request.

Indeed a killswitch feature would be great. Currently we have this optionally commented in our WireGuard client configs, but not yet for OpenVPN/NordVPN. The following should work:

On start:

iptables -I OUTPUT ! -o tun0 -m addrtype ! --dst-type LOCAL -j REJECT
ip6tables -I OUTPUT ! -o tun0 -m addrtype ! --dst-type LOCAL -j REJECT

On stop:

iptables -D OUTPUT ! -o tun0 -m addrtype ! --dst-type LOCAL -j REJECT
ip6tables -D OUTPUT ! -o tun0 -m addrtype ! --dst-type LOCAL -j REJECT

So all packets that are not sent to tun0 (VPN interface) AND that are not sent to a local IP, are rejected.

3

:thinking:

Let me see if I understand properly: those rules should be inserted if dietpi-nordvpn is “installed” (be nordvpn “connected” or not), and deleted if dietpi-nordvpn is uninstalled.

This way, a dietpi machine with dietpi-nordvpn on it will be able to communicate with anything outside its LAN if and only if a nordvpn connection is up.

Right?

4

Exactly. A bid more precisely: The rejection of the packets are bound to the used network interface. tun0 is the OpenVPN interface so as a result this needs to exist and being connected.

When you apply is a question how you need it:

  • You could add it as start/stop hooks to the dietpi-nordvpn.service so when manually stopping the VPN the killswitch is stopped as well.
  • Or you apply as ifupdown hook, so it is always up as fast as any network interface is configured.

I am not yet 100% sure how we implement it. I think we will add a switch to the DietPi-NordVPN menu to enable/disable it from boot on via ifupdown hook.

5

In the meanwhile I noticed that the guys at NordVpn did develop a Linux client package, which includes a killswitch and also other features.

Why didnt you simply adopt theirs ? (question might sound silly, but it’s an honest one)

6

Hmm, I had the impression first that it is a desktop GUI based client, but it is not. It does not use OpenVPN, however is clearly more heavy weight than out solution and does not have a cmdline GUI (whiptail/dialog). But yeah it provides killswitch. Not sure if it allows to connect to the device directly, bypassing the VPN to allow e.g. web application usage?

So indeed worth it to have a closer look, many thanks for providing the info. However my aim is to make DietPi-NordVPN a more general VPN client implementation by times to implement more VPN providers and features. Since it uses OpenVPN we can freely configure it to our needs and implement such features like enabling VPN bypass for web applications and such.

7

Sorry to repoen an old post


I am using the nordvpn app so as to utilise the wireguard connection type (the speed difference compared with ovpn being the sole reason)

I am essentially looking for either an iptable rule such as that above, or a simple script to kill a service and therefor create a de facto killswitch to deluged.

I am a linux noob, apologies.

When I add the iptable rules above (changing tun0 to nordlynx as that is the network interface name) it kills all connectivity (local and wan) i can’t even ping my router.

I note that the nordlynx interface shows ‘UNKNOWN’ state. not up or down, but only exists as an interface when the connection is up.

So essentially i want to either run a script to kill my deluged service if the ‘nordlynx’ inteface does not exist, or a persistent iptable rule that will only allow WAN traffic when the nordlynx interface exists.

I had toyed with the idea of a script that only allows deluged to run when the Nordvpn service is running, but the service runs even when the actual connection has been dropped.

I’ve seen another thread in here that uses a cron job to ping a specific interface, but tbh it was all a bit over my head!

apologies again, i’m sure i’ve not explained this sufficiently well or provided specific enough information.

In summary i would like to achieve

  • LAN access for samba/ssh at all times (regardless of VPN state)
  • WAN access only when the network interface ‘nordlynx’ exists

I’m not too concerned about having to manually restart everything if the nordlynx interface is lost, my primary concern is not to end up with deluged accessing eth0 and revealing my IP. Obviously if everything could be set up to come back online automatically then that would be great.

I have also read that the dietpi wireguard has a built in killswitch, but i understand that i would need to manually configure access via wireguard and at present Nordvpn do not provide configuration files. Also i would like to retain the function of the nordvpn app where the ‘best’ server is selected rather than permanently choosing a single server and then writing any iptables rules for that specific ip address

8

ok apologies for the double post (and indeed the general quality of my first post).

Anyway, i think i have successfully managed to modify a script posted by joulinar in another post to suit my needs. basically ping google through the inteface set up by the Nord app for wireguard (nordlynx).

seems straightforward enough. i’m dumping it in cron minutely (if i wanted it more regularly i suppose i could repeat the code with sleep 15 commands between each, though i’m not sure how resource intensive this would be


#!/bin/sh

# Check vpn-tunnel "nordlynx" and ping google DNS if internet connection work
if  [ "$(ping -I nordlynx -q -c 1 -W 1 8.8.8.8 | grep '0% packet loss' )" != "" ]; then
        
# if-up commands	
	echo "vpn up"
else
#if-down commands
       echo "vpn down"
fi

thanks

9

thx for sharing your solution.

10

Hello,

Apologies for going off-topic here, but I found this topic and had a question. For those using nordvpn on a Raspberry Pi, is it stable for you?

I used to run nordvpn on my Pi 24/7 and after 1-2 days, nordvpn would completely “freeze”, or stop working. It would be eternally reconnecting, and cut of all access to the internet except whitelisted domains and ports.

nordvpn disconnect, reconnect

etc. nothing would work. Only way to fix it would be to kill the

nordvpnd.service

and restart it. Is this with just me?

11

Hi.
I’ve had a couple of ‘worst case scenario’ situations where NordVPN has simply disconnected without warning. I think I was completely exposed for at least 7-8 hours before I noticed (this was before I had implemented my cron script above to kill deluge).
But I think this was user error, I set a startup script to launch nord on startup before realising that it was launching itself anyway, so perhaps that was causing problems?
At any rate though, I have never struggled with anything that wouldn’t be resolved by a quick ‘NordVPN c’ command.
Nord is clearly less stable than my previous provider (airvpn using their lightweight hummingbird client), but nord seems to be the only ‘out the box’ wireguard provider for the pi.

12

I was looking into a way to implement NordVPN WireGuard (NordLynx) into dietpi-nordvpn, but there is the fundamental issue of WireGuard that each client is assigned a single static IP address (for the VPN network only of course). So theoretically one can track actions of a single user by watching connections from a single IP, when having access to connection info of course.

Each VPN provider has its own method to work around this privacy issue, often via config generators which create short-term configurations (with IP and keys) that hence need to be re-created regularly and re-applied to all clients. NordVPN has a double NAT method implemented to randomise IP addresses and I don’t think that there is or will be a public API to use this with the official standard WireGuard tools in a way.

Sad that a dynamic IP range was not thought about right from the start with the WireGuard protocol. If you control your own server, that is not an issue, but for public VPN providers that is a real privacy concern: Not a single (reasonable large) VPN provider uses the WireGuard protocol as it is and lets customers create and use keys+config the regular war. A nice overview can be found here: https://vladtalks.tech/vpn/list-wireguard-vpn-providers
A bit too long repeating around the point, but at the end you get the info: https://restoreprivacy.com/vpn/wireguard/

Native WireGuard solution is work-in-progress: https://git.zx2c4.com/wg-dynamic/about/docs/idea.md

13

update

while the script that i shared earlier worked well as a fundamental “is the interface running” check, i suspect that i am not the only user to find that the NordVPN connection is
 er
 inconsistent. I have found this to be true when using the NORDvpn app in either OVPN or WG protocol. This is also an issue using the Dietpi-vpn method (ovpn config files). i think this may be partly due to the unreliability of a given server at Nord’s end, and the lack of ability to choose a ‘cluster’ of servers and have the connection self select to the best server available (as the app theoretically does).

The real PITA is that nordlynx protocol is just so much faster

anyway, so this all leads me to my latest ‘solution’

once the server goes down using NORDlynx, i have found no solution to reinstate a connection without a full reboot of the pi (yes, i have tried almost everything i can think of to avoid this ‘nuclear’ option - resetting the network interface doesn’t even do the job)

My previously shared script doesn’t pick up the problem of the interface being ‘up’ but with no packets actually transmitted (i’m sure that it should, but it doesn’t - my grep game is pants and i suspect there’s an error in there somewhere)

anyway, the following script, dumped into /etc/cron.minutely, made exectuable WITH NO “.SH” at the end does a fine job of essentially catching a dead nordlynx server and then performing whatever remedial action you may choose. in my case, stop deluged (purely to avoid torrent ‘errors’ of rebooting with the service running - there’s no risk of an IP leak in this scenario - though the following script would also catch a dead interface)


count=$( ping -I nordlynx -c 1 8.8.8.8 | grep icmp* | wc -l )

if [ $count -eq 0 ]
then
    systemctl stop deluged
     cd /mnt/14TB/reboot_logs
    touch "rebooted_at_$(date +"%F %T")"
    reboot


else

    echo "Host is Alive!"

fi

note, i also create a basic log of each time this happens (currently about every 5 hours :frowning:

i also note that this issue (connected to the interface, but no traffic) only appears to have become an issue since V7 of dietpi) - i can’t imagine it is related (though v7 brought all sorts of changes that i didn’t really understand to vpn/networking
)

anyway, hope this will help someone out there (if not me in a few months when i need to refer back to the script!)

14

Well DietPi has no influence if you are using nordlynx as this is an own client best to my knowledge.

Dietpi-VPN themselves is not an own VPN client or protocol. This is just a bash script doing nothing else than installing OpenVPN as client and use a ovpn config files to connect to a public VPN provider. Next to this some iptables rules are setup to create a killswitch.

15

Side note: SSH support has been added to the killswitch with DietPi v7.3. You need to hit “Apply” once again to install the new rules.

About the Nordlynx connection issues: If really a reboot is required and completely killing and de-configuring + re-configuring the VPN connection does not help, then this sounds more like a server/machine issue? Did you check regular system and kernel logs? Are regular network connections are still possible (after disable possible killswitches) without a reboot?

Lol I think everyone stumbles at least once over the fact that /etc/cron.*/ scripts must not have a file ending. Only alphanumerical characters, dash and underscore are allowed. It’s actually the run-parts command that comes with these restrictions :wink:.

16

Thanks for the replies both.

Tbh I’m not even sure how to check the appropriate system logs, but the network behaviour when the nordlynx connection goes down (prior to reboot) is all normal on lan (ssh is fine, I can access all my web based services such as sonarr etc)

I’m confident that it is either a system (mine) or nord problem and not a diet pi issue, that being said I’ve upgraded dietpi since v5 so am going to do a completely fresh install from a ‘clean’ v7.x and see what difference that makes.

Incidentally my ‘wan ip’ in the banner and my ‘wan ip’ on the NordVPN client app are usually different. I do wonder if I’m not trying to double up my vpn with some overspill from an old vpn setup I may have had on the way (I’ve used the dietpi vpn confit method and an airvpn hummingbird client at various points)

Will post my findings