Repair topology subnet on FreeBSD 11

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 <[email protected]...>

---
 src/openvpn/tun.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

src/openvpn/tun.c +7 -4

index af685de..a6d38d5 100644
@@ -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
 			  );

Thanks for testing & review :-)

Patch has been applied to the master and release/2.3 branch.

commit a433b3813d8c38b491d2baa7b433973f2d6cd7c6 (master) commit 446ef5bda4cdc75d4cb955e274846faff0181fd3 (release/2.3)

Author: Gert Doering
Date:   Tue Nov 8 13:45:06 2016 +0100

     Repair topology subnet on FreeBSD 11

     URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207831
     Signed-off-by: Gert Doering <[email protected]...>
     Acked-by: Steffan Karger <[email protected]...>
     Message-Id: <[email protected]...>
     URL: https://www.mail-archive.com/[email protected]/msg12950.html
     Signed-off-by: Gert Doering <[email protected]...>

Quoted 1 line

Repair topology subnet on FreeBSD 11

This is now part of FreeBSD's openvpn 2.3.13_1 (on the port's head) and masked by an option that I enable by default and that I've dubbed FIXSUBNET. <https://svnweb.freebsd.org/ports?view=revision&revision=425811>.

If nothing new crops up, I can request to merge this back to the quarterly (stable) branch and drop the option if someone deems this urgent, else it will propagate to stable ports in early January 2017. I should probably kick the option before then and make this patch regular (unless 2.3.14 is out sooner, but I understand if people want to focus on getting 2.4.0 into Debian).

I might be tempted to do a quick 2.3.14 release in between - there's two important platform fixes in that branch now (FreeBSD and OpenBSD topology subnet :-) ) and Lev's recursive routing patch. Add to that the windows block-outside-dns patch that I hope to be testing this weekend, and it's worth a minor bugfix release... at least "before January".

Am 11.11.2016 um 23:10 schrieb Gert Doering:

Quoted 5 lines

I might be tempted to do a quick 2.3.14 release in between - there's two important platform fixes in that branch now (FreeBSD and OpenBSD topology subnet :-) ) and Lev's recursive routing patch. Add to that the windows block-outside-dns patch that I hope to be testing this weekend, and it's worth a minor bugfix release... at least "before January".

Well, for me to update the FreeBSD port, mid December 2016 would be cool for anything (2.3.14, or 2.4.0, or both) due to the before-xmas-madness and to have like two weeks for smoke testing.

Bottom line, give Debian the priority, and while it would be nice to have for FreeBSD, no need to rush.

Hi,

Quoted 9 lines · Matthias Andree

Am 11.11.2016 um 23:10 schrieb Gert Doering:

Quoted 5 lines

I might be tempted to do a quick 2.3.14 release in between - there's two important platform fixes in that branch now (FreeBSD and OpenBSD topology subnet :-) ) and Lev's recursive routing patch. Add to that the windows block-outside-dns patch that I hope to be testing this weekend, and it's worth a minor bugfix release... at least "before January".

Well, for me to update the FreeBSD port, mid December 2016 would be cool for anything (2.3.14, or 2.4.0, or both) due to the before-xmas-madness and to have like two weeks for smoke testing.

Here we go :-) - Nikolaus present, 2.3.14.

2.4_beta2 is waiting for someone to bump the openvpn-devel port, but everyone is busy, it seems (PR#214930).

I wonder what the best approach towards 2.4 in ports would be, though - introduce an openvpn23 port, and bump "openvpn" to 2.4.0 when that happens? Or introduce it as "openvpn24"?

"operating system wise", 2.4.0 should be as good on FreeBSD as 2.3.14 (because all the platform fixes went into both branches), but there might be hidden bugs lurking in the "non-client, non-platform" bits that are new in 2.4