Join Log in
Score:0
avatar Server

Some packets are not being routed through the local network when using nordvpn

vn flag
Gabriele Cirulli

My local network has two relevant subnets: 192.168.1.0/24 and 192.168.72.0/24. These are defined via my router.

There's a local server running at 192.168.1.10. The server runs a Home Assistant Supervisor (which is run through Docker).

The local server must be able to connect to various hosts on the 192.168.72.0/24 subnet.

This works correctly under normal conditions, but breaks down when I introduce the nordvpn utility, which filters all traffic through NordVPN.

When nordvpn is running and connected, the local server is unable to send or receive from hosts on the subnet 192.168.72.0/24.

I have tried running nordvpn whitelist add subnet 192.168.72.0/24 (or the same command with 192.168.0.0/16) but it doesn't seem to help.

For example, pinging a known address on that subnet:

serv@serv:~$ ping 192.168.72.48
PING 192.168.72.48 (192.168.72.48) 56(84) bytes of data.
From 10.8.0.1 icmp_seq=1 Destination Host Unreachable

If I run ip address, I'm shown the following:

serv@serv:~$ ip address
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: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:23:24:a6:68:56 brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic noprefixroute eno1
       valid_lft 82326sec preferred_lft 82326sec
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:2b:ff:27:b8 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
4: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:7d:ba:7c:5b brd ff:ff:ff:ff:ff:ff
    inet 172.35.32.1/23 brd 172.35.33.255 scope global hassio
       valid_lft forever preferred_lft forever
6: veth0fc757e@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 16:00:e7:0d:c1:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
9: vetha95aaa0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 62:38:5f:f9:c3:f5 brd ff:ff:ff:ff:ff:ff link-netnsid 1
11: vethcf2e4fa@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 8e:4b:83:34:3a:d6 brd ff:ff:ff:ff:ff:ff link-netnsid 1
13: veth6df409c@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 8a:79:2e:f8:dd:8f brd ff:ff:ff:ff:ff:ff link-netnsid 2
15: veth82e25ea@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether ae:eb:57:d3:d0:e0 brd ff:ff:ff:ff:ff:ff link-netnsid 3
17: veth29b3afc@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 66:4c:55:ca:b4:62 brd ff:ff:ff:ff:ff:ff link-netnsid 4
19: veth3377d0e@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether e2:3d:8f:67:d9:57 brd ff:ff:ff:ff:ff:ff link-netnsid 5
21: veth2c850be@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 92:2b:6e:06:51:6d brd ff:ff:ff:ff:ff:ff link-netnsid 6
23: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.8.0.4/24 scope global tun0
       valid_lft forever preferred_lft forever

I believe the tun0 interface is supplied by nordvpn. Its subnet matches the IP I'm seeing in my failed ping attempt.

My understanding of networking is very limited, so I can't wrap my head around why my packets end up in 10.8.0.1 instead of being sent to the router at 192.168.1.1.

If it's any help, this is the output of ip route:

serv@serv:~$ ip route
0.0.0.0/1 via 10.8.0.4 dev tun0
default via 192.168.1.1 dev eno1 proto dhcp metric 100
1.0.0.1 via 192.168.1.1 dev eno1
1.1.1.1 via 192.168.1.1 dev eno1
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.4
128.0.0.0/1 via 10.8.0.4 dev tun0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.35.32.0/23 dev hassio proto kernel scope link src 172.35.32.1
192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.10 metric 100
213.232.87.204 via 192.168.1.1 dev eno1

and iptables -S:

serv@serv:~$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-A INPUT -s 1.1.1.1/32 -i eno1 -j ACCEPT
-A INPUT -s 192.168.0.0/16 -i eno1 -j ACCEPT
-A INPUT -s 172.35.0.0/16 -i eno1 -j ACCEPT
-A INPUT -s 1.0.0.1/32 -i eno1 -j ACCEPT
-A INPUT -s 213.232.87.204/32 -i eno1 -j ACCEPT
-A INPUT -i eno1 -j DROP
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o hassio -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o hassio -j DOCKER
-A FORWARD -i hassio ! -o hassio -j ACCEPT
-A FORWARD -i hassio -o hassio -j ACCEPT
-A OUTPUT -d 1.1.1.1/32 -o eno1 -j ACCEPT
-A OUTPUT -d 192.168.0.0/16 -o eno1 -j ACCEPT
-A OUTPUT -d 172.35.0.0/16 -o eno1 -j ACCEPT
-A OUTPUT -d 1.0.0.1/32 -o eno1 -j ACCEPT
-A OUTPUT -d 213.232.87.204/32 -o eno1 -j ACCEPT
-A OUTPUT -o eno1 -j DROP
-A DOCKER -d 172.35.32.6/32 ! -i hassio -o hassio -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.35.33.0/32 ! -i hassio -o hassio -p tcp -m tcp --dport 8884 -j ACCEPT
-A DOCKER -d 172.35.33.0/32 ! -i hassio -o hassio -p tcp -m tcp --dport 8883 -j ACCEPT
-A DOCKER -d 172.35.33.0/32 ! -i hassio -o hassio -p tcp -m tcp --dport 1884 -j ACCEPT
-A DOCKER -d 172.35.33.0/32 ! -i hassio -o hassio -p tcp -m tcp --dport 1883 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i hassio ! -o hassio -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o hassio -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN

How can I make sure that packets get routed to 192.168.72.0/24 as expected?

148
0 + 0
vpn
ip
vn flag
Gabriele Cirulli
I ran `sudo ip route add 192.168.0.0/16 via 192.168.1.1` and it seems to have helped. I can now connect to devices on the subnet `192.168.72.0/24` because as far as I can tell those packets are now being sent through the router. Is this the correct approach however? I don't know much about networking so I am not sure if this is an appropriate way to solve it.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.