3.18.1 - Private subnet in allowlist not working, lan-discovery works OK
Closed this issue · 37 comments
Hi! I'm using NordVPN version 3.18.1 on Linux Mint 21.3. I seem to have an issue accessing LAN devices when a private subnet is added to the allowlist. I do not have the same issue with any prior NordVPN versions including 3.18.0.
After clearing the allowlist and enabling "lan-discovery" my LAN devices are accessible, so I will continue to use lan-discovery for now. Thanks!
Steps to reproduce:
- nordvpn allowlist add subnet 192.168.1.0/24
- ping another LAN device eg. 192.168.1.99 = fail
- nordvpn allowlist remove all
- nordvpn set lan-discovery enabled
- ping another LAN device 192.168.1.99 = OK
$ nordvpn --version
NordVPN Version 3.18.1
$ nordvpn status
Status: Connected
Server: United States #6301
Hostname: us6301.nordvpn.com
IP: 172.93.177.235
Country: United States
City: Chicago
Current technology: NORDLYNX
Current protocol: UDP
Transfer: 169.76 KiB received, 363.82 KiB sent
Uptime: 10 minutes 33 seconds
$ nordvpn settings
Technology: NORDLYNX
Firewall: enabled
Firewall Mark: 0xe1f1
Routing: enabled
Analytics: enabled
Kill Switch: enabled
Threat Protection Lite: disabled
Notify: disabled
Auto-connect: disabled
IPv6: disabled
Meshnet: disabled
DNS: disabled
LAN Discovery: disabled
$ nordvpn allowlist add subnet 192.168.1.0/24
Subnet 192.168.1.0/24 is allowlisted successfully.
$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -s 192.168.1.0/24 -i eno1 -m comment --comment nordvpn -j ACCEPT
-A INPUT -i eno1 -m connmark --mark 0xe1f1 -m comment --comment nordvpn -j ACCEPT
-A INPUT -i eno1 -m comment --comment nordvpn -j DROP
-A OUTPUT -d 192.168.1.0/24 -o eno1 -m comment --comment nordvpn -j ACCEPT
-A OUTPUT -o eno1 -m mark --mark 0xe1f1 -m comment --comment nordvpn -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A OUTPUT -o eno1 -m connmark --mark 0xe1f1 -m comment --comment nordvpn -j ACCEPT
-A OUTPUT -o eno1 -m comment --comment nordvpn -j DROP
$ nordvpn settings
Technology: NORDLYNX
Firewall: enabled
Firewall Mark: 0xe1f1
Routing: enabled
Analytics: enabled
Kill Switch: enabled
Threat Protection Lite: disabled
Notify: disabled
Auto-connect: disabled
IPv6: disabled
Meshnet: disabled
DNS: disabled
LAN Discovery: disabled
Allowlisted subnets:
192.168.1.0/24
$ ping -c3 192.168.1.99
PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data.
--- 192.168.1.99 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2041ms
$ nordvpn allowlist remove all
All ports and subnets have been removed from the allowlist successfully.
$ nordvpn set lan-discovery enabled
LAN Discovery is set to 'enabled' successfully.
$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -s 169.254.0.0/16 -i eno1 -m comment --comment nordvpn -j ACCEPT
-A INPUT -s 192.168.0.0/16 -i eno1 -m comment --comment nordvpn -j ACCEPT
-A INPUT -s 172.16.0.0/12 -i eno1 -m comment --comment nordvpn -j ACCEPT
-A INPUT -s 10.0.0.0/8 -i eno1 -m comment --comment nordvpn -j ACCEPT
-A INPUT -i eno1 -m connmark --mark 0xe1f1 -m comment --comment nordvpn -j ACCEPT
-A INPUT -i eno1 -m comment --comment nordvpn -j DROP
-A OUTPUT -d 169.254.0.0/16 -o eno1 -m comment --comment nordvpn -j ACCEPT
-A OUTPUT -d 192.168.0.0/16 -o eno1 -m comment --comment nordvpn -j ACCEPT
-A OUTPUT -d 172.16.0.0/12 -o eno1 -m comment --comment nordvpn -j ACCEPT
-A OUTPUT -d 10.0.0.0/8 -o eno1 -m comment --comment nordvpn -j ACCEPT
-A OUTPUT -o eno1 -m mark --mark 0xe1f1 -m comment --comment nordvpn -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A OUTPUT -o eno1 -m connmark --mark 0xe1f1 -m comment --comment nordvpn -j ACCEPT
-A OUTPUT -o eno1 -m comment --comment nordvpn -j DROP
$ nordvpn settings
Technology: NORDLYNX
Firewall: enabled
Firewall Mark: 0xe1f1
Routing: enabled
Analytics: enabled
Kill Switch: enabled
Threat Protection Lite: disabled
Notify: disabled
Auto-connect: disabled
IPv6: disabled
Meshnet: disabled
DNS: disabled
LAN Discovery: enabled
$ ping -c3 192.168.1.99
PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data.
64 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=0.224 ms
64 bytes from 192.168.1.99: icmp_seq=2 ttl=64 time=0.274 ms
64 bytes from 192.168.1.99: icmp_seq=3 ttl=64 time=0.187 ms
--- 192.168.1.99 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2026ms
rtt min/avg/max/mdev = 0.187/0.228/0.274/0.035 ms
I can also confirm this on Kubuntu mantic 23.10. my setup was nearly identical to yours.
3.18.1 has not been released (3.18.0 is latest in github), yet it is available in Linux repos?
Something else is going on as well... I updated my Kubuntu 22.04 after a while (was on nordvpn version 3.17.3) and it took me a while to figure out that it was the 3.18.1 nordvpn update that utterly broke my system making plasmashell unusable. Somehow it keeps spawning norduserd instances forever...
3.18.1 has not been released (3.18.0 is latest in github), yet it is available in Linux repos?
Just to confirm, 3.18.1 shows up in my package manager and in the repo here: https://repo.nordvpn.com/deb/nordvpn/debian/pool/main/
3.18.0 - 09-May-2024
3.18.1 - 10-May-2024
changelog:
nordvpn (3.18.1) stable; urgency=medium
- We've addressed potential security vulnerabilities in this release. Update now for the safest version.
-- NordVPN Linux Team linux@nordvpn.com Fri, 10 May 2024 10:46:36 +0000
Hi!
Same issue here with OpenSUSE Tumbleweed.
LAN discovery also only works reliably when the kill-switch is disabled.
Same here on Debian Bookworm CLI with Nordvpn 3.18.1
Exactly the same problem here. Debian Bookworm with Nord Linux client v3.18.1
Yep, similar local network drama here on Ubuntu Server 20.04.6... After creating a new Nordvpn token, the system is 'ready', but connecting to a country's server will totally lock the session. Reboot, create a new token.... Rinse and repeat. FFS.
Also having hiccups with the new status bar icon in Ubuntu Desktop 20.04 with 3.18.1. Logging in with a token works, but that is (now?) a one-time thing, unless you use the --persist-token parameter on the command line when logging out. So you have to get a new token after every logout... How can you handle that option when using only the status bar applet? Moreover, selecting a country via the applet isn't possible.
Seems like Linux users are again the guinea pigs of NordVPN. The 3.18.1 version followed a bit too quickly already IMHO, probably because something newly introduced in 3.18.0 wasn't working as advertised.
Doing a apt upgrade cost me hours of my life today trying to figure out why local network access wasn't working on my headless pi setup. Tried downgrading the package to 3.17.4 on a whim, and viola everything worked like a charm.
Minimal Debian 10 (buster) no graphics here with just a simple iptables rules
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED - j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
Me too @jeshtroy. But after reaching here and getting in touch with support, in my case I just need to nordvpn set lan-discovery enable and no need to downgrade. Funny thing is I have never set LAN discovery to enable before and it always worked lol
@Klojum why do need to logout? Isn't disconnect enough in your case? I've been using just connect and disconnect with the same token since they introduced login via browser and my internet machine has no X
@Alexgrosy I have done a test here and LAN discovery is working just fine with and without kill switch (nordvpn client asked me to enable firewall first)
@bcarmo-caio Because things are f'd up after a lockup. After that, I'm not logged in. Trying to log in with the same token (no typing errors, I use aliases for that), the login returns with:
"We couldn't log you in - the access token is not valid. Please check if you've entered the token correctly. If the issue persists, contact our customer support." And of course I see no Chat Icon option on the NordVPN support website during the weekend.
Creating a new token seems to work once, then I try to connect to some NordVPN server, and the server/session crashes again. I don't have enough time to dive deeper into this. I'm sure at NordVPN they hastily tried to fix their VPN engine from the newest threads that are floating around, but these big type UX problems shouldn't happen. As a ISTQB person, I know a bit about software testing. I think NordVPN should step up their testing game before releasing new versions.
Confirmed same issue here on Headless Ubuntu 22.04.4 LTS
Same issue here on raspberry pi os based on debian.
same on ubuntu 23.10. I upgraded NordVPN to 3.18.1 and all local access was dropped. I played around with the AllowList for a while then found this and ran nordvpn set lan-discovery enable which warned me it was deleting my AllowList.
It now works properly.
Replacing or disabling the Allowlist seems a major change for this minor update so I'm guessing they just broke it
I have this probalem as well on Ubuntu 24.04 and 22.04 server. Enabling lan-discovery means that I can access 192.168.x.x addresses but I also need to allowlist some docker container IP addresses which are 172.17.x.x and those are now blocked
Same issue on Debian Bookworm headless running in a VM on a Synology NAS. nordvpn set lan-discovery enabled works but does not persist.
Same issue on Kali 2024.1 running in KVM/QEMU. Nordvpn set lan-discovery enabled works but the allowlist subnet doesn't work with Nordvpn 3.18.1.
Same on Fedora 40
same issue debian 11.17 please fix!!!
Same, will be nice to Nordvpn have something similar to docker, create a new table and allow to use also a custom user rules: https://docs.docker.com/network/packet-filtering-firewalls/
Also have this problem on Manjaro Linux with AUR package nordvpn-bin 3.18.1-1.
Well, I spent several hours last night wrecking my brain on why my setup suddenly stopped working, until I ran into this issue. Reverting to 3.17.4 and everything worked again. And of course I ran into this in a headless setup 😫
Enabling the LAN-Discovery option is the simplest solution for me right now, I can deal with the subnet-allow absence. Having to downgrade every Nordvpn client is not on my immediate to-do list.
Upgrade to 3.18.1 broke my Linux Mint Cinnamon desktop: beside pop-ups that the network is disconnected, the screen or parts of screen go black regularly. Reverting the upgrade with Timeshift solved the problem.
Same here on rpi4, Raspbian. allowlist subnet seems to be the issue, reverting to the previous version fixed the issue for now.
Same. Whitelisting/allowlisting of my local subnet doesn't work on NordVPN version 3.18.1 anymore (both outgoing and incoming traffic affected). On another machine, I still have 3.16.6, and it still works fine there (both are Manjaro Linux).
Only due to this ticket, I got aware of the "lan-discovery" option (thanks!) - and it works fine, so I'm going to use it for now.
I just upgraded to 3.18.1 and couldn't connect to my subnet. :-(
hi,
thanks for registering the ticket.
We're working to fix the allowed list issue for the next release. In the meantime, please use the LAN discovery setting as a workaround, as others above mention.
For any other issues not related to LAN access, please create separate tickets.
@bjlockie wouldn't LAN discovery help in your case?
Regarding to LAN discovery persistence, ticket #371. This is fixed in main branch and it will be included in the next release.
Private subnet allowlisting fixed in #413. It will be released with 3.18.2 release
hi
do you have any idea when the new version will be available?
hi,
it is planned for the end of next week.
I am grateful to see that Nord has a fix scheduled for release! I have a use-case that is satisfied by allowing subnets but not by LAN discovery which is not represented here, so I thought it might be helpful to share.
I have multiple networks at different locations, each with a unique subnet. Every satellite location has a VPN tunnel back to the main location. Each gateway has a routing table that sends traffic for the relevant subnet to its corresponding location, instead of to the Internet. I assume NordVPN looks at the client's subnet mask to determine what is "LAN," which would make sense. But LAN discovery does not allow clients to talk to systems at other locations, whereas allow-listing subnets does.
Given I have ignored the problem for a few weeks and the update is a few days away, I'll just wait. Please consider adding a large test for this type of edge-case so updates cannot break it in the future. Thanks for your time!
Just to add another to the list, I'm running Ubuntu 22.04 and 24.04, and have set lan-discovery to true too, but I have to have the killswitch set to disabled in order for my network shares to be accessible. I think I've reinstalled both versions a half dozen times each over the last 3 days trying to figure out whats been going on.
hi, it is planned for the end of next week.
Any update on the release?
I have version 3.18.2 and I think the subnets allow are now working again
Version 3.18.2 was released. This should fix the problems with allowlist.
I'll close the ticket for now, but feel free to reopen if needed.