Node to Node UDP Tunnels HOWTO?

[Parke]

On Mon, May 14, 2018 at 4:44 AM, Keith Whyte <keith at rhizomatica.org> wrote:
> But then, suddenly, I am seeing flow of UDP from B to C on port 655.
> Now, I'm not asking about the NAT hole punching here, but rather;
>
> How is this possible if B and C do not have each others keys?

> I thought
> I understood this before in that somehow the key data is shared over the
> meta connection,

I believe the above is correct.

In your example, A will provide B's key to C, and ...

A will also provide C's key to B.

B and C will then attempt to establish a direct connection.  Whether
or not B and C will succeed depends upon whether or not they have
public IP addresses, what type of firewalls exist, whether or not B
and C are on the same private LAN, etc.

> but then I read that no, each host much have the key of
> the other to establish the direct connection. But I am looking at
> tcpdump right now in the terminal and seeing the UDP tunnel packets
> flowing from B to C.

Where do you read the above?

> I am really trying to understand how I can make this situation more
> persistent, but it seems so very random.
>
> Even in a case where I would make node B publicly reachable and add the
> keys everywhere, without an Explicit ConnectTo = B directive on node C,
> I still see packets routed via A.
>
> I would really like to know if there's some way to more reliably ensure
> that the UDP tunnel would be established from B to C and avoid a
> (transcontinental) route via A!

I believe, by default, Tinc will always try to establish direct data
connections between all nodes.  Perhaps such connections are only
attempted when there is data to send.  That is, if two nodes never
communicate with each other, they will not try to directly connect to
each other.

On-demand direct connections would explain why you observed the first
few pings are routed via A rather than directly.

Cheers,

Parke