WireGuard for FreeBSD

Fri May 25 14:08:09 UTC 2018

On 25.05.18 15:11, Bernhard Fröhlich wrote:
> On Fri, May 25, 2018 at 12:05 PM, Jan Bramkamp <crest at rlwinm.de> wrote:
>>
>>
>> On 25.05.18 09:29, Bernhard Fröhlich wrote:
>>>
>>> On Fri, May 25, 2018 at 12:24 AM, Chris H <portmaster at bsdforge.com> wrote:
>>>>
>>>> On Thu, 24 May 2018 22:16:42 +0200 "Bernhard Froehlich"
>>>> <decke at bluelife.at>
>>>> said
>>>>
>>>>> Am 24.05.2018 21:06 schrieb Chris H <portmaster at BSDforge.com>:
>>>>>>
>>>>>>
>>>>>> On Thu, 24 May 2018 19:39:22 +0200 "Jason A. Donenfeld"
>>>>>> <Jason at zx2c4.com>
>>>>>> said >
>>>>>>>
>>>>>>> Hi Chris, > > > > On Thu, May 24, 2018 at 3:38 PM, Chris H
>>>>>>> <portmaster at bsdforge.com> wrote: > > > I should have no trouble
>>>>>>> introducing
>>>>>>> Wireguard to the ports system today.
>>>>>>>>>>
>>>>>>>>>> I'm not a native fluent speaker of FreeBSDese, but my
>>>>>>>>>> understanding is: > > a) Bernhard committed the two new packages to
>>>>>>>>>> ports
>>>>>>>>>> today. > > b) If you update ports with portsnap, you can build them
>>>>>>>>>> locally.
>>>>>>>>>>>>
>>>>>>>>>>>> c) If you run `pkg install wireguard`, it fails because the build
>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> servers haven't gotten to them and won't for several days. > > > >
>>>>>>>>>> Does your
>>>>>>>>>> statement about "introducing WireGuard to the ports system" > >
>>>>>>>>>> mean that
>>>>>>>>>> you intend to rectify (c) immediately, so we don't have to > > wait
>>>>>>>>>> several
>>>>>>>>>> days for the build snapshot scripts to tick in cron? Or > > is it
>>>>>>>>>> mostly
>>>>>>>>>> just related to not realizing (a)? > Sigh... > It was my
>>>>>>>>>> understanding that
>>>>>>>>>> when I stepped up to adopt WireGuard, > and your ack to that. That
>>>>>>>>>> *I* would
>>>>>>>>>> be adding the port. I wasn't able > to produce the port that same,
>>>>>>>>>> or next
>>>>>>>>>> day, as I am already Maintainer > for nearly 150 ports. I have no
>>>>>>>>>> trouble
>>>>>>>>>> with that list, except that > clang/llvm v5, and shortly after v6
>>>>>>>>>> became the
>>>>>>>>>> default versions in $BASE. > Which introduced a few pr(1)'s I
>>>>>>>>>> needed to deal
>>>>>>>>>> with. > Now all the time I have spent researching, and staging to
>>>>>>>>>> build the
>>>>>>>>>> port > have been laid to waste. Apparently you rescinded, and gave
>>>>>>>>>> it to
>>>>>>>>>> Bernhard. > This project doesn't feel like a good match to me. > No
>>>>>>>>>> hard
>>>>>>>>>> feelings, Bernhard. Have fun with the port.
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> I'm sorry that I was confusing people which was really not my intention.
>>>>> I
>>>>> have also seen your ACK to create the ports and replied to you in
>>>>> private
>>>>> to
>>>>> offer my help. Then I joined in IRC and just wanted to get an idea how
>>>>> far
>>>>> the FreeBSD support was. I ended up creating two very rough ports which
>>>>> did
>>>>> build but not pass poudriere and called it a day. I also did send you
>>>>> and
>>>>> the
>>>>> list a mail to avoid duplicate work - and hoped you take it as a base.
>>>>>
>>>>> But I did not get any reply on the next day so I kept going and finished
>>>>> the
>>>>> ports yesterday with some good help from upstream.
>>>>>
>>>>> Sorry for how that developed but I hoped you get in contact with either
>>>>> me
>>>>> or
>>>>> upstream which neither happened. We usually do not have the problem that
>>>>> too
>>>>> many people want to help out so I did not expect that this will be a
>>>>> problem
>>>>> for anyone.
>>>>
>>>>
>>>> Ahem. OK thank you for the kind words, and intentions, Bernhard. Like I
>>>> said;
>>>> no hard feelings. If you've already gotten that far. You might as well
>>>> finish.
>>>> FWIW while you *did* indeed shoot me, and the list a couple of notes. I
>>>> was
>>>> never under the impression you were going to take it so far. Which
>>>> *ultimately*
>>>> left everyone concerned believing *you* were going to maintain it.
>>>> I only mention it, in hopes all of us might use the --verbose switch in
>>>> the
>>>> future, in hopes of avoiding this sort of nonsense. :-) :-)
>>>>
>>>> Thanks again, Bernhard!
>>>>
>>>> --Chris
>>>>
>>>> P.S. just in case it wasn't clear; feel free to finish, and submit your
>>>> work.
>>>> P.P.S. Just so you (and everyone else) knows; I'm already working on the
>>>> kernel module. Please keep in touch, should you also be interested, and
>>>> have
>>>> any work of your own.
>>>
>>>
>>> Hi chris,
>>>
>>> to be crystal clear about that. My motivation is not to be maintainer
>>> of any specific
>>> port or anything like that but only to have technology available on
>>> FreeBSD that I
>>> personally need and/or want.
>>>
>>> Usually for more complex ports this did lead to team efforts on our
>>> porting work
>>> which was also what I did expect to happen for wireguard. Well it
>>> turned out to be
>>> easier than thought and upstream was also very helpful so in the end
>>> that was more
>>> like a one day of work effort to get the basic ports.
>>>
>>> Nevertheless I would still be very happy to increase the bus factor
>>> and team up with
>>> multiple people to maintain wireguard. I think there will be more work
>>> to be done in the
>>> near future for wireguard on FreeBSD where a team effort would speed
>>> up things for
>>> sure:
>>>
>>> - we need to support FreeNAS and pfsense to get it into their package
>>> systems
>>> - documentation is still needed because it differs a bit from upstream
>>> documentation (Handbook page?)
>>> - wireguard kernel module (can that work already be seen somewhere?
>>> upstream will be interested for sure)
>>> - rc script(s)
>>> - the regular maintenance for the port
>>
>>
>> The wireguard userspace tooling isn't that simple to use reliably. You have
>> to spawn the wireguard-go process before the config can be loaded and it can
>> die in the meantime and to you want to terminate it and destroy the tun
>> interface if the config contains errors. Doing this without ugly hacks isn't
>> possible given the interfaces offered by wireguard-go. It would be really
>> nice to be able to terminate wireguard-go over the unix domain socket
>> instead of a pkill.
> 
> I found it quite okay on FreeBSD that way:
> 
> - create keys with "wg" like in the quickstart
> - create the config file /usr/local/etc/wg0.conf and fill appropriate
> (see manpages
> of wg and wg-quick)
> - start: wg-quick up wg0
> - stop: wg-quick down wg0
> 
> Though I think the OpenBSD support is still very very rough (3 days old).

The problem isn't that these tools don't work in the common case. The 
problem is that their implementation is inherently racy. Here is what 
has to happen to bring up a tunnel:

* wireguard-go tun0
* wg setconf tun0 /etc/wg/tun0.conf
* service netif start tun0 (or sh /etc/netstart tun0 on OpenBSD)

The problem is that both of these configuration steps (wg setconf and 
the rc scripts) can fail and wireguard-go can die any time. I care about 
these corner cases because I plan to run wireguard-go under process 
supervision (runit, s6) on FreeBSD and OpenBSD. To get the most out of 
process supervision everything has start correctly or fail hard with 
sane timeouts. If the ./run script spawns a subshell before exec()ing 
into wireguard-go and the wireguard-go process dies it can't just save 
the pid with PID="$$" and kill it if the config fails to apply. In that 
case the PID could've been reused.