<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Here are a few facts that should make things clearer.<br><br></div><div>Regarding keys:<br></div><div><br></div>- The key used for the metaconnections (routing protocol over TCP) - i.e. the one you configure in your host files - is NOT the same as the key used for UDP data tunnels.<br><br></div>- The key for data tunnels is negotiated over the metaconnections, by sending REQ_KEY and ANS_KEY messages over the metagraph (i.e. the graph of metaconnections). So, in your example, B will send a REQ_KEY message to A, which will forward it to C, which will respond with an ANS_KEY message, also forwarded through A.<br><br></div>- These "data keys" are generated on-the-fly and are ephemeral, with an expiry time set by the KeyExpire configuration option (1 hour by default). When the expiry time is up, the key is renegotiated using the same procedure as above.<br><br>(Note that in the 1.1 SPTPS protocol, the way the keys are exchanged is somewhat different, but the overall principle is the same.)<br><br></div>
Regarding 

forwarding of UDP data packets:<br><br></div>- When tinc doesn't know if a node is reachable directly over UDP (or if the hole punching hasn't been done yet), it will always fall back to a "safe route", i.e. forwarding via an intermediate node (or even going over the TCP metaconnection if the node is already a direct neighbour). This is to avoid packet loss and to allow packets to flow as early as possible, even if the optimal route is not fully set up yet.<br><br></div>- While tinc is doing the above, in parallel, it will send UDP "probe" packets to the destination node. These probes serve three purposes at the same time: (1) they enable tinc to determine if the destination node is reachable over UDP; (2) if it is, they 
enable 

tinc to determine the PMTU; and (3) they de facto act as NAT hole punchers (because both nodes will be sending probes to each over at the same time using the same ports).<br><br></div>- If the UDP probes do come back, indicating that the node is directly reachable over UDP, tinc will stop sending actual data packets through the "safe route" and will start sending UDP packets directly to the destination node. (Though depending on packet size, tinc might wait for PMTU estimation to be complete first.) This happens transparently to the user; as you witnessed, the packets just suddenly start flowing over UDP automagically. (This whole process is quite clever and very well done IMHO - Guus gets the credit for this fantastic job.)<br><br></div>- As long as the UDP packets keep flowing, tinc will continue to send packets over this direct UDP tunnel.<br><br></div>- If the UDP packets stop flowing, tinc will fall back to the "safe route" again and this whole process restarts from scratch. This happens if the UDP tunnel suddenly breaks (because of a change in network conditions), but it can also happen simply because the UDP tunnel became idle for some time.<br><br></div>Note that this is a somewhat simplified overview, and the details can differ slightly depending on whether you're using the 1.0 protocol or the 1.1 SPTPS protocol.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 May 2018 at 12:44, Keith Whyte <span dir="ltr"><<a href="mailto:keith@rhizomatica.org" target="_blank">keith@rhizomatica.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all!<br>
<br>
I still have never managed to fully wrap my head around how UDP data<br>
tunnels can be established between nodes.<br>
<br>
Everytime I think I understand it, I see something that confuses me again<br>
<br>
<br>
Just now I am seeing the following:<br>
<br>
I have nodes A, B + C<br>
<br>
A has everybody's keys and host configuration files.<br>
<br>
B and C only have A's key, and host config with A's public IP address.<br>
<br>
B and C DO NOT have each others keys. Likewise B and C both have a<br>
ConnectTo = A configuration directive.<br>
<br>
Only A is directly reachable with TCP and UDP on port 655, so there's no<br>
point to adding other ConnectTo Lines as neither B nor C are going to be<br>
directly reachable.<br>
<br>
I send some ICMP ping packets from B to C and intially I see as<br>
expected, the encapsulated tinc packets flow from B -> A and A -> C and<br>
back along that path/<br>
<br>
But then, suddenly, I am seeing flow of UDP from B to C on port 655.<br>
Now, I'm not asking about the NAT hole punching here, but rather;<br>
<br>
How is this possible if B and C do not have each others keys? I thought<br>
I understood this before in that somehow the key data is shared over the<br>
meta connection, but then I read that no, each host much have the key of<br>
the other to establish the direct connection. But I am looking at<br>
tcpdump right now in the terminal and seeing the UDP tunnel packets<br>
flowing from B to C.<br>
<br>
I am really trying to understand how I can make this situation more<br>
persistent, but it seems so very random.<br>
<br>
Even in a case where I would make node B publicly reachable and add the<br>
keys everywhere, without an Explicit ConnectTo = B directive on node C,<br>
I still see packets routed via A.<br>
<br>
I would really like to know if there's some way to more reliably ensure<br>
that the UDP tunnel would be established from B to C and avoid a<br>
(transcontinental) route via A!<br>
<br>
Thank you if you can shed any light on this!<br>
<br>
k/<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
tinc mailing list<br>
<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a><br>
<a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="noreferrer" target="_blank">https://www.tinc-vpn.org/cgi-<wbr>bin/mailman/listinfo/tinc</a><br>
</blockquote></div><br></div>