On Mon, May 14, 2018 at 4:44 AM, Keith Whyte <[email protected]> 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 _______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
