List which kernel config options are required in the README

[GarbageHamburger]

Issue report

Operating system: Gentoo Linux 17.1

App version: 2020.4

Issue description

Mullvad expects some unknown set of kernel config options to be enabled. I can't see any documentation on which ones should be (if there is, please close this issue & point me at it). Please list the kernel configuration options which must be enabled in the README.

[pinkisemils]

We've not thought about this because we never considered supporting Gentoo officially. But in general, the daemon expects to have nftables to work and for split tunneling we need cgroups V1. And currently we need the ability to create tunnel devices, in the future, we'll optionally support the WireGuard kernel module. We can have a look at formalizing this list in the future, this is just everything I can come up with off the top of my head for now.

[faern]

@GarbageHamburger If you happen to find any kernel config that is not enabled by default and that our app needs, please help us populate this list by writing it here.

[genbtc]

Completely disabling CONFIG_IPV6 unfortunately results in a completely unusable mullvad-daemon, with the log reporting simply "Failed to set firewall rules" coming out of the rust talpid core ( mullvadvpn-app/talpid-core/src/firewall/linux.rs ). This file does all its work for ipv4 and ipv6 all at once, so not having anything in the kernel for ipv6 to work just ruins everything. Additionally, it requires a bunch of the NETFILTER options. CONFIG_NF_TABLES_IPV6 along with at least CONFIG_NFT_CHAIN_NAT_IPV6 , and I'm guessing CONFIG_IP6_NF_MANGLE - (similarly, the IPV4 versions.) This is my preliminary assessment.

[faern]

Thanks for reporting this. Even though no major distro comes with IPv6 completely disabled in the kernel, it makes sense to support it. We'll look into it and see if it's easily fixable.

[kopr12]

Anything new ? Is IPV6 still a must in the kernel ?

[faern]

Is IPV6 still a must in the kernel ?

Yes

[genbtc]

Anything new ? Is IPV6 still a must in the kernel ?

So far, a Must, yes. But I am using a workaround. compile IPV6 as a module and then boot with the kernel command line: ipv6.disable=1

When mullvad-daemon launches, it is able to request the kernel load the ipv6 module, which it does load (along with all the other netfilter modules) And the kernel reports this in dmesg, confirming the ipv6.disable=1 boot param was successful:

"IPv6: Loaded, but administratively disabled, reboot required to enable"

After that point, Mullvad still works in this state. (despite being officially unsupported) because no ipv6 traffic can be routed and the kernel knows how to enforce this boundary.

Having the ipv6 codepath be required at all is not ideal, but it seems possible that the codepath can be deactivated and made dormant with this method.

I believe this is effective in achieving my own goals, and I am posting it here to expand on the subject for information only. gl :)

[kopr12]

I see, well I started using Mullvad vpn few days ago, and it's working fine with OpenVPN. With Mullvad app I get errors, which are kernel related.

[mullvad_daemon::version][INFO] Starting mullvad-daemon - 2023.3 2023-04-05
[mullvad_daemon][INFO] Logging to /var/log/mullvad-vpn
[mullvad_daemon::rpc_uniqueness_check][DEBUG] Failed to locate/connect to another daemon instance, assuming there isn't one
[mullvad_daemon][INFO] Management interface listening on /var/run/mullvad-vpn
[mullvad_api::address_cache][DEBUG] Loading API addresses from /var/cache/mullvad-vpn/api-ip-address.txt
[mullvad_api::address_cache][DEBUG] Using API address: 45.83.223.196:443
[mullvad_api::availability][DEBUG] Suspending API requests
[mullvad_daemon::settings][INFO] Loading settings from /etc/mullvad-vpn/settings.json
[mullvad_daemon::version_check][DEBUG] Loading version check cache from /var/cache/mullvad-vpn/version-info.json
[mullvad_daemon::version_check][WARN] Error: Unable to load cached version info
Caused by: Failed to open app version cache file for reading
Caused by: No such file or directory (os error 2)
[mullvad_relay_selector][DEBUG] Reading relays from /var/cache/mullvad-vpn/relays.json
[mullvad_relay_selector][DEBUG] Reading relays from /opt/Mullvad VPN/resources/relays.json
[mullvad_relay_selector][INFO] Initialized with 700 cached relays from 2023-06-24 14:29:04.027
[mullvad_api::availability][DEBUG] Pausing background API requests
[mullvad_daemon::account_history][INFO] Opening account history file in /etc/mullvad-vpn/account-history.json
[mullvad_daemon::target_state][DEBUG] No cached target state to load
[mullvad_daemon][ERROR] Error: Unable to initialize daemon
Caused by: Tunnel state machine error
Caused by: Failed to initialize the route manager
Caused by: Internal route manager error
Caused by: Netlink error
Caused by: Received a netlink error message Operation not supported (os error 95)
[mullvad_daemon][DEBUG] Process exiting with code 1
[mullvad_daemon::device][DEBUG] Account manager has stopped

If I understand correctly, the Mullvad app relies on Wireguard, so I followed Gentoo Wiki to set it up, basically it's just a matter of enabling one option in the kernel and emerging wireguard-tools, which I did, app was giving the same error message, but interestingly enough, I couldn't manually bring up Wireguard interface. Again, something else is missing in the kernel, which is interesting because I think I followed that Wireguard Wiki completely.

