VPN Tunneling with tinc

VPN tunneling

The Config tab in tinc in pfSense.

tinc is a Virtual Private Network (VPN) daemon that uses VPN tunneling and encryption to create a secure private network between hosts on the Internet. Because the tunnel appears to the IP level network code as a normal network device, there is no need to adapt any existing software. The encrypted tunnels allow VPN sites to share information with each other over the Internet without exposing any information to others. tinc is free software and is licensed under the GNU General Public License (GPL). tinc incorporates the following features:

  • Encryption, authentication and compression
  • Automatic full mesh routing
  • Easy to add nodes to your VPN
  • Ability to bridge ethernet segments to work like a single segment
  • VPN tunneling that runs on many operating systems (Linux, FreeBSD, OpenBSD, NetBSD, MacOS X, Solaris, Windows 2000, Windows XP, Windows Vista and Windows 7/8 supported)

VPN Tunneling with tinc: Installation and Configuration

If you choose to install tinc on any of these platforms, binaries are available on the tinc website, as well as documentation. If you choose to install it under pfSense, installation is as easy as finding the tinc package on the package list after navigating to System -> Packages. Once you have found it, click on the “plus” button to install the package, and on the next screen, press the “Confirm” button to confirm installation. The installation should complete within a few minutes.

Once tinc is installed, there will be a new entry under the “VPN” menu called “tinc”. Before you start to configure tinc for VPN tunneling, it might be a good idea to consider how you want to organize your VPN. For example, what are the nodes running tinc? What IP addresses and subnets do they have? What is the network mask of the entire VPN? Do you need special firewall rules, and do you have do set up masquerading or forwarding rules? Do you want to run tinc in router mode or switch mode? It also helps to have a good general understanding of networks.

VPN tunneling

The Hosts tab in tinc.

If you navigate to VPN -> tinc, there are two tabs: “Config” and “Hosts”. Under the “Config” tab, there are several configuation paramters. The “Name” field allows you to enter a name to identify the tinc daemon, which must be unique for the VPN to which this daemon will connect. The “Local IP” field allows you to enter the IP address of the local tunnel interface (often the same IP as your router’s LAN address). “Local Subnet” allows you to specify the subnet behind the router that should be advertised to the mesh, and “VPN Netmask” defines what traffic is the router to the VPN’s tunnel interface. The “AddressFamily” dropdown allows you to select whether listening and outgoing sockets, are IPv4, IPv6, or whether it depends on the operating system. In the “RSA private key” and “RSA public key” fields, you can specify an RSA private/public key pair. You can also check the “Generate RSA key pair” checkbox to generate a new RSA key pair.

On the “Hosts” tab, you can add new hosts by clicking on the “plus” button. The “Name” field allows you to specify a name, while “Address” is for the IP address and “Subnet” is for the subnet behind the host. The “Connect at startup” check box specifies whether tinc should try to connect to the host when it starts. There is also a field for an RSA public key. There are also several advanced settings in both the “Config” and “Hosts” tab; however, if you configure these basic parameters, you should be ready to use tinc VPN tunneling.

External Links:

The official tinc website

Tinc on Wikipedia (just a stub)

pfSense Bridges

pfSense Bridges

The bridge settings page in pfSense.

Bridging allows you to join two networks together. Bridging is distinct from routing which allows the networks to communicate independently as separate networks. Unlike routing, which takes place at the network layer of the OSI model, bridging takes place at the data link layer. Like a repeater, a bridge passes frames from one network segment to another. Unlike a repeater, a bridge monitors and records network traffic, eventually reaching the point where it can filter and forward traffic. This makes a bridge more intelligent than a repeater. In most cases, setting up pfSense bridges is relatively easy, but there are many options, which will be covered in this article.

pfSense Bridges: Basic Options

To bridge interfaces, first navigate to Interfaces -> (assign). Then click the “Bridges” tab and click the plus button. At “Member Interfaces“, select two interfaces by clicking on each interface while holding down the CTRL key. At “Description“, enter a description if desired. Then press the “Save” button to save the changes.

pfSense Bridges: Advanced Options

Setting up a bridge can be that easy. However, by clicking on “Show advanced options“, you can also configure other parameters. At “RTSP/STP“, there are several options relevant to setting up a spanning tree. The first is “Enable spanning tree options for this bridge“. A spanning tree, by definition, is a graph with no loops. A physical topology that contains switching or bridge loops is attractive for redundancy, yet a switched loop must not have loops. Loops will create broadcast radiation as broadcasts and multicasts are forwarded by switches out of every port. The switch or switches will repeatedly rebroadcast the broadcast messages, flooding the network. Since the Layer 2 (data link layer) header does not support a time to live (TTL) value, if a frame is sent into a looped topology, it can loop forever. The solution is to allow physical loops, but create a loop-free logical topology using the spanning tree protocol on the network switches.

