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.
Error messages
Tinc doesn’t start, but doesn’t show an error message
If you’re are using tinc 1.0.2, chances are tinc cannot write the pidfile. Normally tinc would tell you this, but in this particular version that error message is missing. When starting tinc, add —pidfile=/tmp/tinc.pid or run mkdir -p /usr/local/var/run to solve this problem.
This bug is fixed in 1.0.3.
File descriptor in bad state
Jan 1 12:00:00 host tinc.net[1234]: Error while reading from ethertap device: File descriptor in bad state
Due to some changes in the header files in recent Linux 2.4 kernels, a tinc daemon that is not recompiled against your kernel headers will fail to work. You must recompile tinc and make sure it uses the header files from the kernel source tree. Some distributions ship with their own copy of these files in /usr/include/linux, you can explicitly override this by running ./configure —with-kernel=[path to kernel source].
Tinc stops functioning after a few hours
There is a small bug in the tinc 1.0pre4 tarball which prevents tinc from notifying the other daemons that its key has expired. One workaround is to edit tinc.conf and add KeyExpire = 30000000, which will set the lifetime of a key to roughly one year.
The bug is fixed in 1.0pre5 and later versions.
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.
Address family not supported by protocol
Jan 1 12:00:00 host tinc.net[1234]: Creating metasocket failed: Address family not supported by protocol
Jan 1 12:00:00 host tinc.net[1234]: Ready
This is not an error, but a warning. Tinc 1.0 and later try to create IPv6 sockets by default. If your kernel has no support for IPv6, this message is logged. However, if tinc logs “Ready”, an IPv4 socket was created without problems, and that one will be used. You can ignore this message, or prevent it from appearing in your logs by adding the following to tinc.conf:
AddressFamily = ipv4
Platform specific questions
No TAP-Win32 interface under Windows XP SP2
Because of changes in Windows XP since SP2, the TAP-Win32 driver distributed with the tinc-1.0.2 installer doesn’t work correctly. Remove all tap devices (use deltapall.bat) and install tinc 1.0.4.
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 100 kilobytes, the virtual memory footprint is about 4 megabytes (this includes the libraries it uses).
Is there a MS Windows client for tinc?
Question: We are about to use a Linux machine as a firewall to protect our office setup. We are interested in using tinc to allow us to VPN through the firewall from home however home machines have a tendency to be running “that” operating system, the one from Redmond. Is there a tinc compatible VPN client for machines running Microsoft operating systems?
As of tinc 1.0, Windows 2000 and XP are supported. It uses the TAP-Win32 driver as a virtual network device. There are two ways of compiling tinc: in a Cygwin environment or in a MinGW environment. The former provides a complete UNIX environment with all facilities common to UNIX. When compiled with Cygwin, tinc must be run in the Cygwin environment, but native Windows programs will also be able to use the VPN. When compiled with MinGW, tinc will be a native Windows program. When started, it will register itself as a service, which will run in the background and will be restarted after reboots.