Frequently Asked Questions

If you have a common problem or question, you will probably be able to find an answer here. If it is not here, and even the documentation is of no help, please contact the authors.

  1. Frequently Asked Questions
  2. Error messages
    1. Bogus data received
    2. Cannot ping the other node(s)
    3. Packets looping back to us
  3. Platform specific questions
    1. Error while writing to Generic BSD tap device /dev/tap0: Input/output error on MacOSX or *BSD
    2. Is there an app for tinc?
  4. Generic questions
    1. Why tinc?

Error messages

Bogus data received

Jan 1 12:00:00 host tinc.net[1234]: Bogus data received from node (192.0.43.10)

Tinc tries to connect to another node but reports that bogus data has been received. This problem is almost always caused by a problem with the RSA keys from one of the nodes. Check that there is only one key in each rsa_key.priv and in each host config file. Also make sure that the host config files with the same name contain the same key on both nodes. When in doubt, remove the rsa_key.priv files, remove the public keys from the host config files, generate new keys and distribute them again.

Cannot ping the other node(s)

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Net Unknown

Or when logging with debug level 5:

Jan 1 12:00:00 host tinc.net[1234]: Cannot route packet from node (MYSELF): unknown IPv4 destination address 192.168.1.1

When trying to ping another node, it can happen that there is no response. First, check that the other node is really online, and that tinc has made a connection with it. When running tinc in router mode (which is the default), check that the node you are trying to reach has a Subnet statement in its host config file that contains the IP address you are trying to reach.

Packets looping back to us

Jan 1 12:00:00 host tinc.net[1234]: Packet with destination 192.168.1.1 is looping back to us!

A packet is received from the tapdevice, and tinc tries to send it to the right destination, but finds out that this packet should be send to itself. Chances are that a “Subnet = …” line in the host configuration file of this tinc daemon is wrong. Change it to a subnet that is accepted locally by another interface, or if that is not the case, try changing the prefix length into /32.

Platform specific questions

Error while writing to Generic BSD tap device /dev/tap0: Input/output error on MacOSX or *BSD

tinc needs to be running before configuring the network interface. Try assigning a static ip address, while tinc is running:

ifconfig tap0 <ip address>

If you are still having trouble, check that you have the tun/tap devices installed and configured for your kernel.

Is there an app for tinc?

Tinc itself supports many platforms, and in principle supports mobile platforms such as Android and iOS as well. However, on this website you will only find the source code (with some exceptions). Ready-to-install packages or apps are mostly made by third parties.

For Android, there are two apps available: tincapp.pacien.org or tinc_gui.poirsouille.org.

Generic questions

Why tinc?

Question: I’ve been using VPNs in a production environment, and until now that has been with FreeS/WAN. I would like to know what the differences are between tinc and FreeS/WAN.

Here’s what we think of that:

  • FreeS/WAN requires a kernel patch (IPSec is not yet a part of the mainstream kernel), while tinc runs completely in userspace. The advantages of the latter should be clear: portability is increased and errors in the implementation will not lead to kernel crashes.
  • Both FreeS/WAN and tinc use tunnels to send packets, but with FreeS/WAN, all tunnels have to be explicitly configured on all hosts, while tinc can set up a large part of the tunnels without requiring too much changing of configuration files. For the addition of 1 extra host in a VPN that is already made out of X hosts, FreeS/WAN requires a modification in X+1 configuration files, while for tinc, only 2 modifications are required.
  • tinc is made for solidness: some disfunctional hosts on the VPN won’t lead to the coming down of the entire VPN, while this is not true for most VPN implementations (especially when a star topology is used and the central node goes down).
  • Configuring tinc is mostly experienced to be easier than that of FreeS/WAN (according to users of both packages).
  • tinc will support the transmission of any kind of network package, not limiting it to IPv4 or IPv6. Multicast and broadcast packets will also be supported in the future.

Other reasons to use tinc instead of other solutions:

  • Although tinc uses a non-standard protocol, it does not suffer from the inefficiencies of most of the standard protocols.
  • The executable is very small, less than 150 kilobytes, the real memory usage is usually about 2 megabytes.