- Tumbleweed (6.19.9.1-default)**
- Mullvad-vpn 2026.1
- (installed via importing the rpm repo asc signatures and installing the rpm).**
Human TLDR;
Basically, for the past month or so I’ve been running tumbleweed and using tailscale as my local-network VPN. To enable this, I used the steps found in this article by, “Jake Howard”. Things worked (and currently work) fine between tailscale and mullvad after this change.
Anyway, I have a steam .desktop file that runs mullvad-exclude on steam so it and its children PIDs are excluded from the tunnel. Today, after running a dup for the first time in about two weeks, my steam “mullvad-exclude” workaround only works on first boot. This allows me to connect to the steam store, but not play online (which I was able to do previously). After disconnecting and reconnecting to the VPN, now steam can’t talk with its servers period, meaning no steam store and certainly no online play.
I have the tumbleweed version of steam and the rpm version of mullvad and they used to play nice. They no longer do and i have no clue why. The same happens with discord (to a lesser extent) but that’s less annoying overall. Not being able to play games with buddies does make me kinda frustrated though.
If you want the details on what I did, there’s an AI summary below.
NOTE:
Hey so if you want the nitty-gritty, I have an AI overview below, since I used Claude to try and troubleshoot what was going on. A tldr actually written by me is above. I legit feel like the AI summary is the best I could provide given that the troubleshooting steps taken would be butchered by me trying to explain them properly. Lmk if I messed up taking this route of troubleshooting.
AI-Generated Summary of Troubleshooting steps.
I have tumbleweed and tailscale coexisting on my system via rules shown in this article. Steam is launched via mullvad-exclude through a custom desktop entry to bypass the VPN. On fresh boot, Steam connects and works fine. However, after disconnecting and reconnecting Mullvad, Steam fails with error 118 (no connection) in the bootstrap/update phase, with the logs showing http error 0 on manifest downloads from akamai.steamstatic.com and steamstatic.com, timing out after ~8 seconds each.
Initial investigation with ss -tp showed steamerrorrepor processes making connections via 10.144.x.x (Mullvad’s DNS/interface), and mullvad-exclude list confirmed Steam’s PIDs were registered for exclusion. DNS was ruled out as the cause — mullvad-exclude dig resolved Steam domains correctly, and mullvad-exclude curl to store.steampowered.com hung at TCP connect stage rather than failing at DNS. ip rule list showed the exclusion fwmark rule (not from all fwmark 0x6d6f6c65 lookup 1836018789) present on both IPv4 and IPv6 after reconnect, so that wasn’t the issue either.
Checking ip route show table 1836018789 (the exclusion routing table) showed default dev wg0-mullvad both before and after reconnect — this initially looked suspicious, but a working mullvad-exclude curl on fresh boot with the same route confirmed this is normal; Mullvad’s exclusion works primarily through nftables fwmark/cgroup rules rather than that routing table.
Comparing nft list ruleset between working (fresh boot) and broken (post-reconnect) states showed the rules are virtually identical — the only difference being the Mullvad server endpoint IP/port changing as expected on reconnect. Critically, the exclusion rule in the mangle chain — meta cgroup 5087041 ct mark set 0x00000f41 meta mark set 0x6d6f6c65 — is present and unchanged in both states. This suggests the rules are correct but the cgroup ID 5087041 may no longer match Steam’s actual cgroup after a reconnect, meaning packets from Steam never get marked for exclusion and fall through to Mullvad’s default-drop policy.
The next step would be to verify whether Steam’s processes are still in cgroup 5087041 after a reconnect (cat /proc/$(pgrep -f steam | head -1)/cgroup) and whether the exclusion mark is actually being applied to Steam’s packets via nft monitor trace. This points to a possible regression in Mullvad 2026.1 where the cgroup used for split tunneling exclusion is not correctly reassigned or reattached after a tunnel reconnect. (not sure if that last sentence is legit or just claude hallucinating, I’m not smart enough to know or waste maintainers’ time with a hallucinated bug)