Arch Linux User Repository

"Please, do not flag this package as out-of-date until there's the official release on Github page."

"Maybe the announcement is delayed, but wait for some other possible forward release, which is patching the previous one before the actual publishing."

Note from 3.19.1:

The repository's hierarchy has been updated and a slightly divergence comes with it. It was from:

/debian/pool/main

To now as:

/debian/pool/main/n/nordvpn

Any previous commits you may like to try in the future will need a manual mediation to replace old links in favor of the new ones.

Note from 3.19.0:

This version introduces new libraries being used by NordVPN. I have created symbolic links and committed a patch for it not interposing with already existing libraries (like sqlite3). Although this is not a big deal, If you, however, upgraded nordvpn-bin before the fix and noticed some library-related issue from sqlite lately, I suggest reinstalling the affected package.

Note from 3.17.4v:

The previous bug exposing DNS servers is fixed.

Note from 3.17.3v:

Caution! This version needs heed while using it and should be avoided. I strongly advice downgrading to 3.17.2 and wait for a new version or patching. Some big problems are:

• There's DNS leak present. Your original ISP servers can be exposed, as reported already on #343 issue.

• Unable to connect on nordvpn servers. Your journal might show the follow output: networker setting dns: setting dns with resolvectl: setting dns with resolvectl: Failed to set DNS configuration: Could not activate remote peer: activation request failed: unknown unit.: exit status 1

  After restarting resolve with systemctl restart systemd-resolved.service you may get it working again, enough for connecting normally, as reported, but not exclusively an ARM platform issue, on #342.

Also huge thanks for the community warnings in prior comments before I could've noticed all.

Note from 3.16.2v:

As the published note from the version above has mentioned on Github's page:

• Logging in with a username and password is no longer available in the terminal.

Please, consider using a token to logging in from now on.

Note from 3.16.0v:

The 'countries.dat' may differ between versions. Be aware to remove the file before upgrading the package.

If you're seeing the message "Daemon is unreachable, is systemd running?", then one of two things is probably happening.

The nordvpn daemon might not be started
Start it using:
sudo systemctl enable --now nordvpnd

You might not have been added to the nordvpn group
Add yourself:
sudo gpasswd -a USERNAME nordvpn
And then restart in order for the group to be created:
reboot

I'm constantly seeing these log messages. Please fix this:

May 17 14:09:25 t480 systemd[1]: Configuration file /usr/lib/systemd/system/nordvpnd.service is marked world-writable. Please remove world writability permission bits. Proceeding anyway.
May 17 14:09:25 t480 systemd[1]: Configuration file /usr/lib/systemd/system/nordvpnd.socket is marked world-writable. Please remove world writability permission bits. Proceeding anyway.

@rezanmz marked this package as outdated with the reason "Outdated", but according to the release notes the latest version is 3.9.4, the same as the PKGBUILD is providing.

Additionally, the NordVPN deb pool lists 3.9.4 as the latest version.

What should be done in situations like these?

Hi to all, the subnet whitelist doesn't work with my Arch Linux Thinkpad T570: I've whitelisted both LAN and VPN subnet, but I can't ping LAN.
I've reinstalled twice, switched from OpenVPN to NordLynx technology, restarted several time systemd's nordvpnd service, but I can't ping local network while I'm connected to NordVPN.
Any advice?
Here's my nordvpn settings:
Technology: NordLynx
Firewall: enabled
Kill Switch: disabled
CyberSec: disabled
Notify: enabled
Auto-connect: disabled
DNS: disabled
Whitelisted subnets:
192.168.1.0/24
10.0.0.0/8


@arizonajoe iptables confs could be a red herring. As you say.. everything else works and then it slowly deteriorates, you've got a decent connection too which could mean traffic shaping via your ISP is taking place or perhaps even at Nordvpn. Might be best to send Nordvpn a DM on Twitter to help them diagnose given you've checked everything 'your side'. FYI I asked for their help once before and they were responsive, supportive and effective in helping me diagnose my issues.

I have been having issues with nordvpn-bin for over a year. Within 10 - 15 minutes "on the clock," something happens to severely restrict though-put, whether I use NetworkManager in Plasma/KDE or Gnome. It matters not. Yes, I make sure that the service is started and enabled. Yes, this user is a member of the group. The connection always starts out to be excellent whether using NordLynx or OpenVPN, and whether Cybersec is on or off. And it makes no difference which server I connect to. Sometimes the connection deteriorates slowly, and at other times, it becomes "constricted" faster, and requires a reboot or iptables restart. I have not looked at the IP tables but assumed that nordvpn broke them. And the system tray icon in Plasma/KDE gets the requisite exclamation mark telling me my connectivity is limited.

This happens whether on WiFi or on Ethernet. I am using a fast fiber connection near 1000MB/sec. A restart of the iptables fixes the though-put temporarily, but the exclamation point warning of limited connectivity in the system tray connection icon remains.

@ledom05 When my connection randomly closes I usually do a pkill nordvpnd and then sudo systemctl restart iptables and everything goes running again.

Still have an issue with "limited connectivity" in Plasma. About 5 minutes in after connecting NetworkManager would notify about "limited connectivity", e.g. no internet access. After that connectivity in some apps (Spotify for example) would be lost, but browser works normally.

Have tried various combinations of settings for the package, but no luck so far. Support agent didn't even try to help, since they have no official support for arch. Flushing iptables and changing permissions for resolv.conf didn't help either.

I have found no working solution for my problem so far.

@Martoko: have you checked the dependencies of the 3.9.0 Debian package? They have changed from previous versions, so the dependencies of your package may need adjustments too.