<div dir="ltr">On Mon, Apr 17, 2017 at 12:55 PM, Jason A. Donenfeld <span dir="ltr"><<a href="mailto:Jason@zx2c4.com" target="_blank">Jason@zx2c4.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Mon, Apr 17, 2017 at 7:45 PM, Jason E. Aten <<a href="mailto:j.e.aten@gmail.com">j.e.aten@gmail.com</a>> wrote:<br>
> 1. If it uses UDP only, how does NAT traversal (firewall punch through)<br>
> work?<br>
<br>
</span>The same way UDP punching works every place else.<span class="gmail-"><br></span></blockquote><div><br></div><div>Thanks, Jason, for the quick reply.<br></div><div><br>If I read through the wikipedia article on UDP hole punching, it (<a href="https://en.wikipedia.org/wiki/UDP_hole_punching">https://en.wikipedia.org/wiki/UDP_hole_punching</a>) suggests that a public 3rd party is needed.<br><br>> S is a public server with a well-known, globally reachable IP address.<br><br></div><div>...which makes total sense. Conversely, I don't see described anywhere a public 3rd party protocol for wireguard clients to rendezvous.<br><br>I found this post: <a href="https://lists.zx2c4.com/pipermail/wireguard/2016-August/000372.html">https://lists.zx2c4.com/pipermail/wireguard/2016-August/000372.html</a>, which makes rendezvous seem like an after thought. <br><br>Should I conclude that addressing NAT-ed clients is not something that WireGuard itself plans to address? <br><br>The "number of security problems" with the approach mentioned in passing in the 2016-August message would need enumeration and addressing. Is anybody thinking about those? Is this on the roadmap for future plans?<br></div><br>Regards,<div>Jason<br></div></div></div></div>