Example configuration (tinc Manual)

Imagine the following situation. Branch A of our example ‘company’ wants to connect three branch offices in B, C and D using the Internet. All four offices have a 24/7 connection to the Internet.

A is going to serve as the center of the network. B and C will connect to A, and D will connect to C. Each office will be assigned their own IP network, 10.x.0.0.

A: net 10.1.0.0 mask 255.255.0.0 gateway 10.1.54.1 internet IP 1.2.3.4
B: net 10.2.0.0 mask 255.255.0.0 gateway 10.2.1.12 internet IP 2.3.4.5
C: net 10.3.0.0 mask 255.255.0.0 gateway 10.3.69.254 internet IP 3.4.5.6
D: net 10.4.0.0 mask 255.255.0.0 gateway 10.4.3.32 internet IP 4.5.6.7

Here, “gateway” is the VPN IP address of the machine that is running the tincd, and “internet IP” is the IP address of the firewall, which does not need to run tincd, but it must do a port forwarding of TCP and UDP on port 655 (unless otherwise configured).

In this example, it is assumed that eth0 is the interface that points to the inner (physical) LAN of the office, although this could also be the same as the interface that leads to the Internet. The configuration of the real interface is also shown as a comment, to give you an idea of how these example host is set up. All branches use the netname ‘company’ for this particular VPN.

For Branch A

# Real interface of internal network:
# ifconfig eth0 10.1.54.1 netmask 255.255.0.0

ifconfig $INTERFACE 10.1.54.1 netmask 255.0.0.0

Name = BranchA
Device = /dev/tap0

Subnet = 10.1.0.0/16
Address = 1.2.3.4

-----BEGIN RSA PUBLIC KEY-----
...
-----END RSA PUBLIC KEY-----

Note that the IP addresses of eth0 and tap0 are the same. This is quite possible, if you make sure that the netmasks of the interfaces are different. It is in fact recommended to give both real internal network interfaces and tap interfaces the same IP address, since that will make things a lot easier to remember and set up.

For Branch B

# Real interface of internal network:
# ifconfig eth0 10.2.43.8 netmask 255.255.0.0

ifconfig $INTERFACE 10.2.1.12 netmask 255.0.0.0

Name = BranchB
ConnectTo = BranchA

Note here that the internal address (on eth0) doesn’t have to be the same as on the tap0 device. Also, ConnectTo is given so that this node will always try to connect to BranchA.

Subnet = 10.2.0.0/16
Address = 2.3.4.5

-----BEGIN RSA PUBLIC KEY-----
...
-----END RSA PUBLIC KEY-----

For Branch C

# Real interface of internal network:
# ifconfig eth0 10.3.69.254 netmask 255.255.0.0

ifconfig $INTERFACE 10.3.69.254 netmask 255.0.0.0

Name = BranchC
ConnectTo = BranchA
Device = /dev/tap1

C already has another daemon that runs on port 655, so they have to reserve another port for tinc. It knows the portnumber it has to listen on from it’s own host configuration file.

Address = 3.4.5.6
Subnet = 10.3.0.0/16
Port = 2000

-----BEGIN RSA PUBLIC KEY-----
...
-----END RSA PUBLIC KEY-----

For Branch D

# Real interface of internal network:
# ifconfig eth0 10.4.3.32 netmask 255.255.0.0

ifconfig $INTERFACE 10.4.3.32 netmask 255.0.0.0

Name = BranchD
ConnectTo = BranchC
Device = /dev/net/tun

D will be connecting to C, which has a tincd running for this network on port 2000. It knows the port number from the host configuration file. Also note that since D uses the tun/tap driver, the network interface will not be called ‘tun’ or ‘tap0’ or something like that, but will have the same name as netname.

Subnet = 10.4.0.0/16
Address = 4.5.6.7

-----BEGIN RSA PUBLIC KEY-----
...
-----END RSA PUBLIC KEY-----

Key files

A, B, C and D all have generated a public/private keypair with the following command:

tincd -n company -K

The private key is stored in /etc/tinc/company/rsa_key.priv, the public key is put into the host configuration file in the /etc/tinc/company/hosts/ directory. During key generation, tinc automatically guesses the right filenames based on the -n option and the Name directive in the tinc.conf file (if it is available).

Starting

After each branch has finished configuration and they have distributed the host configuration files amongst them, they can start their tinc daemons. They don’t necessarily have to wait for the other branches to have started their daemons, tinc will try connecting until they are available.

4.7 Example configuration