From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Peter Dolding <oiaohm@gmail.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Built-in Roaming is limited due to a design fault adding STUN and TURN support would be good and make wire-guard connections more durable.
Date: Thu, 5 Jan 2017 21:33:03 +0100 [thread overview]
Message-ID: <CAHmME9qG4KnuFOCVi6w8fUJ9DVDL9_XjZnWxWPQGQaaPz6UTQw@mail.gmail.com> (raw)
In-Reply-To: <CANA3KFWZP9XmCyWNnb19ywGRa8q57OUNt=42G1yjqkvLYc1kPw@mail.gmail.com>
Hi Peter,
On Thu, Jan 5, 2017 at 12:08 PM, Peter Dolding <oiaohm@gmail.com> wrote:
>> 1. Dynamic IPs.
>> 2. Both peers behind NAT.
> That misses one completely
> 3. Server and Peers both behind NAT. Yes there is a usage case for this one.
WireGuard has no concept of client/server. There are only peers. So,
when I wrote "both peers behind NAT", I most certainly had in mind
what you refer to as "server and peer". Please reread my answer in
light of this new understanding.
> Dynamic DNS has it weaknesses. Transparent DNS caching and DNS
> access restrictions in some networks mess with the solution you
> describe.
>
> https://tools.ietf.org/html/rfc3489
>
> For Voip STUN was developed for many reasons three key reasons.
> 1. you can username and password protect a STUN server so restricting
> the users who can find out about the service.
> 2 . It does support TLS so encrypted.
> 3. Information on a STUN server is not replaced to other servers like
> lots of dynamic DNS are so in case of attack there are limited sources
> of information.
>
> Dynamic DNS option really using a hack that was not suitable for voip
> yet for some reason people think it suitable to use for VPN. Dynamic
> DNS is not designed for punching though NAT solutions for the server
> address like STUN is or designed to limit access to the address
> information like STUN is.
So, as I already wrote in my previous email, implement a STUN tool for
setting up initial WireGuard communications. The example code I linked
to already provides a framework on how this might be done. Just
replace my homebaked hooks with whatever STUN library tickles your
fancy.
> This example the WireGuard server has a public IP address. The case
> I am mentioning Wireguard server may not have a public IP address.
Um, no. Did you even read the example? Both WireGuard peers have
private IP addresses. Only the NAT-helper server has a public IP
address. This is the same model as STUN. Spend some time actually
reading and studying the work already done on this before wasting more
time with long emails.
> Now STUN will attempt hole punching in the case you don't have a
> public IP address for the WireGuard server if the NAT in use are
> cooperative. Of course if you read STUN rfc they state the case
> where STUN cannot be used to create a link between server and client
> both behind NATs as long as the STUN server is in the open.
The example code I linked to presents the same model.
> Jason the issue here to be able to use STUN/TURN combination in all
> cases I need Wireguard to be able to be directed to use TURN.
Great. I already outlined how this could be done, and I provided
example code. Plug your STUN or TURN library into that, and you'll be
all set.
No, I'm not going to write it for you. You got a NAT-punching example
from me. You can get a STUN/TURN library from somebody else. All
that's left for you is putting them together.
> Current model is
> [Client]-[Server]
> What is needed is
> [Client]-[Relay]-[Server] with [Client]-[Server] to cover all usage
> cases. Of course the relay being something standard and common
> reduces the number of servers that have to be publicly deployed and
> maintained.
Yes, I'm aware. And this is exactly what the example code demonstrates
is possible.
> This is a fault in a lot of VPN designs no relay option because is
> always presumed that you can get a public IP the clients can access
> for the server and the location where you can get the public IP
> address is suitable to house the encryption keys that is not always
> the case. With a TURN server relay option packets passing though the
> TURN relay server will remain encoded at the relay server this does
> solve the issue where the encryption keys due to privacy acts have to
> remain inside a particular country or department. The only part
> that requires a public address when using a TURN is the TURN relay
> server. This is just not reinventing the wheel protocol that is
> fairly widely deployed being TURN can provide Relay option. A VPN
> that can run with TURN relays means servers and peers containing
> encryption keys don't have to be on the internet exposed IP addresses.
Great, so plug your TURN library into some resembling the example I
wrote, and you'll be all set.
> Jason I don't code that much I work on deployments. I have run into
> issues where I don't have a public IP address to use. I have used
> solutions containing libnice to get me around problems. Libnice is
> not my project.
Then integrate libnice into my example code, and you'll have what you want.
> Please do note needing TURN/Relay comes important even when attempt to
> link up clients by IRC, Xmmp or other resolve methods where it may
> turn out that both ends are sitting behind NAT where direct
> connectivity is impossible.
Yes, I'm aware. Again, see example code. Replace the homebrewed
structures with a STUN/TURN library.
Please do not write again until you've read the example code and taken
the time to understand what it does.
Regards,
Jason
next prev parent reply other threads:[~2017-01-05 20:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-02 6:10 Peter Dolding
2017-01-02 14:18 ` Jason A. Donenfeld
2017-01-05 11:08 ` Peter Dolding
2017-01-05 20:33 ` Jason A. Donenfeld [this message]
2017-01-09 13:43 ` Peter Dolding
2017-01-15 8:39 ` Dan Lüdtke
2017-01-15 10:55 ` Jason A. Donenfeld
2017-01-18 5:55 ` Peter Dolding
2017-01-18 6:11 ` Dan Lüdtke
2017-01-18 11:21 ` Peter Dolding
2017-01-18 12:07 ` Dan Lüdtke
2017-01-21 21:51 ` Peter Dolding
2017-01-22 23:29 ` Jason A. Donenfeld
2017-01-15 10:40 ` Jason A. Donenfeld
2017-01-18 7:38 ` Peter Dolding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHmME9qG4KnuFOCVi6w8fUJ9DVDL9_XjZnWxWPQGQaaPz6UTQw@mail.gmail.com \
--to=jason@zx2c4.com \
--cc=oiaohm@gmail.com \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).