Increasing the metric of default route in CentOS with DHCP

Question

I am setting up a server (VM to be precise) that runs CentOS 6.4. I have an eth0 adapter on the CentOS machine that has connection to the Internet (through a bridged network on the host). The eth0 adapter is configured through DHCP. So far, so good.

I also want to have a VPN client running on the server and to have it connect through the tun0 adapter to the Internet. The VPN client connects successfully using OpenVPN. It produces a default route with metric 0.

So, first of all, this is possible, right? Second, as far as I understand, there are 2 ways to go about this: increase the metric of the route that runs through eth0 or decrease the metric of the route that runs through tun0.

I have attempted to do both, but have been unsuccessful so far. I have tried these: adding a METRIC=100 line in /etc/sysconfig/network-scripts/ifcfg-eth0, however it does not change the metric of the route.

I have also tried adding a metric option to the client.conf file for OpenVPN. This also had no effect (I believe this to be due to there being a pull option in this file).

My most radical idea was to manually delete the route for eth0 and replace it with the same route, but with higher metric. Unfortunately, I can not do that either, as restarting the network will reset the settings and having a daemon running that does it all the time doesn't seem a good solution.

I am open to suggestions and ideas. Thanks.

Solution

So if I understand the problem correctly then you basically have a computer with an interface set to DHCP, and you want to connect to a VPN and pass all your traffic through the VPN.

You are having problems when the DHCP server renews the lease it is re-adding the gateway provided by the DHCP server.

I suggest you update your client.conf and replace the redirect-gateway option with the redirect-gateway def1. This instructs OpenVPN to add two routes that are more specific than the default gateway instead of removing the pre-existing default gateway and adding a new one.

When you use redirect-gateway def1 you get a route table that looks somewhat like below. Since the most specific matching route is the one that is used, the routes for 0.0.0.0/1, and 128.0.0.0/1 take precednce over the default route, but without the messy business of having to remove/replace the default route. It also removes the requirement that you make sure no other software change the default route.

# ip route
10.3.195.17 dev tun_rem  proto kernel  scope link  src 10.3.195.18 
172.26.222.0/23 dev eth1  proto kernel  scope link  src 172.26.222.204 
0.0.0.0/1 via 10.3.195.17 dev tun_rem 
128.0.0.0/1 via 10.3.195.17 dev tun_rem
default via 172.26.222.1 dev eth1 

If the redirect-gateway setting is not being set in your client.conf, then you may need to also add the "route-nopull option to ignore the routes being pulled from the VPN server.

Comments

[Zoredache]

What problem are you trying to solve that is resulting in you trying to mess around with your metric? Adjusting your metric, is almost certainly the wrong solution. If you are trying to redirect all your traffic over the VPN using the redirect-gateway option, then let me suggest you try redirect-gateway def1 instead. This options sets up a two routes (0/1, 128/1) instead of changing the default gateway.

[K.Steff]

Thank you for your comment, @Zoredache My problem is that I'd like to connect to the Internet through the OpenVPN tun0 adapter, and instead I have about 50% chance to do so, since both eth0 and tun0 provide Internet connection. You may be correct about metrics being the wrong solution. Could you elaborate further about redirect-gateway?

[K.Steff]

Thanks for not only solving the problem at hand, but pointing out my original idea for a solution was wrong. The help is very much appreciated.