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.
Jason A. Donenfeld
Jason at zx2c4.com
Thu Jan 5 21:33:03 CET 2017
On Thu, Jan 5, 2017 at 12:08 PM, Peter Dolding <oiaohm at 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
> 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
> 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
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
> 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
Yes, I'm aware. And this is exactly what the example code demonstrates
> 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.
More information about the WireGuard