Response traffic not going out on local interface with Local Network Sharing enabled [Linux]

[nicolaipre]

Is it a bug?

• [X] I know this is an issue with the app, and contacting Mullvad support is not relevant.

I have checked if others have reported this already

• [X] I have checked the issue tracker to see if others have reported similar issues.

Current Behavior

I have a VM in a certain VLAN which is running Mullvad VPN. To reach this VM I use a jump host (which sits in a different VLAN) and SSH into it. To be able to use Mullvad VPN while also being able to SSH into the VM, I enabled Local Network Sharing (10.0.0.0/8 covers both my VLANs).

I am using this exact same setup for a Windows VM and it works excellent. For my Linux VM with the same Mullvad VPN app config however, it does not work. While debugging the problem I discovered from tcpdumping that my SSH requests from the jump host actually reach the VM in question on the local interface (eth0), but the SSH response traffic is going out on the Mullvad VPN interface (tun0).

I have confirmed that Local Network Sharing is enabled which should allow this response traffic to flow over the local inteface (eth0), but my suspicion is that this is not respected by Mullvad. I have also tried adding routes manually to resolve the problem without much luck so far.

Expected Behavior

Allow response traffic for local subnets if Local Network Sharing is enabled.

Steps to Reproduce

1. SSH from jump host in separate VLAN to VM without Mullvad VPN running to confirm you are able to reach the VM.
2. Ensure Local Network Sharing is enabled in VPN Settings and connect to Mullvad VPN.
3. Run a tcpdump on eth0: $ tcpdump port 22 -i eth0. You will then see incoming SSH traffic, but no responses.
4. With Mullvad VPN still connected from previous steps, run a tcpdump on tun0: $ tcpdump port 22 -i tun0. You will now see the response traffic being sent over the Mullvad VPN link instead of the local interface.

Failure Logs

Not necessarily relevant, but can be provided upon request.

Operating system version

Kali Linux 2024.3 (Debian based)

Mullvad VPN app version

2024.5

Additional Information

No response

[MarkusPettersson98]

Hi, thanks for the bug report. We will look into this and report back when we know more :blush:

[MarkusPettersson98]

Hi again, would you mind sending a problem report to our support and providing a link to this GitHub issue? You'll find the problem report under Settings > Support > Report a problem :blush:

[nicolaipre]

Hi again, would you mind sending a problem report to our support and providing a link to this GitHub issue? You'll find the problem report under Settings > Support > Report a problem 😊

Sure thing. Report has been sent.

[MarkusPettersson98]

Thanks, it helps us a lot :blush:

[nicolaipre]

Related: #6219

[nicolaipre]

With some help I managed to solve the problem with these two commands after Mullvad has started and is running. In my case my VLAN is 10.0.1.0/24, where 10.0.1.12 is the IP address of the VM running Mullvad:

$ sudo ip rule add from 10.0.1.12 lookup main priority 100
$ sudo ip route add 10.0.1.0/24 dev eth0 table main

I am not sure whether this is the best solution to solve the problem or whether it can cause unintended leaks, but it works as a temporary fix.

Another edit Here is a better solution for those using NetworkManager. This script (/etc/NetworkManager/dispatcher.d/99-mullvad-route.sh) will ensure that the needed rule and route is added after Mullvad connects and also remove it once the VPN tunnel goes down:

#!/bin/bash

if [ "$1" == "tun0" ]; then
    if [ "$2" == "up" ]; then
        # Add the routing rules when tun0 is up
        ip rule add from 10.0.1.12 lookup main priority 100
        ip route add 10.0.1.0/24 dev eth0 table main
    elif [ "$2" == "down" ]; then
        # Delete the routing rules when tun0 is down
        ip rule del from 10.0.1.12 lookup main priority 100
        ip route del 10.0.1.0/24 dev eth0 table main
    fi
fi

$ sudo chmod +x /etc/NetworkManager/dispatcher.d/99-mullvad-route.sh