nordvpn: init at 4.3.1

[different-error]

Add the popular NordVPN to NixOS. Tested using the following configuration:

{
  config,
  lib,
  pkgs,
  ...
}:

{
  imports = [
    ./hardware-configuration.nix
  ];

  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;
  networking.firewall.enable = false;  # required

  services.nordvpn.enable = true;  # required

  virtualisation.vmVariant = {
    virtualisation = {
      memorySize = 4096;
      cores = 3;
    };
  };

  users.groups.alice = {};
  users.users.alice = {
    isSystemUser = true;
    password = "alice";
    group = "alice";
    extraGroups = [
      "wheel"
      "nordvpn"  # strongly recommended
    ];
    shell = pkgs.bash;
    home = "/home/alice";
    createHome = true;
    packages = with pkgs; [
      tree
    ];
  };

  system.stateVersion = "24.11"; # Did you read the comment?
}

The configuration was tested by running:

nixos-rebuild build-vm --use-remote-sudo -I nixos-config=/path/to/above/configuration.nix -I nixpkgs=/path/to/this/pr/nixpkgs

There is another PR (#220616) for NordVPN, which is over two years old and has been stale for a year. Additionally, there are issues requesting NordVPN support for NixOS here and here.

I chose to extract the .deb package instead of building from source to avoid modifying or leaking the salt. Meshnet is not yet supported, but core NordVPN features work. I’ll create another PR once the Meshnet issues are resolved.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[drupol]

Hello,

Thanks for your first PR.

I made some feedback, let me know if you need some help.

[NyCodeGHG]

For such a security relevant package such as a vpn software, we should build from source if possible.
I'm not sure why you want to avoid "leaking" the salt, since it can be easily extracted from the binary in the .deb you linked.

This would also allow us to patch out quirks such as relying on /usr

[different-error]

For such a security relevant package such as a vpn software, we should build from source if possible. I'm not sure why you want to avoid "leaking" the salt, since it can be easily extracted from the binary in the .deb you linked.

This would also allow us to patch out quirks such as relying on /usr

Your claims about salts are valid and correct! My earlier statement was based on an incorrect misunderstanding, and I've updated the comment accordingly.

Another way to address quirks is to make changes directly in the NordVPN repository, which was my implicit assumption for the next release.

I could update this to build from scratch, but I don’t see the added security benefit. All other Linux distributions download from repo.nordvpn.com (.deb or .rpm) via their install script. I’ve also noticed that ExpressVPN extracts their .deb. Fortunately, building from source is nearly complete thanks to community efforts. Regardless, I’m not convinced there’s a significant advantage. Lmk your thoughts, thanks!

[drupol]

I could update this to build from scratch, but I don’t see the added security benefit. All other Linux distributions download from repo.nordvpn.com (.deb or .rpm) via their install script. I’ve also noticed that ExpressVPN extracts their .deb. Fortunately, building from source is nearly complete thanks to community efforts. Regardless, I’m not convinced there’s a significant advantage. Lmk your thoughts, thanks!

You are right that most distributions fetch the .deb or .rpm packages from repo.nordvpn.com using the official install script, and that ExpressVPN follows a similar approach in Nixpkgs by extracting the .deb archive.

However, the key issue here is trust and verifiability.

At the moment, there's no reliable way to verify that the binaries provided on repo.nordvpn.com are actually built from the publicly available sources. By using those prebuilt packages, we are implicitly trusting the vendor without any way to independently validate the build integrity.

One of the strengths of Nix is its focus on reproducibility. Building from source allows us (most of the time) to produce reproducible outputs. This enables a verifiable 1-to-1 mapping between the source code and the resulting binaries, which significantly improves the security of the software supply chain.

Fortunately, thanks to recent community efforts, we’re getting close to being able to build the client fully from source.

That’s why I believe it’s worth pushing in that direction.

[different-error]

I could update this to build from scratch, but I don’t see the added security benefit. All other Linux distributions download from repo.nordvpn.com (.deb or .rpm) via their install script. I’ve also noticed that ExpressVPN extracts their .deb. Fortunately, building from source is nearly complete thanks to community efforts. Regardless, I’m not convinced there’s a significant advantage. Lmk your thoughts, thanks!

You are right that most distributions fetch the .deb or .rpm packages from repo.nordvpn.com using the official install script, and that ExpressVPN follows a similar approach in Nixpkgs by extracting the .deb archive.

However, the key issue here is trust and verifiability.

At the moment, there's no reliable way to verify that the binaries provided on repo.nordvpn.com are actually built from the publicly available sources. By using those prebuilt packages, we are implicitly trusting the vendor without any way to independently validate the build integrity.

One of the strengths of Nix is its focus on reproducibility. Building from source allows us (most of the time) to produce reproducible outputs. This enables a verifiable 1-to-1 mapping between the source code and the resulting binaries, which significantly improves the security of the software supply chain.

Fortunately, thanks to recent community efforts, we’re getting close to being able to build the client fully from source.

That’s why I believe it’s worth pushing in that direction.

Gotcha. A malicious attacker might somehow tamper with their binaries. Building from source is the secure way to go. Ok, will do, thanks!

[different-error]

Modified the package to build from source instead of extracting the .deb file.
Attribution: I adapted the working configuration found here.

Verified that core features function correctly.

Thank you all for your time!

[different-error]

I've reduced privileges by using a dedicated nordvpn user. DynamicUser=true behaved inconsistently when I specified the nordvpn group, including when I set it only in SupplementaryGroups=.

Additionally, the nordvpnd source was modified to find helper executables in the <<pkg>>/bin directory (and the PATH, of course). The PATH configured in the systemd unit file now includes only paths to the binaries that are needed.

One more thing, nordvpnd failed to recognize the norduserd process, even though both ran as the same user, which is incorrect behavior. As far as I know, this only affects notifications for VPN server connection/disconnection. I verified basic connect/disconnect operations using OpenVPN and NordLynx protocols.

Thanks again for the review!

[andersonjoseph]

Any insight about why meshnet is not supported? I've been using the package just fine until I got hit with an error while trying to use meshnet and I could not find anything useful on the logs.

[ruffsl]

Any insight about why meshnet is not supported?

@andersonjoseph , meshnet requires dependencies such as libtelio, related discussion from Jun 13th to 18th above:

• nordvpn: init at 4.3.1 #406725 (comment)
• nordvpn: init at 4.3.1 #406725 (comment)

[different-error]

Just a quick version bump to 4.3.1. Going to work on the Flutter GUI now. Hopefully it turns out not too difficult thanks to the prior effort of @ruffsl

[different-error]

Ok, I think the previous build passed because of some cache weirdness. Strangely when I had tested the binary, it spat out that the binary had used version 4.3.1. Anyway, latest commits use the correct vendor and src hashes for 4.3.1. libxml2 successfully removed in the package.

[different-error]

Attempting to build nordvpn's flutter gui. You can find what I have so far here. It does not build atm, complains with the following error:

[ +154 ms] CMake Error at /nix/store/w9jm660dykns6hzrdhxmqfywnc9ail8g-cmake-4.1.2/share/cmake-4.1/Modules/FindPackageHandleStandardArgs.cmake:227 (message):
[        ]   Could NOT find X11 (missing: X11_X11_INCLUDE_PATH X11_X11_LIB)
[        ] Call Stack (most recent call first):
[        ]   /nix/store/w9jm660dykns6hzrdhxmqfywnc9ail8g-cmake-4.1.2/share/cmake-4.1/Modules/FindPackageHandleStandardArgs.cmake:591 (_FPHSA_FAILURE_MESSAGE)
[        ]   /nix/store/w9jm660dykns6hzrdhxmqfywnc9ail8g-cmake-4.1.2/share/cmake-4.1/Modules/FindX11.cmake:671 (find_package_handle_standard_args)
[        ]   CMakeLists.txt:57 (find_package)

Seems like I need to add xorg somehow (nixos discourse). I intend to try again tomorrow.

[different-error]

I've added flutter gui support to the package and removed the salt. Also to avoid rebuilding the cli twice, I've separated out the package into cli.nix and gui.nix. I had to patch their linux CMakeLists.txt to use pkgconfig to find the correct x11 path.

Tested and verified that both standalone package and module work as intended over openvpn and nordlynx.

I intend to work on incorporating meshnet next which I would start on Dec 26th. Hopefully not too difficult thanks to the prior efforts of @dimkNevidimk!

[different-error]

meshnet progress update:

• libtelio package builds
• tests all pass in a pure nix-shell but seem to break when I run nix-build -A libtelio. Not sure why yet..

https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet

https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet/pkgs/by-name/li/libtelio

[different-error]

update:

• I've added libdrop and modified the nordvpn cli recipe to use the tags "telio" "drop".
• they've patched libdrop-go so I believe we can use Go1.24+

Surprisingly, I don't see "meshnet" in the nordvpn settings.

https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet
https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet/pkgs/by-name/li/libdrop
https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet/pkgs/by-name/no/nordvpn

I've caught the flu. I intend to get back to this when I feel healthy enough to do so.

[dimkNevidimk]

@different-error,

Sorry for not replying earlier, but I think NordVPN team dropped meshnet support completely:
https://nordvpn.com/blog/meshnet-shutdown/

[different-error]

@different-error,

Sorry for not replying earlier, but I think NordVPN team dropped meshnet support completely:
https://nordvpn.com/blog/meshnet-shutdown/

They changed their mind and decided to keep it.

https://nordvpn.com/blog/meshnet-stays

[different-error]

I could use some help getting meshnet working. Please base your changes around my feature branch nordvpn-meshnet. Ty

[andersonjoseph]

I could use some help getting meshnet working. Please base your changes around my feature branch nordvpn-meshnet. Ty

I will take a look when I get home from holiday travel (in a couple of hours) 👌

---

Update here

TL;DR: I got Meshnet working, but it tries to edit /etc/hosts, which causes permission errors.
I can force it to work by changing the file mode to 0644, but that's a dirty hack.

If anyone knows a clean way to grant write permissions to /etc/hosts, it would be great. Another solution is to send a patch with a --no-ns-hosts flag to the upstream repo so we can disable the write attempts and handle hostnames declaratively.

[different-error]

Some nits. Tested successful connection using the GUI.

While progress with meshnet continues, seeing that including it would cause this PR to increase significantly in size, I think we should PR the current changes without meshnet support and include meshnet in the next PR.

I presently intend to break this PR into smaller, newer ones to facilitate review.