4.3 How connections work

When tinc starts up, it parses the command-line options and then reads in the configuration file tinc.conf. If it sees one or more ‘ConnectTo’ values pointing to other tinc daemons in that file, it will try to connect to those other daemons. Whether this succeeds or not and whether ‘ConnectTo’ is specified or not, tinc will listen for incoming connection from other deamons. If you did specify a ‘ConnectTo’ value and the other side is not responding, tinc will keep retrying. This means that once started, tinc will stay running until you tell it to stop, and failures to connect to other tinc daemons will not stop your tinc daemon for trying again later. This means you don’t have to intervene if there are temporary network problems.

There is no real distinction between a server and a client in tinc. If you wish, you can view a tinc daemon without a ‘ConnectTo’ value as a server, and one which does specify such a value as a client. It does not matter if two tinc daemons have a ‘ConnectTo’ value pointing to each other however.

Connections specified using ‘ConnectTo’ are so-called meta-connections. Tinc daemons exchange information about all other daemon they know about via these meta-connections. After learning about all the daemons in the VPN, tinc will create other connections as necessary in order to communicate with them. For example, if there are three daemons named A, B and C, and A has ‘ConnectTo = B’ in its tinc.conf file, and C has ‘ConnectTo = B’ in its tinc.conf file, then A will learn about C from B, and will be able to exchange VPN packets with C without the need to have ‘ConnectTo = C’ in its tinc.conf file.

It could be that some daemons are located behind a Network Address Translation (NAT) device, or behind a firewall. In the above scenario with three daemons, if A and C are behind a NAT, B will automatically help A and C punch holes through their NAT, in a way similar to the STUN protocol, so that A and C can still communicate with each other directly. It is not always possible to do this however, and firewalls might also prevent direct communication. In that case, VPN packets between A and C will be forwarded by B.

In effect, all nodes in the VPN will be able to talk to each other, as long as their is a path of meta-connections between them, and whenever possible, two nodes will communicate with each other directly.