removing incorrect route on exit

[agowa338]

I have only the following static routes set (before OpenVPN is started):
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.10
192.0.2.146 via 192.168.0.1 dev eth0

The OpenVPN config has redirect-gateway def1 set and the Server has the IP 192.0.2.146.

Now when OpenVPN connects it adds the route for the default gateway through the VPN tunnel as it should.
It also tries set /sbin/ip route add 192.0.2.146/32 via 0.0.0.0 which throws a warning with RTNETLINK answers: No such device.
This is not an issue. But once OpenVPN exits it tries to cleanup the routes and thereby deletes the wrong one. It deletes the one previously existed and that points towards the OpenVPN server. And therefore it won't be able to be restarted.

Routing table after OpenVPN exited:
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.10

[Gert Döring]

Part of "def1" is "install a host route for the VPN server" (so it can reach the server "outside"). I think it is getting confused because it tries to find the default gateway, and fails.

The IPv6 "find gateway" code is more robust, so that might help ;-)

But besides that, it should not try to clean up a route that failed to install. Can you show a more complete log file with --verb 3, please, showing one complete openvpn run from start to route addition to end?

Which openvpn version is that (well, the log will show)?

[Selva Nair]

I can reproduce this.

We set the direct IPv4 route to server in redirect_default_route_to_vpn() which uses add_route3() and there is no way to save route flags like RT_ADDED. The route is deleted using del_route3() which always sets r.flags = RT_DEFINED|RT_ADDED before calling delete_route().

I do not clearly understand why these and some other bypass routes are set like this instead of adding them into the route list which will use add_routes()/delete_routes(). There RT_ADDED flag is saved and checked before deleting.

[Gert Döring]

We are looking into all these special cases for route addition/deletion and "error on addition leads to confusion on exit".

As Selva says, it's a bit unclear why we are not using the "delete route using the standard mechanism" approach (route_list -> del_routes()), but maybe this was done so a specific sequence could be enforced on deletion. Or maybe the code just evolved over time.

I am putting this to milestone 2.7.0, as "rework all this" is on our agenda for right after 2.6.0 release (next week).

(We can then also have a look which of these patches that went into release/2.6 we consider "real bugs" as opposed to "making operations more smooth" and backport to release/2.5 - this one, deleting a route that wasn't created by us, is something I consider a "real bug", but if the code change is too big, it might still not be backportable. We'll see).