SSH connection with NordVPN

Hi there!

Yesterday, I connected my RPi4 to a NordVPN server through dietpi-vpn. Everything seems to be fine. The only issue I’ve found is that I can’t reach the pi via ssh when I try to connect from another router that is under the same subnet (I can do so when the pi is not connected to NordVPN).

I’ve read that a possible solution is to add the subnet (i.e.192.168.1.0/24) to a whitelist. My questions are?

  1. Is it a possible solution?

  2. If not, what should I do?

(I’m not an expert myself, sorry and I’m lost when it comes to iptables or stuff like that).

More info:

  • DietPi version
    G_DIETPI_VERSION_CORE=8
    G_DIETPI_VERSION_SUB=22
    G_DIETPI_VERSION_RC=3
    G_GITBRANCH=‘master’
    G_GITOWNER=‘MichaIng’
  • Distro version | bullseye 0
  • Kernel version | Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
  • Architecture | armhf
  • SBC model | RPi 4 Model B (aarch64)

Thanks in advance.

Yes, it seems that the vpn killswitch is too tight, for your own security.
Have a look here.
I am not sure if there is any update since May 2021 when this topic was opened and there is a better way to exclude some private IPs from the killswitch.

If I’m not mistaken, we use subnet 192.168.0.0/16. Usually this should include 192.168.1.0/24 right?

1 Like

Thank you for your answers.

The killswitch is off, should I add the rules?

I can’t reach other ports such as 9091.

Sould I add a rule for every port as in the example?

iptables -A INPUT -s 192.168.10.0/24 -p tcp --dport 9091 -j ACCEPT

Thanks!

Yes,192.168.0.0/16means one subnet from 192.168.0.1 to 192.168.255.254

1 Like

Can you post the ip -4 addr; ip -4 ro list table all; ip -4 ru; iptables-save -c with the killswitch enabled?

Thank you for your answer. It doesn’t work.

  1. I disconnected the vpn.
  2. Edit the up script with the line: iptables -A INPUT -s 192.168.0.0/24 -p tcp --dport 22 -j ACCEPT
  3. Save the file and connect the vpn again.

But I can’t get the ssh connection.

  1. I erased the up script.

  2. Enabled killswitch.

  3. Run ip -4 addr; ip -4 ro list table all; ip -4 ru; iptables-save -c

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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 mq state UP group default qlen 1000
    inet 192.168.4.48/24 brd 192.168.4.255 scope global dynamic eth0
       valid_lft 48279sec preferred_lft 48279sec
4: br-353dfaeb6856: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-353dfaeb6856
       valid_lft forever preferred_lft forever
6: br-53881ace3f35: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    inet 172.20.0.1/16 brd 172.20.255.255 scope global br-53881ace3f35
       valid_lft forever preferred_lft forever
7: br-64b8bd1bb8b5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    inet 172.21.0.1/16 brd 172.21.255.255 scope global br-64b8bd1bb8b5
       valid_lft forever preferred_lft forever
8: br-d9a46b4fb181: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-d9a46b4fb181
       valid_lft forever preferred_lft forever
9: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
29: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    inet 10.8.0.2/24 scope global tun0
       valid_lft forever preferred_lft forever
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 192.168.4.1 dev eth0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
128.0.0.0/1 via 10.8.0.1 dev tun0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-353dfaeb6856 proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-d9a46b4fb181 proto kernel scope link src 172.19.0.1
172.20.0.0/16 dev br-53881ace3f35 proto kernel scope link src 172.20.0.1
172.21.0.0/16 dev br-64b8bd1bb8b5 proto kernel scope link src 172.21.0.1 linkdown
185.199.100.27 via 192.168.4.1 dev eth0
192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.48
local 10.8.0.2 dev tun0 table local proto kernel scope host src 10.8.0.2
broadcast 10.8.0.255 dev tun0 table local proto kernel scope link src 10.8.0.2
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1
local 172.18.0.1 dev br-353dfaeb6856 table local proto kernel scope host src 172.18.0.1
broadcast 172.18.255.255 dev br-353dfaeb6856 table local proto kernel scope link src 172.18.0.1 linkdown
local 172.19.0.1 dev br-d9a46b4fb181 table local proto kernel scope host src 172.19.0.1
broadcast 172.19.255.255 dev br-d9a46b4fb181 table local proto kernel scope link src 172.19.0.1
local 172.20.0.1 dev br-53881ace3f35 table local proto kernel scope host src 172.20.0.1
broadcast 172.20.255.255 dev br-53881ace3f35 table local proto kernel scope link src 172.20.0.1
local 172.21.0.1 dev br-64b8bd1bb8b5 table local proto kernel scope host src 172.21.0.1
broadcast 172.21.255.255 dev br-64b8bd1bb8b5 table local proto kernel scope link src 172.21.0.1 linkdown
local 192.168.4.48 dev eth0 table local proto kernel scope host src 192.168.4.48
broadcast 192.168.4.255 dev eth0 table local proto kernel scope link src 192.168.4.48
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
# Generated by iptables-save v1.8.7 on Thu Oct  5 13:41:12 2023
*filter
:INPUT DROP [22:10144]
:FORWARD DROP [16:1733]
:OUTPUT DROP [23:2727]
[31:2948] -A INPUT -i lo -j ACCEPT
[239:37766] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
[53:6510] -A OUTPUT -o lo -j ACCEPT
[52:4388] -A OUTPUT -o tun0 -j ACCEPT
[156:29941] -A OUTPUT -d 192.168.0.0/16 -j ACCEPT
[0:0] -A OUTPUT -d 172.16.0.0/12 -j ACCEPT
[0:0] -A OUTPUT -d 10.0.0.0/8 -j ACCEPT
[58:7951] -A OUTPUT -d 185.199.100.27/32 -p udp -m udp --dport 1194 -j ACCEPT
COMMIT
# Completed on Thu Oct  5 13:41:12 2023
# Generated by iptables-save v1.8.7 on Thu Oct  5 13:41:12 2023
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:DOCKER - [0:0]
[23910:1433644] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
[5605:336300] -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
[37870:3417914] -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
[3:180] -A POSTROUTING -s 172.19.0.0/16 ! -o br-d9a46b4fb181 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.21.0.0/16 ! -o br-64b8bd1bb8b5 -j MASQUERADE
[33754:2136684] -A POSTROUTING -s 172.20.0.0/16 ! -o br-53881ace3f35 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.18.0.0/16 ! -o br-353dfaeb6856 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 3129 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.20.0.2/32 -d 172.20.0.2/32 -p tcp -m tcp --dport 5055 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.19.0.2/32 -d 172.19.0.2/32 -p tcp -m tcp --dport 6595 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.17.0.3/32 -d 172.17.0.3/32 -p tcp -m tcp --dport 51413 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.17.0.3/32 -d 172.17.0.3/32 -p udp -m udp --dport 51413 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.17.0.4/32 -d 172.17.0.4/32 -p tcp -m tcp --dport 8083 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.17.0.5/32 -d 172.17.0.5/32 -p tcp -m tcp --dport 9000 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.17.0.6/32 -d 172.17.0.6/32 -p tcp -m tcp --dport 80 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.17.0.3/32 -d 172.17.0.3/32 -p tcp -m tcp --dport 9091 -j MASQUERADE
[848:50850] -A DOCKER -i docker0 -j RETURN
[0:0] -A DOCKER -i br-d9a46b4fb181 -j RETURN
[0:0] -A DOCKER -i br-64b8bd1bb8b5 -j RETURN
[21955:1317300] -A DOCKER -i br-53881ace3f35 -j RETURN
[0:0] -A DOCKER -i br-353dfaeb6856 -j RETURN
[0:0] -A DOCKER ! -i docker0 -p tcp -m tcp --dport 3129 -j DNAT --to-destination 172.17.0.2:3129
[30:1560] -A DOCKER ! -i br-53881ace3f35 -p tcp -m tcp --dport 5055 -j DNAT --to-destination 172.20.0.2:5055
[0:0] -A DOCKER ! -i br-d9a46b4fb181 -p tcp -m tcp --dport 6595 -j DNAT --to-destination 172.19.0.2:6595
[0:0] -A DOCKER ! -i docker0 -p tcp -m tcp --dport 51414 -j DNAT --to-destination 172.17.0.3:51413
[0:0] -A DOCKER ! -i docker0 -p udp -m udp --dport 51414 -j DNAT --to-destination 172.17.0.3:51413
[0:0] -A DOCKER ! -i docker0 -p tcp -m tcp --dport 8083 -j DNAT --to-destination 172.17.0.4:8083
[2:104] -A DOCKER ! -i docker0 -p tcp -m tcp --dport 9002 -j DNAT --to-destination 172.17.0.5:9000
[384:21640] -A DOCKER ! -i docker0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.0.6:80
[4568:273552] -A DOCKER ! -i docker0 -p tcp -m tcp --dport 9091 -j DNAT --to-destination 172.17.0.3:9091
COMMIT

Maybe because in your next post you can see, that you use a different subnet on your device, and not 192.168.0.0/24. So change the IP or the subnet range to 16 instead of 24.

You already have a rule to allow SSH from anywhere, therefore there is no need to add anything additional. But there are no hits. Which means that no packets arrived to the dietpi on port 22.

So, should I add a line like this: -A INPUT -s 192.168.0.0/16 -p tcp --dport 22 -j ACCEPT in the up script? Or should it be iptables -A INPUT -s 192.168.0.0/16 -p tcp --dport 22 -j ACCEPT?

Thank you.

No, as Trendy said you have already a rule that allows SSH connections from everywhere, so there must be another reason you can’t connect.

1 Like

I am a bit confused now. Are you able to reach the Dietpi on SSH port 22 when the VPN and killswitch are active?
Or the problem is with other protocols?

Sorry for the confusion I may cause.

When the killswitch is active and the VPN is connected I can’t ssh.

I’ve had the same problem with other protocols too, I can’t reach radarr for example.

From which IP address are you trying to connect?

This is expected because of the killswitch

1 Like

What should I do then? Does it affect the connection even when disabled?

I connect from a Chromebook the ip looks: 10.2.X.XXX

Edit the up script:
iptables -A INPUT -s 10.0.0.0/8 -p tcp --dport 22 -j ACCEPT

Should I do the same for all the other services?