Details like...? If you configure/push an IP with a subnet (i.e. non /32 prefix or 255.255.255.255 subnet mask) to a client, a subnet route will be added to main route table (as show by `ip r`) by the kernel just like on Desktop Linux (at least that's what would happen on my device). When I use ics-openvpn without openvpn3 box checked or OpenVPN Connect, the route would be in effect so I don't need to push/configure one explicitly to the client for it to be able to reach the server (or vice versa) via the tunnel. But if I use ics-openvpn with the openvpn3 box checked, apparently the route is not in effect (but still added), and therefore for it to be able to reach the server, I would need to push/configure a route explicitly.
On Tue, 12 Nov 2019 at 02:02, Arne Schwabe <a...@rfc2549.org> wrote: > > Am 11.11.19 um 16:12 schrieb Tom Yan: > > Yes both iproute2 and sitnl works perfectly as expected. Will the fix > > be backported to the 2.4 branch? > > > > P.S. For the record, if the client is ics-openvpn with openvpn3, > > somehow you need push route (either host or subnet will do) anyway. > > I am not aware of this issue. Could you go more into detail? > > > This is not necessary with ics-openvpn with openvpn2 or OpenVPN > > Connect (AFAIK its core is openvpn3 as well, albeit different > > snapshot). The problem/behaviour is not specific to /31 subnet though, > > apparently. I guess the main route table is ignored/masked. > > ics-openvpn is a) OpenVPN master b) uses a completely different logic to > handle network config (in OpenVPNService.java). So this patch does not > affect ics-openvpn in any way. > > Arne > > > _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
