12.3. L2TP tunnelling

12.3. L2TP tunnelling
	Chapter 12. Tunnels

Layer 2 tunnelling protocol is a standard way to pass IP packets via a tunnel. It was originally used for dialup connections, connecting the RAS (Remote Access Server) to the LNS (L2TP Network Server), and is still used today within Internet Service Providers for broadband connections. L2TP has the advantage that it is very standard and interacts with a variety of equipment.

The FireBrick provides a means to accept static L2TP connections with configured username, password, and IP routing.

The FireBrick also provides a means to make an outgoing L2TP connection as if it was a RAS, connecting to an LNS. This can be used with ISPs that offer this service, or could be used, for example, to connect to another FireBrick.

The FireBrick can act as full LNS, designed to allow thousands of connections to be handled by an ISP. See Chapter 19 for more details.

Note

Some systems may refer to L2TP when they actually mean L2TP over IPsec, which was used more commonly before IKEv2 was available in IPsec, and is not supported.

12.3.1. Outgoing L2TP

The tunnel/L2TP configuration allows you to create an outgoing L2TP connection. The connection will need two levels of authentication - one for the tunnel and one for the session. Both have a form of username and password - for the tunnel this is called the hostname and secret. In practice, as with any authentication, one or both of these may not actually be needed - e.g. a tunnel may be open and only validate used based on the PPP username/password.

Note

As with other tunnels, it is often useful to set the payload table to a different routing table to the tunnel traffic, to avoid sending tunnel traffic down the tunnel. This is particularly important for an outgoing tunnel as the default is to route all traffic (i.e. 0.0.0.0/0 and ::/0) down the tunnel when connected. You can configure specific routes to be passed down the tunnel if you wish. Routing in to this tunnel depends entirely on the configuration at the other end.

Tip

The debug level logging is ideal for showing the details of the low level connection and PPP negotiation. This is recommended when first setting up such tunnels, and should be checked at both ends to identify any errors or problems.

12.3.2. Static incoming L2TP

In addition to working as an LNS, as an Internet Service Provider, and using RADIUS, it is also possible to configure static incoming tunnels.

The incoming L2TP configuration is in two stages, one for the tunnel (which matches the hostname and secret used), and then for sessions within the tunnel. Static sessions are configured by specific matching rules. These can check various credentials from the incoming connection, but the main ones used would be username and password. Once matched, you can set the IP or blocks of IPs to be routed to the connection.

It is also possible to configure matching critera to cause the incoming connection to be relayed by L2TP on to another LNS.

12.3.3. High availability L2TP

The L2TP configuration has an optional ha-set setting allowing you to define that sessions in the specified tunnel are used for High availability.

This means any packets sent to the sessions are in fact sent to each session (duplicated). At the receiving end the first of each duplicate is passed on as normal and any subsequent ones discarded.

This sacrafices bandwidth for high availability and reliability.

You need to ensure packets are routed to the multiple sessions in the set, in the same way as bonding L2TP, and also that they are put in the same ha-set.

Note

The receive byte counts and any graphs on the L2TP tunnels will show the duplicate packets, as this shows the process is working. However, a packet dump of L2TP session content traffic does not include the duplicate packets. A packet dump of the L2TP wrapper traffic will, of course, show the wrapper duplicate packets received.


12.2. FB105 tunnels		12.4. Ether tunnelling