Re: SIOCDELRT, or: proper syntax to delete default route for an interface?

[Matt Ventura <mattventura@mattventura.net>]

On 01/23/2015 04:05 AM, Sven Hartge wrote:
> Matt Ventura <mattventura@mattventura.net> wrote:
> > > me@client:~$ date ; sudo route -n
> > > Thu Jan 22 11:48:48 EST 2015
> > > Kernel IP routing table
> > > Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> > > 0.0.0.0         10.144.15.100   128.0.0.0       UG    1      0        0 ppp0
> > > 0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
> > > 10.144.0.1      0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
> > > 128.0.0.0       10.144.15.100   128.0.0.0       UG    1      0        0 ppp0
> > > 134.67.15.30    10.8.0.5        255.255.255.255 UGH   1      0        0 tun0
> > Try it with 0.0.0.0 instead of default. I didn't notice that the netmask
> > was 128.0.0.0 rather than 0.0.0.0. Not sure why it would do that or if
> > that has some kind of special meaning.
> VPN clients normally use two routes as "default" route:
>
> 0.0.0.0/128.0.0.0    (or 0.0.0.0/1)
> 128.0.0.0/128.0.0.0  (or 128.0.0.0/1)
>
> This way, the VPN client does not need to replace the existing default
> route. Because those two new route are more specific than 0/0, all
> packages are routed into the tunnel and not to the old default gateway.
>
> If the VPN client crashes (or the tunnel interfaces is removed) those
> two routes are automatically removed too and the old default route is
> active again.
>
> If the client replaced the old default route then you would be left with
> a system without any default route, because the new one would have been
> deleted together with the tunnel interface.
>
> Grüße,
> Sven.
Well, that confirms my original suspicion. The F5 VPN is throwing its 
default route over the original one, and that's causing traffic to the 
OpenVPN server to try to route over the F5 VPN. Obviously this doesn't 
work because the traffic to the F5 VPN needs to go through the OpenVPN 
link, so it becomes circular.

What you need to do is add a route, something like:
route add <external IP of OpenVPN server> gw 192.168.1.1 dev eth0
so that the traffic to the OpenVPN server can be routed properly.

Matt Ventura