You can set up split tunneling yourself if you run the wireguard/OpenVPN daemon manually and move the “mouth” of the tunnel to a separate Linux network namespace.
You can set up split tunneling yourself if you run the wireguard/OpenVPN daemon manually and move the “mouth” of the tunnel to a separate Linux network namespace.
OVPN is a 1-to-1 feature clone of mullvad (wireguard, multiple device keys, crypto payments/cash in the mail, no usernames/emails, etc.) AND has port forwarding. Switched to them when mullvad sadly closed their ports, no problems since. Can’t live without port forwarding.
The exact script would depend on the use case; you’d use commands something like this:
mkdir -p /etc/netns/VPN sh -c 'echo nameserver 1.1.1.1 > /etc/netns/VPN/resolv.conf' ip netns add VPN ip link add tun1 type wireguard ip link set tun1 netns VPN
Because the wireguard device was created in the default namespace, it will “magically” remember its birthplace, even after you move its mouth (the tun1 device) to a separate namespace. The envelope VPN packets will keep going in/out in the default namespace.
ip netns exec VPN wg setconf tun1 /etc/wireguard/vpn.conf ip netns exec VPN wg set tun1 private-key /etc/wireguard/vpn-key.private ip -n VPN addr add 192.my.peer.ip/32 dev tun1
Get the wireguard config file from the VPN website, both mullvad and OVPN have a wizard to generate them. Your assigned private network ip is in the config file. Also get and save your device key.
ip -n VPN link set tun1 mtu 1420 ip -n VPN link set tun1 up ip -n VPN route add default dev tun1 ip netns exec VPN su myuser -c 'firefox --no-remote'
Now all firefox (and only that firefox) traffic will go through the tunnel. Firefox has its own DNS, if you run another app it will use 1.1.1.1.
I actually do the reverse of this - I create a namespace ETH and move my eth0 device in there and attach dhcpcd to it. Then I create the wireguard tun1 device inside ETH namespace, and move tun1 to the default namespace. Then any software I run can only use the tunnel, because the ethernet device doesn’t even exist there. This keeps the routing table simple and avoids a whole class of issues and potential deanonymization exploits with the split routing table used in traditional single-namespace VPN configurations.