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.

[Peter Dolding]

On Tue, Jan 3, 2017 at 12:18 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Hi Peter,
>
> That's a pretty bombastic and rambling way to put a simple point. I
> believe you're conflating two different things. Let's break it down:
>
> 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.
>
> With regard to dynamic IPs, the solution is to use a dynamic DNS
> service, and simply use the DNS name as the endpoint. When you set up
> the device after being disconnected, userspace will do the DNS lookup
> to determine a current IP. When you're already connected to that IP,
> WireGuard's roaming capabilities will automatically keep track of IP
> updates.

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.

>
> With regard to NAT, this is where you want your STUN-like solution.
> However, this does _not_ belong inside of WireGuard. This is where you
> simply need some basic userspace utility to handle punching holes in
> NAT/firewall, and then bringing up the WireGuard interface with the
> discovered address/port. It's not that complicated. In fact, there was
> already a substantial discussion about this on the list (did you check
> the archives?), and I wound up writing a simple PoC utility for it:
> https://git.zx2c4.com/WireGuard/tree/contrib/examples/nat-hole-punching/README
> It works well, though it of course needs work before it's
> production-ready.
This example the WireGuard server has a public IP address.   The case
I am mentioning Wireguard server may not have a public IP address.

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.

TURN relay protocol used in SIP and other usage cases is for when you
don't have a public IP address of your own and you are behind NAT
solutions where you cannot form a direct link between client and
server.
https://tools.ietf.org/html/rfc5766

TURN is not without is overhead.   Now if you are hosting a TURN
server somewhere it does not have to contain any important encryption
information as it just a Relay point.

> Perhaps you could rewrite it to use your glib-based
> libnice? Send an email here when you've got a github repo for
> something like this, as I'm sure a few others on the list might
> benefit from it too.
>

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.

The difference is a turn relay server is not holding critical secrets.

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.

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.

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.

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.

Peter Dolding