L2TP NAT Port forwarding

L2TP VPN Network Requirements

The L2TP/IPSec VPN protocol set uses the 'port-less' IP protocol #50 (ESP) and #51 (AH) for IPSec transmission in addition to TCP 1701 for L2TP.  For optimal security L2TP/IPsec is operated on a dedicated public IP address behind a  firewall with compatible 1:1 NAT functionality.

The use of port-less protocols renders L2TP incompatible with M-NAT port forwarding.  To address this intended limitation a NAT traversal mechanism has been developed.  L2TP/IPsec With NAT-T encapsulated both the L2TP and IPSec traffic within UDP packets to provide a L2TP/IPSec VPN transport that is slightly less secure but is compatible with M-NAT and a single public IP address.  A static public IP address remains highly desirable however.

L2TP/IPSec (Native)

TCP 1701 L2TP

IPSec
  IP Protocol #50 ESP
  IP Protocol #51 AH

L2TP/IPSec with NAT-T

  UDP 500 IKE

  UDP 4500 ( L2TP/IPSec NAT-T mode)

Note: Windows clients will require the UDP encapsulation policy enabling in the registry

Key: HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent
Name:  AssumeUDPEncapsulationContextOnSendRule
Type: DWord
Value = 0x00000002

Routing / Split Tunnel

The original context of L2TP/IPSec was as a site2site and point to point client VPN transport, routing all traffic to a secure corporate gateway.  However, with the demise of the PPTP transport, use of L2TP has expanded to encompass dial up functionality and a need for split tunnel routing and split horizon DNS at the client. 

Split-horizon DNS is within the capability of PPP, whereby the client DNS server is dynamically configured use the private DNS server on the target network.  Subsequent DNS requests by the client are responded to by the private server which is able to resolve both public and private names. 

The major hurdle with a split tunnel is selectively routing traffic from the client via the tunnel end point and on to the remote private address space.  The majority of L2TP implementations use a virtual subnet to connect the client to the end point, as L2TP is incompatible overlapping subnet address spaces.  L2TP further lacks the capability to modify the client routing table, leaving the client without a route to the target address space.  To reach the destination subnet a method is needed to dynamically alter the client routing table.

Windows VPN Client

There is no graphical method of adding a route to the routing table or to the VPN client.  However, powershell provides cmdlets for automating VPN profile creation with dynamic routing table additions.

MacOSX / Linux

The PPP client can trigger the routing table addition by calling a shell script when the interface is connected, in the same way as other interface call shell scripts when they are raised.

$> sudo /etc/ppp/ip-up

#!/bin/bash

/sbin/route add -net 10.20.30.0/24 interface $1

$> chmod 0755 /etc/ppp/ip-up

Note the script is only called when the permissions are correctly set