The FB2900 supports the following tunnelling protocols:-
- IPsec (IP security)
- FB105 lightweight tunnelling protocol
- ETUN (Ether tunnelling)
IPsec is an implementation of the IPsec protocol and IKEv2 key management protocol, as defined in various RFCs. This provides the means to authenticate and encrypt traffic sent over a public communication channel (such as the Internet).
L2TP client functionality enables tunnelled connections to be made to an L2TP server
Ether tunnelling provides a mechanism to tunnel layer 2 Ethernet traffic between two devices, using the protocol defined in RFC3378.
Support for FB105 tunnels means the FB2900 can inter-work with existing FB105 hardware. FB105 tunnels can also be set up between any two FireBricks from the FB2x00 and FB6000 ranges which support FB105 tunnelling.
IPsec (IP security)
One of the uses of IPsec is to create a private tunnel between two places. This could be two FireBricks, or between a FireBrick and some other device such as a router, VPN box, Linux box, etc.
The tunnel allows traffic to IP addresses at the far end to be routed over the Internet in secret, encrypted at the sending end and decrypted at the receiving end.
IPsec can also be used to set up a VPN between a roaming client and a server, providing security for working-at-home or on-the-road scenarios. This usage is usually known as a Road Warrior connection. The FireBrick can be used as the server for Road Warrior connections; it cannot act as a Road Warrior client.
There are three main aspects to IP Security: integrity checking, encryption and authentication.
The FB105 tunnelling protocol is a FireBrick proprietary protocol that was first implemented in the FireBrick FB105 device and is popular with FB105 users for setting up VPNs etc. It is ‘lightweight’ in as much as it is relatively simple, with low overhead and an easy setup procedure, but it does not currently offer encryption. Although encryption is not available, the protocol does digitally sign packets, so that tunnel end-points can be confident that the traffic originated from another ‘trusted’ end-point. Where it matters, encryption can be utilised via secure protocols such as HTTPS or SSH over the tunnel.
The protocol supports multiple simultaneous tunnels to/from an end-point device, and Local Tunnel ID values are used on an end-point device to identify each tunnel. The ‘scope’ of the Local ID is restricted to a single end-point device – as such, the tunnel itself does not possess a (single) ID value and is instead identified by the Local IDs in use at both ends, which may well differ.
L2TP (Layer 2 Tunnelling Protocol)
L2TP provides a simple means for PPP packets to be passed over an IP network. It uses a small header and UDP to pass packets between the LAC and LNS.
Sometimes it because sensible for the LAC to decide to which LNS it should connect by some means. A good example is where a carrier with LACs will route connections to wholesale customers’ LNSs. This would allow ISPs to make use of providers that have modems. This is actually the way it works on broadband access networks. For example, BT, O2, and TalkTalk have LACs in their network which passes L2TP to their ISP customers.
To achieve this, the LAC does some of the initial PPP negotiations. It handles the LCP and starts the authentication. It then establishes the L2TP connection passing these proxy details on to the LNS. The choice of LNS is done using the username, which is why it has to start the authentication. Typically a realm is included in the user name, using an @ and a string at the end of the username to steer the connection to the right LNS.
ETUN (Ether tunnelling)
More Information on Ether Tunnelling can be found here.