<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 April 2018 at 19:34, Alex Corcoles <span dir="ltr"><<a href="mailto:alex@corcoles.net" target="_blank">alex@corcoles.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>  Note that it would be easier to set up tinc nodes on your Windows<br>
> desktop and Linux laptops, to avoid the additional complication of<br>
> having to relay broadcast packets between your local networks and the<br>
> tinc network. This is what I do in my setup.<br>
<br>
</span>But both systems will be behind NAT routers. I could forward a port to<br>
the Windows desktop and use that, but it seems a bit longwinded. Or I<br>
could do the tinc-over-tinc, I guess, but I'm a bit concerned about<br>
latency.<br></blockquote><div><br></div></div>tinc is fully capable of traversing NATs automatically and transparently; it implements techniques such as UDP hole punching that are specifically designed to do just that.<br><br>The only requirement is that you have *some* nodes on your graph that are not subject to NATs. In your case that would be your linux boxes. If you add your laptop and Windows machine to that graph by establishing tinc connections between them and their respective linux boxes, these new nodes that are behind NATs will automatically leverage your nodes that aren't behind NATs for rendezvous, UDP hole punching, and falling back to plain forwarding as necessary. There is no need to forward any ports, and the latency will be pretty much unaffected.<br></div></div>