On Sat, 1 Jul 2006, Christian Holler wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
today I discovered a bug that is not easy to trigger but causes the
"get_default_gateway" function to fail in some cases. This function
is, as you surely know, used for example when "net_gateway" is pushed
by the server as an option to the route command and should return the
default gateway so a route can be set via that default gateway.
(Version: 2.0.7)
Both in the linux and windows code, you assume that this gateway is
non-zero (see lines 1055 and 1295 in route.c). This is normally the
case, but has not necessarily to be always like that. For example,
when you want to use openvpn in an environment, where already other
programs use tun devices to reroute the traffic, then default routes
may appear which look like this:
(route -n output on linux)
Destination Gateway Genmask Flags Metric Ref
Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0
0 tun0
This is fully valid with tun devices, but because the gateway is
0.0.0.0, the get_default_gateway function fails to find this correct
route and fails.
Solution: Do not rely on gateway to be nonzero, and honor Iface when
setting the default route. This can be fixed easily with small
modifications to the windows and linux version of this function and
how it is used. (Make get_default_gateway return a whole route
structure in side effect instead of only the gateway address. This
route structure should also include the Iface then).
I discovered this bug while I was trying to use openvpn with a server
that uses net_gateway in push instruction from within an environment
that uses vpnc (another VPN client) to connect to a VPN which is
required to get online at all. This other VPN client already reroutes
all traffic through a tun device as described above, and this is fully
valid, but openvpn fails then to find this route, so
get_default_gateway fails.
If this is being fixed, the function should probably be renamed to
"get_default_route", because it does not need to be a gateway
necessarily. Default routes don't need to have any gateway as shown in
the above example.
It would be very helpful for me if this would be fixed as this is what
causes openvpn not work in our environment, and if you wish, then I
can write a patch for it as well.
Yes, if you could write a patch, that would great.
Thanks,
James
