Example: bridging Ethernet segments using tinc under Linux

Normally, in the default router mode, tinc will only tunnel IPv4 and IPv6 unicast packets. However, since 1.0pre5 there is an option to let the tinc daemon act as a switch or a hub (using the Mode configuration variable). This mode is necessary for tinc to pass non-IP based protocols (NetBEUI, AppleTalk, IPX, etcetera), and to allow broadcast-based functionality in some applications (Windows ‘Network Neighborhood’ without a WINS server, among others) to be usable on a VPN created with tinc.

In switch and hub mode, broadcast packets are broadcast to other daemons and (in switch mode) MAC addresses are dynamically learned from other tinc daemons in order to route packets. With these mode tinc can be used to act as a bridge between two or more Ethernet segments.

Bridging allows all nodes in the VPN to share the same subnet. However, if this is the only reason for bridging, and you do not need to tunnel broadcast or non-IP packets, you can alternatively use proxy ARP instead of bridging.


The network setup is as follows:

  • Internal network, on both sides, is
  • The host’s own IP address on the internal network is

The gateway of each segment has an external interface, eth0, and an internal interface eth1. Furthermore a bridge interface will be created with name “bridge”, and the internal interface will be made a slave of this bridge. The virtual network interface used by tinc will also be a slave. Configuration of the kernel In addition to the standard kernel configuration described in the Configuring the kernel section of the manual, a bridge device needs to be added to your kernel configuration.

To add the bridge device to the Linux 2.4.0 and higher kernels, select the option under ‘Networking options’ called 802.1d Ethernet Bridging. You may either compile this option as a module or build it into the kernel. Configuration of the interfaces Switch and hub modes require that both sides of a tinc VPN be contained within the same subnet (in this example, the subnet is This is no different from the configuration that would be required if tinc was replaced with an actual switch or hub.

host# brctl addbr bridge
host# ifconfig bridge netmask

host# ifconfig eth1
host# brctl addif bridge eth1
host# ifconfig eth1 up

After starting tinc:

host# brctl show
bridge name     bridge id               STP enabled     interfaces
bridge          8000.005004003002       yes             eth1

host# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:20:30:40:50:60
          inet addr:  Bcast:  Mask:
          UP BROADCAST RUNNING  MTU:1500  Metric:1

eth1      Link encap:Ethernet  HWaddr 00:11:22:33:44:55

lo        Link encap:Local Loopback
          inet addr:  Mask:
          UP LOOPBACK RUNNING  MTU:3856  Metric:1

bridge    Link encap:Ethernet  HWaddr  00:11:22:33:44:55
          inet addr:  Bcast:  Mask:

vpn       Link encap:Ethernet  HWaddr 00:11:22:33:44:55

host# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   *        U     0      0        0 eth0     *          U     0      0        0 bridge
default         UG    0      0        0 eth0

Configuration of tinc

Note that switch and hub mode do not utilize the Subnet variable in the host files. Instead, any packet received by the bridge interface will be passed to the TUN/TAP device for processing. If your tinc instance is running in hub mode, all packets are forwarded to the remote tinc instance. In switch mode, tinc maintains an ARP cache to determine whether any received packet should be forwarded to the remote tinc instance.

host# cat /etc/tinc/vpn/tinc.conf
Name = segment1
Mode = switch
ConnectTo = segment2

host# cat /etc/tinc/vpn/tinc-up

ifconfig $INTERFACE
brctl addif bridge $INTERFACE
ifconfig $INTERFACE up

host# ls /etc/tinc/vpn/hosts
segment1  segment2  ...

host# cat /etc/tinc/vpn/hosts/segment1
Address =

host# cat /etc/tinc/vpn/hosts/segment2
Address =

Additional Configuration

If the Ethernet interface added to the bridge was used for the default route, you will need to re-add the default route.

If you want to be able to filter packets on your bridge interface, you will need to a kernel with ebtables support. More information For more information on Linux bridging, see the bridge-utils homepage.