<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 April 2018 at 20:06, 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">Hi again,<br>
<span class=""><br>
On Fri, 2018-04-13 at 19:56 +0100, Etienne Dechamps wrote:<br>
> tinc is fully capable of traversing NATs automatically and<br>
> transparently; it implements techniques such as UDP hole punching<br>
> that are specifically designed to do just that.<br>
> <br>
> The only requirement is that you have *some* nodes on your graph that<br>
> are not subject to NATs. In your case that would be your linux boxes.<br>
> If you add your laptop and Windows machine to that graph by<br>
> establishing tinc connections between them and their respective linux<br>
> boxes, these new nodes that are behind NATs will automatically<br>
> leverage your nodes that aren't behind NATs for rendezvous, UDP hole<br>
> punching, and falling back to plain forwarding as necessary. There is<br>
> no need to forward any ports, and the latency will be pretty much<br>
> unaffected.<br>
<br>
</span>I'm not sure I follow. This would be a second mesh or add them to the<br>
first one?<br></blockquote><div><br></div><div>You only need one tinc graph.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

However, my linux boxes *are* behind a NAT (this is a home fiber<br>
connection doing the NAT, they are behind that). For my four-site mesh<br>
I take advantage that two nodes have public routable IPs *and* forward<br>
ports on the fiber router to the tinc daemons... but I'm thinking<br>
probably I'm doing it all wrong.</blockquote><div><br></div><div>That's fine. As long as all nodes can reach other through at least *some* path, they'll figure it out using UDP Hole Punching, and if that doesn't doesn't work, they will fall back to using intermediate nodes to forward packets.<br><br></div><div>In tinc, nodes always know everyone else's IP addresses and they always try to talk directly to each other as long as they're part of the same graph (and IndirectData is not enabled). That is true even if the nodes don't have a direct edge (metaconnection) to each other. If they can't talk to each other directly because of NATs, they will try to use UDP Hole Punching to get through the NAT. And if that doesn't work, they will fall back to sending packets indirectly through intermediate nodes until they find a path that works. This all happens automatically behind the scenes.<br><br></div><div>In addition to that, tinc 1.1 can also use UPnP (if it was enabled during build and at runtime) to automatically set up port forwarding on home routers, making it even more likely that direct communication can take place.<br></div></div><br></div></div>