pfSense Bridges

Advanced options for bridging in pfSense 2.0.

If you want to implement a spanning tree on your bridge, you must choose a protocol, which you can do with the “Protocol” option. There are two choices: Spanning Tree Protocol (STP), and Rapid Spanning Tree Protocol (RSTP). Spanning Tree Protocol is a network protocol that ensures a loop-free topology for any bridged Ethernet local area network. The operation of STP entails the following: [1] selecting a root bridge (the bridge with the lowest bridge ID); [2] determining the least cost paths to the root bridge, and [3] disabling all other root paths. This should leave us with a minimum spanning tree. Obviously if the network topology changes either because new bridges are added or because old ones go offline, then the spanning tree will have to be re-created, and STP is able to do this automatically, although it is somewhat slow in this respect. STP is standardized as 802.1D.

In 2001, the IEEE introduced Rapid Spanning Tree Protocol (RSTP) as 802.1w. RSTP provides significantly faster spanning tree convergence after a topology change, including new convergence behaviors and bridge port rules to do this, and it was designed to be backwards-compatible with standard STP. While STP can take 30 to 50 seconds to respond to a topology change, RSTP is typically able to respond to changes much faster, sometimes within a few milliseconds of a physical link failure. It can typically respond to changes within 3 times the Hello time. The Hello time is a configurable time interval that RSTP uses for several purposes and is configurable; the default value is 2 seconds.

At “STP interfaces“, you can select which interfaces on which STP/RSTP is enabled. At “Valid time“, you can set the time that a STP configuration is valid. The default is 20 seconds. The minimum is 6 seconds, and the maximum is 40 seconds. At “Forward Time” you can set the time that must pass before an interface begins forwarding packets when STP/RSTP in enabled. The default is 15 seconds; the minimum is 4 seconds and the maximum is 30 seconds.

At “Hello time” (mentioned briefly in the description of RSTP), you can set the time between broadcasting of Spanning Tree Protocol configuration messages. The hello time may only be changed when operating in legacy STP mode. The default is 2 seconds; the minimum is 1 second and the maximum is 2 seconds.

At “Priority“, you can set the bridge priority for the Spanning Tree. The default is 32768, but you can set it anywhere from 0 to 61440. The “Hold Count” allows you to set the transmit hold count for the Spanning Tree; this is the number of packets transmitted before being rate-limited. The default is 6 but you can set it to anything from 1 to 10.

Next is a second “Priority” setting, one which allows you to set priorities for individual interfaces. The default is 128 but it can be set anywhere from 0 to 240. Finally, at “Path cost” you can set the Spanning Tree path cost of each interface. The path costs are used to generate the spanning tree. If nothing is entered here, the algorithm will by default calculate path cost based on the link speed. Set the cost to 0 to set it back to the default. The minimum is 1 and the maximum is 2000000000.

The next two settings are “Cache Size” and “Cache entry expire time“. “Cache Size” sets the size of the bridge address cache (the default is 100 entries). “Cache entry expire time” sets the timeout of address cache entries (the default is 240 seconds).

Next is “Span port“. Setting an interface as a span port (also referred to as “port mirroring”) causes that interface to transpit a copy of every frame received by the bridge. This is most useful for snooping a bridged network passively on another host connected to one of the span ports of the bridge. This is commonly used for network appliances that require monitoring of network traffic, such as an intrusion detection system, passive probe or real user monitoring (RUM) that is used to support application performance management (APM). The span interface cannot be part of the bridge member interfaces.

The next two settings are “Edge ports” and “Auto edge ports“. “Edge ports” allows you to set a port that is only connected to one bridge as an edge port so it will automatically transition to the forwarding state. RSTP still continues to monitor the port in case a bridge is connected. “Auto edge ports” allows an interface to automatically detect edge status. This is the default for all interfaces added to a bridge.

The next two settings are “PTP ports” and “Auto PTP ports“. “PTP ports” allows you to set the interface as a point-to-point link. This is required for straight transitions to forwarding and should be enabled on a direct link to another RSTP-capable switch. “Auto PTP ports” automatically detect the point-to-point status on an interface by checking the full duplex link status. This is the default for interfaces added to the bridge. The interfaces selected here will be removed from default autoedge status.

Sticky ports" and "Private ports". "Sticky" ports enables you to mark an interface as "sticky" it is never aged out of the cache or replaced, even if the address is seen on a different interface. "Private ports" enables you to mark an interface as private, so that it does not forward any traffic to any other port that is also a private interface.

If your network topology is simple, then it is probably enough to set up a simple network bridge. In other cases, however, it may behoove you to set up a spanning tree using STP or RST when setting up your pfSense bridges.

External Links:

Spanning Tree Protocol on Wikipedia

Interface Bridges at doc.pfsense.org

© 2013 David Zientara. All rights reserved. Privacy Policy