Possible to create a qube to proxy other qubes’ traffic using SOCKS?

Unfortunately, Mullvad only permits up to 5 devices in an account.

I’m in a situation where I need a different IP for a few of my qubes.

Creating many sys-mullvad NetVMs wouldn’t be an option.

Would it be possible to do something akin to the Mullvad Browser extension which allows you to set a different relay for each domain, but for whole qubes instead?

My ideia would be to have a sys-mullvad-proxy qube in which there would be a mapping (qube name x relay) like so:

“john” → relay 1
“work” → relay 2
“dev” → relay 3

and it’d somehow route traffic from a qube to its respective relay. Or, if the qube isn’t listed, it’d pick a random relay and persist.

The list of relays would be refreshed daily in a separate qube, similar to how it’s done here GitHub - maximko/mullvad-socks-list: List all active mullvad socks servers and resolve its internal addresses, and copied over to sys-mullvad-proxy.

I’m not well versed with Linux networking. Has someone done similar? How would it know from which qube the traffic is originating from? The IP address of the Qubes virtual network?

Thanks.

Yes, this is definitely possible in Qubes, and the general approach is similar to how VPN gateway qubes are usually set up. You can create a dedicated qube that runs a SOCKS proxy and then route other qubes through it by setting that qube as their NetVM or by enforcing it with firewall rules.

A couple of things to keep in mind:

Using a separate proxy qube fits well with Qubes’ security model, but you’ll want to be careful with firewall rules so that traffic can’t bypass the proxy unintentionally.

SOCKS works well for application-level traffic, but it won’t automatically catch everything unless the client is explicitly configured to use it. Some people combine this with iptables/nftables rules to force traffic through the proxy qube.

The VPN gateway qube docs are a good reference, even if you’re not using a VPN, because the network flow concepts are the same.

If your goal is to route traffic through a specific endpoint—say, something behaving like a (mod edit: removed advert backlink) proxy — you’d just configure that as the upstream proxy inside the proxy qube and make sure other qubes don’t have a direct path to NetVM.

Overall, it’s a clean and flexible setup once you get the routing and firewall rules right.

Yeah, I did a successful PoC a couple of years ago:
https://zrubi.hu/2018/redsocks/

Where the goal was to create a transparent SOCKS proxy in Qubes.
As it was a long time ago, so it’s outdated for sure. But the main concept is still the same.

And as I recently lost the English versions of my blog posts, you might need to use google translate to read it :unamused:

It might be available on webarchive :slight_smile:

Well, I have them in a backup…somewhere. It’s just not worth the time diging them up and restoring them.
Here is the full story - in English :slight_smile:
https://zrubi.hu/en/2025/lost-in-translation/

1 Like