Skip to contentSkip to conversation

Repair topology subnet on OpenBSD

PATCH In review Gert Doering 2 participants 2 messages Nov 9, 2016 – Nov 11, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Repair topology subnet on OpenBSD

Turns out that "topology subnet" never worked totally right on OpenBSD - the "netmask" parameter to ifconfig is ignored, and one needs to add a subnet route (and this issue is hidden if an encompassing route is pushed, like, by using --redirect-gateway).

While add it, apply the hack used for FreeBSD where "an arbitrary address from the subnet" is used to set the "remote" end of the tunnel, and point the route to that - so if OpenBSD decides to change their kernel routing structure the same way, our code still works (copying from commit 433b3813d8c38b4, trac #425 and commit 60fd44e501f2002, trac #481).

Tested on OpenBSD 6.0 and 4.9

Trac #710

---
 src/openvpn/tun.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)
src/openvpn/tun.c +19 -2
index a6d38d5..a312d91 100644
@@ -711,7 +711,8 @@ void delete_route_connected_v6_net(struct tuntap * tt,
 }
 #endif
 
-#if defined(TARGET_FREEBSD)||defined(TARGET_DRAGONFLY)
+#if defined(TARGET_FREEBSD)||defined(TARGET_DRAGONFLY)||\
+    defined(TARGET_OPENBSD)
 /* we can't use true subnet mode on tun on all platforms, as that
  * conflicts with IPv6 (wants to use ND then, which we don't do),
  * but the OSes want "a remote address that is different from ours"
@@ -1032,6 +1033,8 @@ do_ifconfig (struct tuntap *tt,
 
 #elif defined(TARGET_OPENBSD)
 
+      in_addr_t remote_end;		/* for "virtual" subnet topology */
+
       /*
        * On OpenBSD, tun interfaces are persistent if created with
        * "ifconfig tunX create", and auto-destroyed if created by
@@ -1051,12 +1054,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 -link0",
 			  IFCONFIG_PATH,
 			  actual,
 			  ifconfig_local,
-			  ifconfig_local,
+			  print_in_addr_t (remote_end, 0, &gc),
 			  tun_mtu,
 			  ifconfig_remote_netmask
 			  );
@@ -1073,6 +1077,19 @@ do_ifconfig (struct tuntap *tt,
 			  );
       argv_msg (M_INFO, &argv);
       openvpn_execve_check (&argv, es, S_FATAL, "OpenBSD ifconfig failed");
+
+      /* Add a network route for the local tun interface */
+      if (!tun && tt->topology == TOP_SUBNET)
+        {
+          struct route_ipv4 r;
+          CLEAR (r);
+          r.flags = RT_DEFINED;
+          r.network = tt->local & tt->remote_netmask;
+          r.netmask = tt->remote_netmask;
+          r.gateway = remote_end;
+          add_route (&r, tt, 0, NULL, es);
+        }
+
       if ( do_ipv6 )
 	{
 	  argv_printf (&argv,
Signature · 1 line
2.9.0
#1 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ACK.

Checked these changes against the FreeBSD 11 fixes. The changes puts the OpenBSD section well aligned with FreeBSD in do_ifconfig(), and it all makes sense from a code-review perspective.

When also knowing the FreeBSD fix have been tested and verified successful by externals, I do not see any reasons this should be any worse for OpenBSD. I do not have an OpenBSD box to run tests on, so I place confidence in the testing Gert have done (which usually very well executed).

Your patch has been applied to the following branches

commit 7f444dee52321c0f0294e99695150a7f69522715 (master) commit ceac73b04fe9b70ed798afc07ddb9737c97b7a5d (release/2.3)

Author: Gert Doering
Date:   Wed Nov 9 21:19:32 2016 +0100
     Repair topology subnet on OpenBSD

     Trac: #710
     Signed-off-by: Gert Doering <[email protected]...>
     Acked-by: David Sommerseth <[email protected]...>
     Message-Id: <[email protected]...>
     URL: https://www.mail-archive.com/[email protected]/msg12983.html
     Signed-off-by: David Sommerseth <[email protected]...>

- --
kind regards,

David Sommerseth

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYJa6TAAoJEIbPlEyWcf3ypU4P/0jRDeEnPBBPdCucYreiYdX2 aXGfDsz+bzX3Gmp5rD00MZjETLJKl3E6ZPnFN8D0nUeE2p9L/cyPK+eESZ+gE41c oelConatOMAKALZYzBgjoP8zQGvlurDZg7BycXNy6vfJ2G2gWJLkyq6piCcOnif6 wFo7FxicrceHB0emLM8lEQdTdTc1grRpSB8BQSYEZvY4SwzmooD6RLnwrBiiBs2K j/ccEANehxDFZ7cPACmRF+gXr7TXoFbAzxiep/jFIAXo7caHgD3JbdAzdRxgOLeO cc8c7NjgtKN5wgBbB6Cgr/jSJwBqweBE0MDS0cRRMPARSpOqlRx2OhZtcmFsv7hE K9/esBtpW0JsNo8QKAuPAbfU2TJPjyk9x0u6bNqHlqQtcXbRz91fqa+DgEHeCCoo BRIgNW3+OUdfte9NgvsTetaK7LViio44M3PFEmwYBtBz/6oazYO0lpDKJRyineNP +lACVieA2YgXKoghsRNRcWJxd2jqyZUTdQvrh86euaGz38RupDPqpFDf5W0fR2as BT3F4Q2T+0WLT4fK1ZZZAK0dD+IHcQwmUanWOFMVStl3Z4vuZc7kUiANU2/m1Ria qgnxzP8LG7m52ebtsTd1OzE7HEAejpp3CXEN0dlddLbfVJbyYsdK2pW9vogdSIpZ xawe0ScDiu0hSBintf6I
=gnP6
-----END PGP SIGNATURE-----