# wg-quick up wg0                                                                                                                                                                                                                       ─╯
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 192.168.1.16/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
RTNETLINK answers: Operation not supported
[#] resolvconf -d wg0 -f
[#] ip link delete dev wg0

@genbtc , do you maybe happen to know exactly which options are needed in the kernel for the mullvad app? (to save me some time)

[genbtc]

You don't need to interact with the wireguard-tools, in fact you won't even need them. i suppose it goes to show the failure: RTNETLINK answers: Operation not supported meaning you need netlink and netfilter modules, ~and they are too complicated for me to enumerate other than~ pasting the list of lsmod for what i have working: https://gist.github.com/genbtc/f1a3b07a1a63bdaa12b1560a707ed237

preliminary list:

CONFIG_WIREGUARD CONFIG_IPV6 CONFIG_NETFILTER CONFIG_NETFILTER_NETLINK CONFIG_NF_TABLES CONFIG_NET_UDP_TUNNEL CONFIG_NF_TABLES_IPV6 CONFIG_IP6_NF_MANGLE CONFIG_NFT_CT CONFIG_NFT_MASQ CONFIG_NFT_NAT ( nft_chain_nat module) CONFIG_NFT_REJECT CONFIG_NFT_REJECT_INET CONFIG_NF_REJECT_IPV6 CONFIG_NF_REJECT_IPV4

possibly: nf_log_ipv4 16384 4 nf_log_common 16384 1 nf_log_ipv4

iptable_filter 16384 1 iptable_mangle 16384 0 iptable_nat 16384 0

nf_nat 40960 3 nft_masq,nft_chain_nat,iptable_nat nf_conntrack 122880 4 xt_conntrack,nf_nat,nft_ct,nft_masq nf_defrag_ipv6 20480 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack ip_tables 28672 6 iptable_filter,iptable_nat,iptable_mangle

[kopr12]

Much appreciated! Will try and log which options exactly I've enabled, until I get it working, then will post the findings here.

[kopr12]

btw I used wireguard-tools because app is not working, so I first went with Wireguard config from the Mullvad, that didn't work either so I finally went with OpenVPN, which worked fine on the first try and which I still use (only way for me to use mullvad vpn currently)

Anyway, I tried enabling those options from your preliminary list, some I already did have enabled, some were enabled by enabling the other one from the list, here's what I've enabled (was missing from that list) :

CONFIG_NF_TABLES
CONFIG_NF_TABLES_IPV6
CONFIG_IP6_NF_MANGLE
CONFIG_NFT_CT
CONFIG_NFT_MASQ
CONFIG_NFT_NAT
CONFIG_NFT_REJECT

I still get the same error both from mullvad dameon and wireguard. Didn't went with "possibly" / lsmod list, will try that some other time. I know it's hard to pinpoint exactly which ones are needed, it is what it is.

[kopr12]

Got it to work, what worked is what I should have done in the first place, to follow the error messages. So, the error said "Failed to initialize the route manager", so I went in kernel and searched for "route", enabled everything network related, there were maybe 5 or 6 of them, 10 tops. After that I got this error :

It actually said what to look for (net_cls) After that one enabled, daemon started without errors.

That's that I guess, it all depends which modules someone already has enabled or not, but if you follow the error messages you will get there in the end.

[dominic-espo]

Got it to work, what worked is what I should have done in the first place, to follow the error messages. So, the error said "Failed to initialize the route manager", so I went in kernel and searched for "route", enabled everything network related, there were maybe 5 or 6 of them, 10 tops. After that I got this error :

It actually said what to look for (net_cls) After that one enabled, daemon started without errors.

That's that I guess, it all depends which modules someone already has enabled or not, but if you follow the error messages you will get there in the end.

Would you mind sharing you kernel config file? I can get the mullvad-daemon to run at boot, but I have no internet access. Mullvad works just fine with gentoo-kernel-bin though.

[kopr12]

Actually I quickly dropped that config and went back to the old one, realized I don't need the app at all. I still use mullvad vpn but I start it with OpenVPN.

Yes, it works with gentoo-kernel-bin, that's what I first tried, just to make sure it's something in the config that I'm missing, then I was curious to find the missing items in my config, it was a pain at first but like I said, if you follow the error messages it's kinda easy, search for it in the kernel, like for example (tunnel) and enable what seems logical etc.

[dominic-espo]

By emerging wireguard-tools I was able to see what config options needed to be enabled by reading the warnings from portage. The Mullvad daemon is working now.

[danbreu]

Just adding this here to hopefully help the next person:

mullvad-daemon[77639]: [mullvad_daemon][ERROR] Error: Unable to initialize daemon
mullvad-daemon[77639]: Caused by: Unable to initialize split tunneling
mullvad-daemon[77639]: Caused by: Unable to initialize net_cls cgroup instance
mullvad-daemon[77639]: Caused by: EINVAL: Invalid argument

This error message [same as in the screenshot above, but now searchable ;)], was caused in my case by having cgroup v1 disabled ("cgroup_no_v1=all" in kernel params). Which is a required dependency as indicated by @pinkisemils.