I have a Linux machine that is always connected to a VPN (vpn0 interface), and the default route goes through the vpn0 interface. The connection to my router is done through the wlan0 interface.

I do like the fact that it routes everything through the VPN, and there are reasons to keep this config. But since the VPN is quite slow, I would like to be able to launch a few specific applications with a different default route: one that goes directly through wlan0 instead of vpn0. I don't want, for example, my apt-get update or browser-running-web-radio-streaming to go through the VPN.

I googled a lot for this, and didn't really find anybody with the same problem. One solution that I found requires me to use eth0: I'd connect eth0 to the network, create a new network namespace, and then move eth0 to this new namespace and use it normally. Then I can launch apps on it using ip netns exec nsname command. The big problem with this solution is that it requires me to connect both through eth0 and wlan0, and I am looking for a solution that uses just wlan0 - since these days a lot of machines don't even have ethernet.

It seems the way to go would be: create a new network namespace, create a virtual ethernet pair (veth0 and veth1), move veth1 to the new namespace, and then do some magic to route the stuff from the other network namespace to use wlan0 as a gateway instead of vpn0.

Since veth1 is on the new NS, and veth0 is on the default NS, and both are connected, I guess we probably want to find a way to redirect the veth0 traffic to use a different route (or routing table?) than the standard one. It seems I could use "policy based routing", but so far all my attempts have failed. Also, since wlan0 does not allow the same cool features as eth0 (such as attaching to bridges), this solution would probably involve some sort of nat/masquerading.

Can anybody give me a light here? Maybe a patch to the script below?

Note: the wlan0 interface has an IP, and the wireless router is Also, the apps inside the VPN need to use http_proxy and friends, but I don't need this when I'm not on the VPN.

I have tried many different things, but this is a list of most of the commands I tried:

echo 1 > /proc/sys/net/ipv4/ip_forward

# Create the novpn namespace, the virtual interfaces and configure them
ip netns add novpn
ip link add name veth0 type veth peer name veth1
ip link set veth1 netns novpn
ifconfig veth0 up
ip netns exec novpn ifconfig veth1 up

# Route stuff from veth0 to wlan0 using NAT. I don't know if this is
# really what I want because it uses the default routing tables
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
iptables -A FORWARD -i veth0 -j ACCEPT

# Do some magic to configure the routing tables on the new NS
ip netns exec novpn ip route add default via ?.?.?.? dev veth1

# Maybe try to route some stuff with a new routing table called novpn:
ip rule add iif veth0 lookup novpn
ip route add default dev wlan0 table novpn
ip route ???
ip route flush cache

I was also told that maybe I could use a setup that involves routing just the "internal" traffic through the VPN, but I don't really want this.


It is actually easier than that.

What you need to do is to set up policy routing so that you have two distinct routing tables, and a rule that tells your pc when to use either one.

You start your vpn, and let us assume you have a tap0/tun0 interface with IP address, and a wlan0 interfce with address

We now need to set up policy routing:

 echo 201 novpn >> /etc/iproute2/rt_tables
 ip route add dev wlan0 src table novpn
 ip route add default via table novpn
 ip rule add from table novpn
 ip rule add from table main

and you are now done. You will have to bind specific applications to either interface depending upon whether you wish to use or not the VPN. Binding an application to an interface is generally easy, except for the notoriously sticky Firefox, for which you may wish to read this Web page.

Remember that you are allowed a single set of DNS servers, as specified in /etc/resolv.conf. You should make sure that at least one of them is accessible to either interface: if the VPN specifies both of them to be inside the remote LAN, name resolution for the second, nonVPN interface will not work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.