Hi,
On 02/10/2020 19:57, Gert Doering wrote:
> Commit aa34684972eb0 fixed a long-standing bug in setting the
> "route-list" flag RTSA_REMOTE_HOST for IPv4 ("we have a well-defined
> remote_host == VPN server IP address") even if connecting over IPv6.
>
> Unfortunately the logic in redirect_default_route_to_vpn() was also
> wrong, and refused cooperation if that flag is not set, triggering
> the message
> "NOTE: unable to redirect IPv4 default gateway -- Cannot
> obtain current remote host address"
>
> Correct operation: if RTSA_REMOTE_HOST is not set, or remote_host
> is IPV4_INVALID_ADDR (= 255.255.255.255), do not try to install a
> host route for continued connectivity to the VPN server - which is
> not needed when connecting over IPv6. But the actual *routes*
> (/0 or 2 x /1) can be installed just fine.
>
> There is a second bug here, which hits if there is no IPv4 gateway
> at all. In that case, the same function triggers the message
> "NOTE: unable to redirect IPv4 default gateway -- Cannot
> read current default gateway from system"
>
> This is caused by using "IPV4_INVALID_ADDR" as a flag for "do we
> know the remote_host?" - which worked before, but after the commit
> said above, the "remote_host" field is not well-defined unless
> RTSA_REMOTE_HOST is set. So, change the condition to check that.
>
> Reported-By: François Kooman <fkoo...@tuxed.net>
> Reported-By: Thomas Schäfer <tschae...@t-online.de>
> Trac: #1332
>
> Signed-off-by: Gert Doering <g...@greenie.muc.de>
The bug becomes obvious after reading commit aa34684972eb0
This fix is basically cleaning up some conditions which did not adapt to
the new logic.
Stared at the code and tested on my system with and without an IPv4
default route.
Signed-off-by: Antonio Quartulli <a...@unstable.cc>
--
Antonio Quartulli
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
