Change:
Describe the bug After upgrading mullvad to 2021.1 it can't connect to the servers properly. To Reproduce Configure mullvad service: Run GUI and try to connect to a WireGuard or OpenVPN server. For WireGuard it'll get stuck in the connecting state. For OpenVPN it will show that it's connected in the GUI, but there's no actual internet connection. Expected behavior The connection should be established successfully. Notify maintainers Metadata Maintainer information:
<details<summarymullvad-daemon log</summary</details
Is this still the case for 2021.2? Then I'll have a look at it.
I believe this is a with the daemon itself. I was wondering if could share more of their config to see how to trigger the issue. A minimal is not able to reproduce the issue.
Seems like NixOS's firewall is interfering with our netfilter rules. And even if I force the firewall to use a netfilter comptabile , it's still broken (but OpenVPN connects, but no traffic flows). We changed the way tunnel traffic is routed to rely on some netfilter rules to allow for split tunelling. The long and short of it is, I'll try and see if there's anything we can do daemon side to circumvent this issue, possibly adding if exist. Otherwise, you'll have to change the service to add permissive firewall rules to NixOS's firewall, and maybe even apply the nftables compatible package.
I'm having a similar issue with , my full config is available here: Some networking-related configs live here: I thought it was related to having tailscale enabled (both being wireguard) but removing tailscale didn't seem to help. I also tried switching from to but that didn't seem to help. <details<summaryjournalctl SYSTEMDUNIT=mullvad-daemon.service</summary</details
thanks for having a look! Which firewall rules would you need? Or shall we wait for you to try and fix it on your end first?
I've merged a for this already in our code. The issue was reverse path filtering. It seems that the default firewall does have a module to do that, so we a chain to mark traffic from the relay so that it passes the RPF. Users who have enabled strict reverse path filtering in kernel should also configure appropriately, otherwise the kernel won't take the firewall mark into account when evaluating the reverse route, thus filtering our traffic. The issues were stemming from the fact that we use policy based routing now, which is inherently at odds with reverse path filters unless our rules accommodate them. And now they do. We are still discussing if we should set the sysctl at runtime. On one hand, it's just a very bad thing to do. On the other, we don't know under what circumstances would a user want to have strict reverse path filtering in the kernel and not want a way to have policy based routing to work.
I've now tried the beta. It times out when connecting via wireguard. When it switches to OpenVPN, it shows , but all connections time out. When disabling the firewall, it works perfectly again. Here's some info: logs while trying to connect
I peeked at mullvad's code and it seems like it uses nftables which I assume causes issues in some way with iptables. Replacing iptables with just nftables as a workaround seems to have fixed wireguard with the newest beta for me. For reference here is the config I wrote to test with nftables (Still lacks most of the config needed for being a drop-in replacement for iptables): No idea what the best way to fix this is, or if it even is possible without disabling iptables and moving to nftables which is a bit out of scope for this issue.
So, I've found a fix. Setting will allow connection. As you were the last one to edit the firewall module, I'm pinging you: Is there a security implication if this module sets reverse path filtering to ?
There's precedent for disabling this when it breaks vpn modules, see [wg-quick][]. I don't want to make strong claims about security here. The reverse path filter is a security feature so disabling it necessarily affects security. If what wg-quick does is ok, then it should be ok here too. [wg-quick]:
Thanks for the feedback. I've opened a PR which acknowledges the potential security issue.
Have you tried our latest release? Regardless, I don't believe RPF done via iptables is any better than RPF done via the kernel, but I must assume that iptables allows for a more flexible configuration. Ideally, iptables RP filter would consider the packet mark during evaluation.
+1 to workarounds in this issue. To summarize for anyone else wanting to setup mullvad VPN on NixOS (as of 2021-08-04)... 1) Add the following to : 2) and . 3) 4) Follow
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I had a lot of headache making a WireGuard setup work with systemd-networkd, where all traffic is sent through wg tunnel. After a long amount of fiddling, I could make it work only with . Here is the config that worked for me, so that future me (and others) may suffer less:

Discussion:
default = false; description = '' This option enables Mullvad VPN daemon. <ins> This sets <option>networking.firewall.checkReversePath</option> to "loose", which might be undesirable for security. </ins> ''; };

# mullvad-daemon writes to /etc/iproute2/rt_tables networking.iproute2.enable = true; <ins> # See https://github.com/NixOS/nixpkgs/issues/113589 networking.firewall.checkReversePath = "loose"; </ins> systemd.services.mullvad-daemon = { description = "Mullvad VPN daemon"; wantedBy = [ "multi-user.target" ];

}; }; <del> meta.maintainers = [ maintainers.xfix ]; </del> <ins> meta.maintainers = with maintainers; [ ymarkus ]; </ins> }