New-package: Mullvad vpn

[dkwo]

• I tested the changes in this PR: yes, in the field.
• This new package conforms to the package requirements: YES
• I built this PR locally for my native architecture, (aarch64-glibc)

cc #21154

[MarkusPettersson98]

Can we help move this forward somehow?:)

[Zeitsperre]

I can also confirm that this package works great for me locally (x86_64-glibc).

[dkwo]

@MarkusPettersson98 Thanks! This has been working well for me for a while on Apple silicon.
Do you think a pure rust build using gotatun will get released soon for Linux? I was tracking the master branch, hoping to drop go, so that more archs and crossbuild could potentially work.

[MarkusPettersson98]

@MarkusPettersson98 Thanks! This has been working well for me for a while on Apple silicon. Do you think a pure rust build using gotatun will get released soon for Linux? I was tracking the master branch, hoping to drop go, so that more archs and crossbuild could potentially work.

The goal is to switch over to gotatun asap. No specific timeline though, and we will roll it out slowly (most likely do one platform at a time). Switching the Android app over to gotatun has worked out very well and increased our confidence that we are able to move away from wireguard-go completely. There has literally been zero downsides for us this far: Better performance, smaller binary sizes, simpler builds and no crashes (while wggo stood for the majority of crashes in the Android app). We are excited for the future of gotatun.

For the Linux community, dropping wggo will simplify packaging. I know that nixpkgs go to great lengths to work around how we bundle wggo with the daemon atm.

Edit: If you build the app from source with cargo today, it is already the case that gotatun is used instead of wireguard-go*. It should work fine on Linux, but we have not tested or benchmarked it extensively yet. There is a known issue with glibc's malloc and memory fragmentation, but musl is more well-behaved from our testing :)

*On the 2025.14 release branch, you still need to pass --features boringtun when building mullvad-daemon. This won't be necessary in coming releases.

[meator]

What's the status of this PR? I see a do not merge commit. Are you waiting for a new upstream release?

[dkwo]

@meator That commit was just for experimenting with pure rust, it can be dropped. It is already working quite well.
@MarkusPettersson98 if I drop the wireguard-go and build 2025.14, the build fails even with that feature. Am I missing smth?

[meator]

By the way, split tunneling and mullvad-exclude do not work rootless without intervention here. The issue is mentioned here: https://old.reddit.com/r/voidlinux/comments/nw8eot/cgroup_permissions_mullvad/

mullvad-exclude fails because of the following syscall:

openat(AT_FDCWD, "/sys/fs/cgroup/net_cls/mullvad-exclusions/cgroup.procs", O_WRONLY|O_CREAT|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)

This file is -rw-r--r-- root root on Void, so writing it won't work.

I assume that this issue is caused by different handling of cgroups by systemd and Void. I don't have enough experience with cgroups to diagnose this further or propose solutions.

[dkwo]

Indeed, I also get the same from mullvad-exclude

Error: Cannot set the cgroup
Caused by: Permission denied (os error 13)

Mullvad recently added support for cgroups v2 (not sure in which version they are included though), and runit in Void uses v2 by now. It looks like this may not be runit-related, see e.g. mullvad/mullvadvpn-app#5532

[meator]

I don't think mullvad/mullvadvpn-app#5532 is relevant here. 2025.14_1 must be compatible with cgroups v2, it would fail to function on my system otherwise (or it would produce much more severe errors/warning messages). I have CGROUP_MODE=unified in my /etc/rc.conf (the current default).

The net_cls interface seems to come from cgroups v1, but it remained in v2 because it has no proper modernized counterpart. A different approach should be used in v2 instead (quote from cgroups(7)):

There is no direct equivalent of the net_cls and net_prio controllers from cgroups version 1. Instead, support has been added to iptables(8) to allow eBPF filters that hook on cgroup v2 pathnames to make decisions about network traffic on a per-cgroup basis.

The v2 devices controller provides no interface files; instead, device control is gated by attaching an eBPF (BPF_CGROUP_DEVICE) program to a v2 cgroup.

systemd has a whole per-user cgroup mechanism. This part of systemd's behavior is not replicated by elogind to my knowledge.

I'll try to ask around in #voidlinux tomorrow.

[dkwo]

My feeling is that even Mullvad devs are not satisfied with their current cgroup v2 implementation of split-tunneling, see e.g. mullvad/mullvadvpn-app#9430 (comment)