5.5 Error messages

What follows is a list of the most common error messages you might find in the logs. Some of them will only be visible if the debug level is high enough.

‘Could not open /dev/tap0: No such device’

• You forgot to ‘modprobe netlink_dev’ or ‘modprobe ethertap’.
• You forgot to compile ‘Netlink device emulation’ in the kernel.

‘Can't write to /dev/net/tun: No such device’

• You forgot to ‘modprobe tun’.
• You forgot to compile ‘Universal TUN/TAP driver’ in the kernel.
• The tun device is located somewhere else in /dev/.

‘Network address and prefix length do not match!’

• The Subnet field must contain a network address, trailing bits should be 0.
• If you only want to use one IP address, set the netmask to /32.

‘Error reading RSA key file `rsa_key.priv': No such file or directory’

• You forgot to create a public/private key pair.
• Specify the complete pathname to the private key file with the ‘PrivateKeyFile’ option.

‘Warning: insecure file permissions for RSA private key file `rsa_key.priv'!’

• The private key file is readable by users other than root. Use chmod to correct the file permissions.

‘Creating metasocket failed: Address family not supported’

• By default tinc tries to create both IPv4 and IPv6 sockets. On some platforms this might not be implemented. If the logs show ‘Ready’ later on, then at least one metasocket was created, and you can ignore this message. You can add ‘AddressFamily = ipv4’ to tinc.conf to prevent this from happening.

‘Cannot route packet: unknown IPv4 destination 1.2.3.4’

• You try to send traffic to a host on the VPN for which no Subnet is known.
• If it is a broadcast address (ending in .255), it probably is a samba server or a Windows host sending broadcast packets. You can ignore it.

‘Cannot route packet: ARP request for unknown address 1.2.3.4’

• You try to send traffic to a host on the VPN for which no Subnet is known.

‘Packet with destination 1.2.3.4 is looping back to us!’

• Something is not configured right. Packets are being sent out to the virtual network device, but according to the Subnet directives in your host configuration file, those packets should go to your own host. Most common mistake is that you have a Subnet line in your host configuration file with a prefix length which is just as large as the prefix of the virtual network interface. The latter should in almost all cases be larger. Rethink your configuration. Note that you will only see this message if you specified a debug level of 5 or higher!
• 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.

‘Node foo (1.2.3.4) is not reachable’

• Node foo does not have a connection anymore, its tinc daemon is not running or its connection to the Internet is broken.

‘Received UDP packet from unknown source 1.2.3.4 (port 12345)’

• If you see this only sporadically, it is harmless and caused by a node sending packets using an old key.
• If you see this often and another node is not reachable anymore, then a NAT (masquerading firewall) is changing the source address of UDP packets. You can add ‘TCPOnly = yes’ to host configuration files to force all VPN traffic to go over a TCP connection.

‘Got bad/bogus/unauthorized REQUEST from foo (1.2.3.4 port 12345)’

• Node foo does not have the right public/private key pair. Generate new key pairs and distribute them again.
• An attacker tries to gain access to your VPN.
• A network error caused corruption of metadata sent from foo.