How to Configure Security Policies to Allow L2TP VPN
There are three typical Layer 2 Tunneling Protocol (L2TP) VPN scenarios, which are described as follows.
Client-Initiated Scenario (Remote Users Accessing the Enterprise Intranet)
To access intranet resources in the client-initiated scenario, the remote user's device needs to establish an L2TP tunnel, an L2TP session, and a PPP connection with the L2TP network server (LNS), that is, the firewall. During the establishment of a PPP connection, the LNS allocates a private IP address to the remote user's device. The remote user's device exchanges L2TP packets with the LNS. In the data transmission phase, the service packets sent from the remote user's device are encapsulated by PPP and L2TP and then sent to the firewall. The firewall removes the L2TP header and PPP header of the service packets on the VT interface, searches for the private network route, and forwards the service packets to the server according to the route. Figure 9-6 shows the packet exchange process.
In the packet exchange process, the firewall functions as the LNS and processes the following types of packets:
- L2TP packets, including L2TP negotiation packets sent by the remote user's device and L2TP-encapsulated service packets. Public IP addresses are used as destination addresses in these packets, which are transmitted to the Local zone from the Untrust zone. The destination port is UDP 1701.
- Service packets decapsulated on the VT interface. Private IP addresses are used in these packets, which are transmitted to the security zone of the intranet server from the security zone of the VT interface.
Table 9-5 describes the configuration for security policies.
No. |
Name |
Source Security Zone |
Destination Security Zone |
Source Address/Region |
Destination Address/Region |
Service |
Action |
---|---|---|---|---|---|---|---|
101 |
Allow L2TP packet from remote uses |
Untrust |
Local |
any |
203.0.113.1/32 |
l2tp (UDP: 1701) |
permit |
102 |
Allow original packet from remote user |
DMZ |
Trust |
10.1.3.1-10.1.3.100 |
10.1.2.10/32 |
any1 |
permit |
1: Specify a service as required. If the server needs to proactively access the remote user's device, you need to configure a reverse security policy. To simplify the configuration, you can add the VT interface to the security zone where the intranet server resides. |
NAS-Initiated Scenario (Dial-Up Users Accessing the Enterprise Intranet)
In the NAS-initiated scenario, the dial-up user device first sends a broadcast PPPoE packet to establish a PPPoE connection with the carrier's NAS device. Then, the NAS and LNS negotiate an L2TP tunnel and establish an L2TP session. The dial-up user device applies to the LNS for a private IP address and sets up a PPP connection. In the data transmission phase, the service packets sent from the dial-up user device are encapsulated by PPP and PPPoE and then sent to the NAS. The NAS removes the PPPoE header from the packets on the VT interface, encapsulates the packets with an L2TP header, searches for the public network route, and sends the packets to the LNS according to the route. After receiving the packets, the LNS removes the L2TP header and PPP header of the packets on the VT interface, searches for the private network route, and forwards the packets to the intranet server according to the route.
According to the preceding figure:
- PPPoE packets exchanged between the dial-up user device and the NAS are broadcast packets, and therefore no security policy is required.
- The NAS sends L2TP negotiation packets and L2TP-encapsulated packets to the LNS from the Local zone and the security zone where the LNS resides.
- The LNS receives L2TP negotiation packets and L2TP-encapsulated service packets from the Untrust zone to the Local zone.
- After receiving the encapsulated service packets, the LNS decapsulates the packets on the VT interface and forwards them to the intranet server. That is, the packets are transmitted from the security zone of the VT interface and that of the server.
Table 9-6 describes the configuration for security policies.
No. |
Name |
Source Security Zone |
Destination Security Zone |
Source Address/Region |
Destination Address/Region |
Service |
Action |
---|---|---|---|---|---|---|---|
NAS on the carrier side |
|||||||
101 |
Allow L2TP packet to LNS |
Local |
Untrust |
192.0.2.1/32 |
203.0.113.1/32 |
l2tp (UDP: 1701) |
permit |
LNS on the enterprise side |
|||||||
201 |
Allow L2TP packet from NAS |
Untrust |
Local |
192.0.2.1/32 |
203.0.113.1/32 |
l2tp (UDP: 1701) |
permit |
202 |
Allow original packet from remote user |
DMZ |
Trust |
10.1.3.1-10.1.3.100 |
10.1.2.10/32 |
any1 |
permit |
1: Specify a service as required. To simplify the configuration, you can add the VT interface to the security zone where the intranet server resides. |
Call-LNS Scenario (Intranet Connection Through LAC Dial-Up)
In the call-LNS scenario, the L2TP access concentrator (LAC) proactively negotiates with the LNS to establish an L2TP tunnel, an L2TP session, and a PPP connection. During PPP connection establishment, the LNS allocates a private IP address to the VT interface of the LAC. During data transmission, the LAC uses translates the source IP address of the original packet to the VT interface address through source NAT, performs PPP encapsulation and L2TP encapsulation on the VT interface, and sends the encapsulated packet to the LNS through a public network route. After receiving the packet, the LNS removes the PPPoE header and PPP header from the packet on the VT interface, searches for the private network route, and forwards the packet to the server according to the route.
For the LAC:
- The LAC sends L2TP negotiation packets and L2TP-encapsulated packets to the LNS from the Local zone to the security zone of the LNS (Untrust).
- The service packets initiated by the intranet terminal need to be sent to the VT interface for encapsulation. Therefore, the destination security zone of the packets is the security zone where the VT interface resides.
For the LNS:
- The LNS receives the L2TP negotiation packets and L2TP-encapsulated packets from the security zone of the LAC to the Local zone.
- The LNS decapsulates the packets on the VT interface and sends the packets to the intranet server. The source and destination security zones of the packets are security zone of the VT interface and that of the intranet server, respectively. The source IP address of the decapsulated packets is the private IP address obtained by the VT interface on the LAC.
If the intranet terminal on the LNS side needs to proactively access services on the LAC side, the service packets need to be encapsulated on the LNS and decapsulated on the LAC. Therefore, you need to configure reverse security policies. Table 9-7 describes the configuration for security policies.
No. |
Name |
Source Security Zone |
Destination Security Zone |
Source Address/Region |
Destination Address/Region |
Service |
Action |
---|---|---|---|---|---|---|---|
LAC |
|||||||
101 |
Allow L2TP packet to LNS |
Local |
Untrust |
192.0.2.1/32 |
203.0.113.1/32 |
l2tp (UDP: 1701) |
permit |
102 |
Allow original packet from local user |
Trust |
DMZ |
10.3.3.0/24 |
10.1.2.0/24 |
any1 |
permit |
103 |
Allow original packet from remote user |
DMZ |
Trust |
10.1.2.0/24 |
10.3.3.0/24 |
any1 |
permit |
LNS |
|||||||
201 |
Allow L2TP packet from LAC |
Untrust |
Local |
192.0.2.1/32 |
203.0.113.1/32 |
l2tp (UDP: 1701) |
permit |
202 |
Allow original packet from remote user |
DMZ |
Trust |
10.1.3.1-10.1.3.1002 |
10.1.2.0/24 |
any1 |
permit |
203 |
Allow original packet from local user |
Trust |
DMZ |
10.1.2.0/24 |
10.1.3.1-10.1.3.1002 |
any1 |
permit |
1: Specify a service as required. If the server needs to proactively access the remote user's device, you need to configure a reverse security policy. To simplify the configuration, you can add the VT interface to the security zone where the intranet server resides. 2. The source IP address of the service packets decapsulated on the LNS is the IP address allocated to the VT interface on the LAC instead of the IP address of the remote intranet PC. |