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

@metiis: please add: wireguard-tools wireguard-arch since the nordlynx technology is now included in the app that needs that packages to work properly. (https://nordvpn.com/blog/nordlynx-protocol-wireguard/) NordLynx works like charm for me now after adding wireguard. (sudo pacman -S wireguard-tools wireguard-arch) Maybe disable cyberSec in the settings)

It is under heavy development regarding that and has new versions sometimes twice a day: (https://repo.nordvpn.com/deb/nordvpn/debian/pool/main/)

Auto-connect not working on my system. nordvpn connect working though.

Can you make me a maintainer please? It's ALREADY OUTDATED...

@viking777

I have been experimenting and I am not sure my assumptions is entirely correct.

I now believe it to be undesireable behavior of the official client.

All my notes are on the Manjaro forum https://forum.manjaro.org/t/howto-understand-why-nordvpn-disables-ufw/96135

@fhdk Thanks for the reply, I am sure you are correct in your assumptions re this program and ufw, but I don't think that excuses the fact that this happens without any warnings. If I see a program that deliberately disables my firewall, doesn't tell me, and then fails to re-enable it, then I instantly think 'malware'. Now I know this program is not malware, and certainly don't blame the maintainer for anything, he has just inherited this behaviour due to poor coding in from the nord original - it exhibits the same behaviour on debian based distros btw. I don't use Windows, but my wife does, and she also uses Nord and her software firewall doesn't get disconnected every time she connects, so it must be possible.

As to workrounds, I don't use autoconnect, so thankfully, I don't have to mess with the impenetrability of systemd. I use the simple but effective expedient of "nordvpn -c ** && sudo ufw enable" from the terminal, in case anyone else looking for a quick way around it.

Is there a system im place to update the deb url since there is the version 3.3 out there and the repo outdated or how can i support you guys?

https://repo.nordvpn.com/deb/nordvpn/debian/pool/main/

Hi @erkexzcx, ahead of a 'poltical' decision regarding the maintainers adding you as a maintainer perhaps fast-track approach to merit maintaining here too [not necessary given your activity elsewhere on AUR but... ;-)] would be to share a link to your proposed build scripts to be used, or start a new AUR package. Just my 2c.

Can you make me a maintainer, please? I'd like to setup automated script to update this package.

Hey. Add missing armel architecture. It's for RPI1 and RPI zero devices (devices with armv6 architecture).

It's also provided by NordVPN: https://repo.nordvpn.com/deb/nordvpn/debian/pool/main/

@viking777 @typicallinuxuser

I am by no means a guru on connections and ufw but I do think that ufw is disabled because of the routing changes.

If the nordvpnd did not disable the ufw, the iptables generated by ufw would be blocking the traffic from the connected server as your nic changes address, dns and gateway.

If you are directly connected to a public a ip (most users connect through a firewalled routing device) then you are well served by a local firewall.

If you realle need firewall, you can create a systemd service to react on your network change to reenable ufw after nordvpnd has created the tunnel.