On 13 April 2018 at 19:34, Alex Corcoles <alex at corcoles.net> wrote:> > Note that it would be easier to set up tinc nodes on your Windows > > desktop and Linux laptops, to avoid the additional complication of > > having to relay broadcast packets between your local networks and the > > tinc network. This is what I do in my setup. > > But both systems will be behind NAT routers. I could forward a port to > the Windows desktop and use that, but it seems a bit longwinded. Or I > could do the tinc-over-tinc, I guess, but I'm a bit concerned about > latency. >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. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180413/06b2048f/attachment.html>
Hi again, On Fri, 2018-04-13 at 19:56 +0100, Etienne Dechamps wrote:> 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. > > 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.I'm not sure I follow. This would be a second mesh or add them to the first one? However, my linux boxes *are* behind a NAT (this is a home fiber connection doing the NAT, they are behind that). For my four-site mesh I take advantage that two nodes have public routable IPs *and* forward ports on the fiber router to the tinc daemons... but I'm thinking probably I'm doing it all wrong.
On 13 April 2018 at 20:06, Alex Corcoles <alex at corcoles.net> wrote:> Hi again, > > On Fri, 2018-04-13 at 19:56 +0100, Etienne Dechamps wrote: > > 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. > > > > 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. > > I'm not sure I follow. This would be a second mesh or add them to the > first one? >You only need one tinc graph.> However, my linux boxes *are* behind a NAT (this is a home fiber > connection doing the NAT, they are behind that). For my four-site mesh > I take advantage that two nodes have public routable IPs *and* forward > ports on the fiber router to the tinc daemons... but I'm thinking > probably I'm doing it all wrong.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. 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. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180413/9aca4f0c/attachment-0001.html>