"DEFROUTE" in RHEL, CentOS or Fedora - a usage case for eth0

Here is the situation: There is a user with a remote office that includes networking equipment like printers, backup server etc. He uses a company provided CentOS laptop as the gateway for his network via a cell card since there is no other cheaper option available to get him connected. He travels with the laptop often and I don't need access to the equipment at his office unless he's there. The user always connects either via WIFI or a cell card for VPN connection depending on what is available. The laptop is running openvpn and is connecting to our company's openvpn server. No problem... until I want to also connect the laptops ethernet cable and use NetworkManager and use a DHCP server for the eth0... That's when the VPN drops and the laptop now has an incorrect default route. What's odd is that order of interface startup does not matter... dhcp on eth0 wins no matter what... bummer.


What's happening? Well, normally with DHCP, the client is given a default route as part of the information exchange. That eth0 default route takes over. It's just that simple... unless you give the networking system guidance on what to do in the form of the "DEFROUTE" option. The option has been around for a long time. The current Red Hat Enterprise Linux 6 Deployment Guide has DEFROUTE option hidden in the 8.2.4. Dialup Interfaces section. Here is a chunk of the information from the guide:

DEFROUTE=answer

where answer is one of the following:

• yes — Set this interface as the default route.
• no — Do not set this interface as the default route.         

In the past, I did not use the DEFROUTE option. I found that I could just statically assign the eth0 and *not* let NetworkManager have access to it (NM_CONTROLLED=no). In fact with Centos (and the like), NM seems to get disabled as a generally rule.

Also, if this was a server or I wanted to statically assign the interface, it would not be an issue. Just one of those fringe usage cases.