We used to add "route for this subnet" by using our own address as the gateway address, which used to mean "connected to the interface, no gateway". FreeBSD commit 293159 changed the kernel side of that assumption so "my address" is now always bound to "lo0" - thus, our subnet route also ended up pointing to "lo0", breaking connectivity for all hosts in the subnet except the one we used as "remote".
commit 60fd44e501f200 already introduced a "remote address" we use for the "ifconfig tunX <us> <remote>" part - extend that to be used as gateway address for the "tunX subnet" as well, and things will work more robustly. Tested on FreeBSD 11.0-RELEASE and 7.4-RELEASE (client and server) (this particular issue is not present before 11.0, but "adding the subnet route" never worked right, not even in 7.4 - 11.0 just made the problem manifest more clearly) Trac #425 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207831 Signed-off-by: Gert Doering <g...@greenie.muc.de> --- src/openvpn/tun.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index af685de..a6d38d5 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -721,8 +721,8 @@ void delete_route_connected_v6_net(struct tuntap * tt, * is still point to point and no layer 2 resolution is done... */ -const char * -create_arbitrary_remote( struct tuntap *tt, struct gc_arena * gc ) +in_addr_t +create_arbitrary_remote( struct tuntap *tt ) { in_addr_t remote; @@ -730,7 +730,7 @@ create_arbitrary_remote( struct tuntap *tt, struct gc_arena * gc ) if ( remote == tt->local ) remote ++; - return print_in_addr_t (remote, 0, gc); + return remote; } #endif @@ -1230,6 +1230,8 @@ do_ifconfig (struct tuntap *tt, #elif defined(TARGET_FREEBSD)||defined(TARGET_DRAGONFLY) + in_addr_t remote_end; /* for "virtual" subnet topology */ + /* example: ifconfig tun2 10.2.0.2 10.2.0.1 mtu 1450 netmask 255.255.255.255 up */ if (tun) argv_printf (&argv, @@ -1242,12 +1244,13 @@ do_ifconfig (struct tuntap *tt, ); else if ( tt->topology == TOP_SUBNET ) { + remote_end = create_arbitrary_remote( tt ); argv_printf (&argv, "%s %s %s %s mtu %d netmask %s up", IFCONFIG_PATH, actual, ifconfig_local, - create_arbitrary_remote( tt, &gc ), + print_in_addr_t (remote_end, 0, &gc), tun_mtu, ifconfig_remote_netmask ); @@ -1274,7 +1277,7 @@ do_ifconfig (struct tuntap *tt, r.flags = RT_DEFINED; r.network = tt->local & tt->remote_netmask; r.netmask = tt->remote_netmask; - r.gateway = tt->local; + r.gateway = remote_end; add_route (&r, tt, 0, NULL, es); } -- 2.9.2 ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
