Automatic configuration of direct routes behind NAT

[Pedro Côrte-Real]

On Wed, Feb 22, 2012 at 4:18 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> I will see if it is possible to add something like this to the protocol in a
> backwards-compatible way.

Cool, thanks

> The STUN protocol, as defined in RFC5389, is meant to be used in a stand-alone
> server, and is more complex than is necessary for tinc. The basic idea of STUN
> is used though; a third node that is in communication with two other nodes
> forwards the UDP address and port that the first one uses to the second, so the
> second can connect back to that exact address/port combination. This requires
> that the NAT device of the first node allows incoming packets from the second
> node on that address/port combination, also knows as "cone NAT". For more
> details, see http://en.wikipedia.org/wiki/Network_address_translation. Luckily,
> most cheap ADSL routers implement cone NAT.

I'll have to try it, thanks.

>> Bringing it all together:
>> 1- If Address fields are specified try those
>
> This could indeed be added. At the moment, the Address field is only used when
> making the initials connections defined by ConnectTo statements.

I didn't realize that. So right now you don't get automatic
connections even if everyone has public IP addresses specified in
Address but don't have ConnectTo lines to everyone else? How does the
example in the blog post where the ping starts high but then goes low
work then? What discovery is happening?

>> 3- Try a direct connection to the IP address of the peer as seen by
(...)
> Tinc does 3.

I had read that as you suggesting that that could be done.

Thanks,

Pedro