[WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[Jason A. Donenfeld]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new experimental snapshot, `experimental-0.0.20160708.1`, has been tagged in
the git repository.

Please note that this snapshot is, like the rest of the project at this point
in time, experimental, and does not consitute a real release that would be
considered secure and bug-free. However, if you'd like to test this snapshot
out, there are a few relevent changes.

== Changes ==

  * persistent keepalive: start sending immediately -- the previously released
    feature was not useful without this extra commit. So, getting this in here
    now so that people can actually test this out. Sorry for the churn. Don't
    bother packaging the previous snapshot.

As always, the source is available at https://git.zx2c4.com/WireGuard/ and
information about the project is available at https://www.wireguard.io/ .

This snapshot is available in tarball form here:
  https://git.zx2c4.com/WireGuard/snapshot/WireGuard-experimental-0.0.20160708.1.tar.xz
  SHA256: 11faf795dd45ff0d13cdd204775b07e01fda596b4a9c2a1b326614c226e9725d

If you're a snapshot package maintainer, please bump your package version. If
you're a user, the WireGuard team welcomes any and all feedback on this latest
snapshot.

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQItBAEBCAAXBQJXf7p+EBxqYXNvbkB6eDJjNC5jb20ACgkQSfxwEqXeA66C1BAA
r3VYAPR7CNx5j93fK+tTdbotRT/OwVMntgI6Rwy/JgDX6lyGofcwZsGPv8EsKH2j
FSozoC4eCabG1Oq+Rjvh9Hpr+H50tJMruiICodRgKLVQkpQNPzl3XDI1u0nZRxkh
H8N7i9/PWIyCGbQXlSQJjWaYu8/n+qE7rfTDnCfedi2vPyKXR9STKEO14It9brM6
FK/5s9+LQH7wWVSawTPQJIo8G7lZUxJHYMe6Ipb26tXFvyup+D7vvlzVaP0Nfb7x
R67Fly9iBTPjS0eqUaZes+JHZUMQ/T7St5HZ4Xg+diDmjDzuhlHG1i5YyY94NEfA
/D/3MyTMaO6j3kGSIQmKM7kiI2+ngkOaj5tKSqNua+USpiL8v4461m5Jti1psNwA
mm/Qw+MROUz4zkXsMHtN97DSCK+66MVRFB023FI8Ol0Wwitp9RAm57jQWRu+Meij
Vor57Q5SD+299xb0CciNjh1neBlRirkA6fG3RZM4WyUnD7qoR8o3c+ezXslj6qur
giXMZTTb2+BdCgV+w0Z7blHFKqR0PvW8ehJoFPsU5GSAcZ20ucGmZ33Z/gFE5WLQ
QPO4Rzj6Nq4SxWDHwBuo0UaRr28i0tGM7nUJaSjalB7NZ9ZcAf/jMLwkGpJTeCzn
zirmZfYGs2+EviiOE4jX+2cp/AXn5x5xg5EGymxCOD0=
=zcDL
-----END PGP SIGNATURE-----

Re: [WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[Bruno Wolff III]

On Fri, Jul 08, 2016 at 16:37:23 +0200,
  "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>
>== Changes ==
>
>  * persistent keepalive: start sending immediately -- the previously released
>    feature was not useful without this extra commit. So, getting this in here
>    now so that people can actually test this out. Sorry for the churn. Don't
>    bother packaging the previous snapshot.

I tried this an noticed a problem. The keep alive packets don't set the 
reply IP address and port for the endpoint. (Which makes sense since they 
aren't authenticated.) So in the case of nat, where you won't know what 
the port is (and in some cases the IP address as well) you still can't 
connect to the end point behind the nat until there is some authenticated 
data sent from the end point.

So if nat changes the port at some point, in order to reestablish a path, 
you need to send authenticated data. I am not thinking of an obvious way 
to tell when you just need to hold the port mapping via nat open versus 
when you need to send authenticated data to rebuild a connection after 
a port or IP address change from nat.

Re: [WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[Jason A. Donenfeld]

Hi Bruno,

On Fri, Jul 8, 2016 at 6:23 PM, Bruno Wolff III <bruno@wolff.to> wrote:
>
> I tried this an noticed a problem. The keep alive packets don't set the
> reply IP address and port for the endpoint. (Which makes sense since they
> aren't authenticated.) So in the case of nat, where you won't know what the
> port is (and in some cases the IP address as well) you still can't connect
> to the end point behind the nat until there is some authenticated data sent
> from the end point.

UGH! You're right. Thanks for thinking about this properly, and good
observation.

>
> So if nat changes the port at some point, in order to reestablish a path,
> you need to send authenticated data. I am not thinking of an obvious way to
> tell when you just need to hold the port mapping via nat open versus when
> you need to send authenticated data to rebuild a connection after a port or
> IP address change from nat.

Well, after the initial authenticated data has been sent (say, at `ip
link set up` time), the persistent keepalives should keep the link
open, which would prevent NAT from changing the port. This _should_
work.

But is it too fragile? Maybe we should scrap all of this and make
persistent keepalives authenticated. I'm not too thrilled about that
though...

Re: [WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[Jason A. Donenfeld]

On Fri, Jul 8, 2016 at 7:55 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> But is it too fragile? Maybe we should scrap all of this and make
> persistent keepalives authenticated. I'm not too thrilled about that
> though...

I'm experimenting with this in the authenticated-persistent-keepalive
branch, if you'd like to try it out and report back on how it goes...

Re: [WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[Bruno Wolff III]

On Fri, Jul 08, 2016 at 20:49:07 +0200,
  "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>On Fri, Jul 8, 2016 at 7:55 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>> But is it too fragile? Maybe we should scrap all of this and make
>> persistent keepalives authenticated. I'm not too thrilled about that
>> though...
>
>I'm experimenting with this in the authenticated-persistent-keepalive
>branch, if you'd like to try it out and report back on how it goes...

It looks like initially it does 0 length udp packets for keep alive and the 
authenticated keep alives don't seem to happen until after some data is sent.

Re: [WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[Jason A. Donenfeld]

On Fri, Jul 8, 2016 at 9:55 PM, Bruno Wolff III <bruno@wolff.to> wrote:
> It looks like initially it does 0 length udp packets for keep alive and the
> authenticated keep alives don't seem to happen until after some data is
> sent.

I suspect you forgot to rmmod the previous module before trying this
branch. There are no 0 length udp packets sent anywhere in this
branch's code paths.

Re: [WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[Bruno Wolff III]

On Fri, Jul 08, 2016 at 22:21:09 +0200,
  "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>On Fri, Jul 8, 2016 at 9:55 PM, Bruno Wolff III <bruno@wolff.to> wrote:
>> It looks like initially it does 0 length udp packets for keep alive and the
>> authenticated keep alives don't seem to happen until after some data is
>> sent.
>
>I suspect you forgot to rmmod the previous module before trying this
>branch. There are no 0 length udp packets sent anywhere in this
>branch's code paths.

Thanks. I'll retest.

Re: [WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[Bruno Wolff III]

On Fri, Jul 08, 2016 at 22:21:09 +0200,
  "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>On Fri, Jul 8, 2016 at 9:55 PM, Bruno Wolff III <bruno@wolff.to> wrote:
>> It looks like initially it does 0 length udp packets for keep alive and the
>> authenticated keep alives don't seem to happen until after some data is
>> sent.
>
>I suspect you forgot to rmmod the previous module before trying this
>branch. There are no 0 length udp packets sent anywhere in this
>branch's code paths.

Yep, that was it. It allowed a remote connection at start up without 
having to manually send traffic out locally first. So it looks like 
it is working as expected.

Right now I am testing through a stateful firewall that blocks the 
inbound connection unless it is related to an already established 
connection. That isn't exactly the same as nat, but should work similarly 
for testing purposes.

Re: [WireGuard] [ANNOUNCE] Snapshot `experimental-0.0.20160708.1` Available

[Jason A. Donenfeld]

Hey Bruno,

On Fri, Jul 8, 2016 at 10:54 PM, Bruno Wolff III <bruno@wolff.to> wrote:
> Yep, that was it. It allowed a remote connection at start up without having
> to manually send traffic out locally first. So it looks like it is working
> as expected.
>
> Right now I am testing through a stateful firewall that blocks the inbound
> connection unless it is related to an already established connection. That
> isn't exactly the same as nat, but should work similarly for testing
> purposes.

Excellent to hear! Hopefully it continues to work well. If so, I'll
merge next week and roll a new snapshot.

Regards,
Jason