[plug] Multiple routes

[Daniel Pittman]

Brad Campbell <brad at wasp.net.au> writes:

> I have an odd configuration I need some advice on.
>
> My home network is 192.168.2.0/24 I have a VPN using openvpn that is
> 10.8.0.0/24 that works almost everywhere. This pushes a route to
> 192.168.2.0/24 and when I'm out and around I can seamlessly access my home
> network.
>
> A facility that I work at intermittently has a very tight firewall, and to
> penetrate it I've had to use another instance of openvpn using tcp and a
> specific port - network 10.8.3.0/24. I don't want to use this all the time
> as it's less efficient than my normal stock udp vpn instance.
>
> I have both tunnels up simultaneously and they both push the 192.168.2.0/24
> route.  So, when I'm at home I have all the routes up, but as the network is
> the default it's all good.
>
> When I'm out I have to restart openvpn to get a working route to my home
> network (or hand modify the routing table. Not hard, but then I should not
> have to think about it).

You probably want to set a higher metric on the less desired route, at which
point traffic will take the preferred (lower metric) option ... until it
vanishes.

    --route-metric=50  # set the default route metric

You can also specify that in the --route command, which you could also send as
part of the push, if you want server-side control over routing preferences on
the client.

> When I restart openvpn outside the restrictive firewall, the udp instance
> always establishes first, so I get the best route straight out of the bag.
>
> When I move into the restrictive firewall, that openvpn instance is still
> live and tries to route over that. When I restart openvpn, the udp instance
> fails to connect, so I get the route over the right tunnel.
>
> What could I use that would try each route and just make it work?

Both at once, route metrics to select between them.

You can even have that configured so you assign a metric of 0 to your physical
internal network device, 10 to the UDP tunnel, 20 to the TCP tunnel, and have
the entire thing work transparently regardless of physical location.

        Daniel

-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons