I can confirm that this fixes OpenVPN in my use-case at least. Thank you for the patch!
-- Bryan On 2016-09-14 08:16:18, Brent Cook <bust...@gmail.com> wrote: > phessler and I looked at this last week, and if I understand correctly, > the indirect gateway address was the main problem here. We manually > added a route via the tunnel address instead, and things seemed to work > as expected. > > So, would a patch like this make more sense? > > Wed Sep 14 08:08:28 2016 ROUTE_GATEWAY 192.168.22.1 > Wed Sep 14 08:08:28 2016 TUN/TAP device /dev/tun0 opened > Wed Sep 14 08:08:28 2016 do_ifconfig, tt->ipv6=0, > tt->did_ifconfig_ipv6_setup=0 > Wed Sep 14 08:08:28 2016 /sbin/ifconfig tun0 10.8.0.4 10.8.0.4 mtu 1500 > netmask 255.255.255.0 up > Wed Sep 14 08:08:28 2016 /sbin/route add -net 10.8.0.0 10.8.0.4 -netmask > 255.255.255.0 > add net 10.8.0.0: gateway 10.8.0.4 > Wed Sep 14 08:08:28 2016 /sbin/route add -net 104.238.145.134 10.8.0.4 > -netmask 255.255.255.255 > add net 104.238.145.134: gateway 10.8.0.4 > Wed Sep 14 08:08:28 2016 /sbin/route add -net 0.0.0.0 10.8.0.4 -netmask > 128.0.0.0 > add net 0.0.0.0: gateway 10.8.0.4 > Wed Sep 14 08:08:28 2016 /sbin/route add -net 128.0.0.0 10.8.0.4 > -netmask 128.0.0.0 > add net 128.0.0.0: gateway 10.8.0.4 > Wed Sep 14 08:08:28 2016 Initialization Sequence Completed > ^CWed Sep 14 08:08:32 2016 event_wait : Interrupted system call (code=4) > Wed Sep 14 08:08:32 2016 SIGTERM received, sending exit notification to > peer > Wed Sep 14 08:08:37 2016 /sbin/route delete -net 104.238.145.134 > 10.8.0.4 -netmask 255.255.255.255 > delete net 104.238.145.134: gateway 10.8.0.4 > Wed Sep 14 08:08:37 2016 /sbin/route delete -net 0.0.0.0 10.8.0.4 > -netmask 128.0.0.0 > delete net 0.0.0.0: gateway 10.8.0.4 > Wed Sep 14 08:08:37 2016 /sbin/route delete -net 128.0.0.0 10.8.0.4 > -netmask 128.0.0.0 > delete net 128.0.0.0: gateway 10.8.0.4 > Wed Sep 14 08:08:37 2016 Closing TUN/TAP interface > Wed Sep 14 08:08:37 2016 SIGTERM[soft,exit-with-notification] received, > process exiting > > --- route.c.orig Wed Sep 14 07:55:13 2016 > +++ route.c Wed Sep 14 08:07:45 2016 > @@ -1301,6 +1301,7 @@ > const char *network; > const char *netmask; > const char *gateway; > + const char *local; > bool status = false; > int is_local_route; > > @@ -1313,6 +1314,7 @@ > network = print_in_addr_t (r->network, 0, &gc); > netmask = print_in_addr_t (r->netmask, 0, &gc); > gateway = print_in_addr_t (r->gateway, 0, &gc); > + local = print_in_addr_t (tt->local, 0, &gc); > > is_local_route = local_route(r->network, r->netmask, r->gateway, rgi); > if (is_local_route == LR_ERROR) > @@ -1503,7 +1505,7 @@ > > argv_printf_cat (&argv, "-net %s %s -netmask %s", > network, > - gateway, > + local, > netmask); > > /* FIXME -- add on-link support for OpenBSD/NetBSD */ > @@ -1751,6 +1753,7 @@ > const char *network; > const char *netmask; > const char *gateway; > + const char *local; > int is_local_route; > > if ((r->flags & (RT_DEFINED|RT_ADDED)) != (RT_DEFINED|RT_ADDED)) > @@ -1762,6 +1765,7 @@ > network = print_in_addr_t (r->network, 0, &gc); > netmask = print_in_addr_t (r->netmask, 0, &gc); > gateway = print_in_addr_t (r->gateway, 0, &gc); > + local = print_in_addr_t (tt->local, 0, &gc); > > is_local_route = local_route(r->network, r->netmask, r->gateway, rgi); > if (is_local_route == LR_ERROR) > @@ -1883,7 +1887,7 @@ > argv_printf (&argv, "%s delete -net %s %s -netmask %s", > ROUTE_PATH, > network, > - gateway, > + local, > netmask); > > argv_msg (D_ROUTE, &argv); > > On Tue, Sep 13, 2016 at 11:45:22PM +0100, Stuart Henderson wrote: > > There's clearly some problem, others have seen breakage too, but I don't see > > why replacing -netmask to /prefix would change anything.. > > > > > > On 13 September 2016 22:35:54 Sander van Kranenburg <san...@vkranenburg.nl> > > wrote: > > > > > Hi, > > > > > > GMBL so it's probably my vpn provider that doesn't work with 6.0. > > > Thx for your time and the great support. > > > > > > Best regards, > > > > > > Sander van Kranenburg > > > > > > -----Oorspronkelijk bericht----- > > > Van: Stuart Henderson [mailto:s...@spacehopper.org] > > > Verzonden: dinsdag 13 september 2016 23:26 > > > Aan: Sander van Kranenburg <san...@vkranenburg.nl> > > > CC: ports@openbsd.org > > > Onderwerp: Re: openvpn broken caused by a change in route add and delete > > > > > > On 2016/09/13 21:20, Sander van Kranenburg wrote: > > > > Hi, > > > > > > > > Are you at openbsd 6.0 at the moment? > > > > This is my uname -a OpenBSD openbsd.HOME.local 6.0 GENERIC#0 i386. > > > > -netmask doesn't work at all for me since i updated tot 6.0 > > > > > > -current from a few days ago, but I just also tested it on 6.0 release. > > > > > > > > > > Van: Stuart Henderson [mailto:s...@spacehopper.org] > > > > Verzonden: dinsdag 13 september 2016 23:07 > > > > Aan: Sander van Kranenburg <san...@vkranenburg.nl> > > > > CC: ports@openbsd.org > > > > Onderwerp: Re: openvpn broken caused by a change in route add and > > > > delete > > > > > > > > On 2016/09/13 19:29, Sander van Kranenburg wrote: > > > > > Hi, > > > > > > > > > > As far as i know -netmask doesn't work anymore. > > > > > We need to add the netbits tot the network adres like openvpn is > > > > doing with ipv6. > > > > > > > > -netmask is expected to work exactly the same as specifying > > > > ip/prefix, and it does work fine here: > > > > > > > > # route add -net 192.0.2.0 82.68.199.133 -netmask 255.255.255.0 add > > > > net 192.0.2.0: gateway 82.68.199.133 # netstat -rnfinet | grep ^192 > > > > 192.0.2/24 82.68.199.133 UGS 0 0 - 8 > > > > vlan2 > > > > # route delete -net 192.0.2.0 -netmask 255.255.255.0 delete net > > > > 192.0.2.0 # netstat -rnfinet | grep ^192 # > > > > > > > > Exactly the same behaviour as the prefix: > > > > > > > > # route add 192.0.2.0/24 82.68.199.133 add net 192.0.2.0/24: gateway > > > > 82.68.199.133 # netstat -rnfinet | grep ^192 > > > > 192.0.2/24 82.68.199.133 UGS 0 0 - 8 > > > > vlan2 > > > > # route delete 192.0.2.0/24 > > > > delete net 192.0.2.0/24 > > > > # netstat -rnfinet | grep ^192 > > > > # > > > > > > > > I think the problem you ran into was something to do with the > > > > gateway address, handling of this *was* changed relatively recently, > > > > and not the syntax of address format to route(8). > > > > > > > > >
