[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.

---

Note: I use Claude btw.

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!

[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.

[different-error]

Updated to version 4.5.0

[romildo]

There are merge conflicts.

[different-error]

Updated to 5.0.0

[different-error]

NordVPN 5.1.0

[different-error]

NordVPN 5.2.0

[romildo]

This branch has conflicts that must be resolved.

[different-error]

• Package pr has merged. Ty @romildo!!
• Meshnet requires some changes upstream and the nixpkgs changes would go inside a different pr. This would take me a few weeks. Thank you for your patience.
• Verified that nordvpn module with version 5.2.0 works over nordlynx and openvpn protocols and over cli and gui.

[different-error]

Closing this pr since it has two review requests with write access from reviewers no longer active with the pr. I can open another pr for the module shortly after.

[different-error]

New module pr #538312 (same commit). Ty

[different-error]

• PR nixos/nordvpn: init module #538312 merged, ty @romildo!! 🚢
• I intend to delete my nordvpn branch sometime Sunday, 2026-07-19 UTC. Please migrate to NixOS's unstable nordvpn package/option by then.
• Consult nordvpn.md for documentation. I plan to open a follow-up PR to incorporate it into the wiki.

[different-error]

Hey folks, update on meshnet:

• Presently I can send files to another peer on the network but I cannot receive files. I've started a separate PR to facilitate debugging.
• I've started an issue upstream pertaining to new features necessary for nixos support and have a few PRs open upstream.
• I've opened nixos/nordvpn: make more secure and robust #547437 with further hardening of the nixos/nordvpn service.

Thanks to @andersonjoseph and @dimkNevidimk for the initial groundwork on meshnet!

[different-error]

Update:

• Version bump 5.2.0 -> 5.3.0: Nordvpn fix nix update, 5.2.0 -> 5.3.0 #549793. Auto-updating should now work for future releases.
• Meshnet file transfer now works (see commit b35b95). Communicating with upstream to get dependent changes merged. Upvote the issue to indicate relevance: meshnet enable fails under unprivileged nordvpnd (NixOS module) NordSecurity/nordvpn-linux#1648.

[different-error]

Hey folks, an update on Meshnet:

You can use the changes in the unmerged nordvpn-mesh branch. This contains the changes found in the aforementioned PRs #549793 and #547437, along with the changes in my pepper branch for upstream nordvpn-linux. NordSecurity/nordvpn-linux#1648 tracks the ongoing discussion with upstream to merge NixOS-relevant features and fixes for Meshnet.

I haven't explored all the features of Meshnet and have only experimented with fileshare, which should work.

In the meantime, feel free to use nordvpn-meshnet in your flake:

inputs = {
  # ...
  nordvpn-meshnet.url = "github:different-error/nixpkgs/nordvpn-meshnet";
};
outputs =
{
  self,
  nordvpn-meshnet,
  ...
}:
let
  # ...
  pkgs-nordvpn = import nordvpn-meshnet { inherit system; };
  nordvpnModule = {
    disabledModules = [ "services/networking/nordvpn.nix" ];
    imports = [ "${nordvpn-meshnet}/nixos/modules/services/networking/nordvpn.nix" ];
    nixpkgs.overlays = [
      (_final: _prev: { nordvpn = pkgs-nordvpn.nordvpn; })
    ];
  };
in
  # ...
  nixpkgs-unstable.lib.nixosSystem {
    # ...
    modules = [
      nordvpnModule
      # ...
    ];
  }

and note the corresponding new firewall and networking configuration:

  networking.firewall = {
    enable = true;
  };
  networking.hosts = {
    "1.2.3.4" = [ "peer1" ];
  };

No need to set checkReversePath = "loose"; as that has moved into the module itself (seems like every other VPN on here does this too).

🍻

[novalkun]

Upstream 5.4.0 is out:
https://github.com/NordSecurity/nordvpn-linux/releases/tag/5.4.0

Happy to test a bump PR on NixOS 26.05 + Plasma if you open one.

[different-error]

Updates:

• I encountered a brief account suspension (for a little over a month), during which time @novalkun kindly took over and did a great job. Thank you.
• @romildo merged nixos/nordvpn: make more secure and robust #547437 which contained additional security restrictions that reduce the blast radius of a compromised service. Thank you.
• Meshnet PR finally out at nixos/nordvpn: add meshnet support #576413. I could use a few extra hands to manually test the PR and build confidence before requesting merger.

[novalkun]

would you open the PR for nordvpn 6.0.1 @different-error ? seems the bot would not work for major releases.
OpenVPN used on this release is 2.7.7 but on nixpkgs still using 2.6.23

[novalkun]

hello @different-error. could you check ZHF? nixos/tests/nordvpn fails only on aarch64-linux: verify_kernel_modules_loaded() asserts tun is listed by lsmod, but on aarch64 CONFIG_TUN=y (built-in), so it never appears there. x86_64 passes, and the package/module itself build fine — this is a test-only failure added by #547437 (introduced in the current ZHF run #584347).