[Dr.WoW] [No.28] L2TP LAC-Auto-initiated VPNs Highlighted

Latest reply: Jul 14, 2015 03:40:39 3732 1 0 0

LAC-auto-initiated VPNs are also called LAC automatic dialing VPNs. These do just what they sound like they do―after LAC configuration is complete, the LAC will automatically dial the LNS and establish an L2TP tunnel and session, meaning that it is not necessary for the branch organization user to dial-up to trigger this. For the branch organization user, this means that accessing the HQ network is the same as accessing his/her own branch organization's network, and he/she won't feel at all as if they are on a remote connection. However, in this method the LNS only authenticates the LAC, so that so long as the branch organization user is able to connect to the LAC they can use the L2TP tunnel to connect to HQ, meaning that this method offers slightly lower security compared with NAS-initiated VPNs.

1 LAC-Auto-initiated VPN Principles and Configuration

As shown in Figure 1-1, the set-up process for LAC-auto-initiated VPNs is similar to that of client-initiated VPNs, except that for LAC-auto-initiated VPNs, the LAC has replaced the role the L2TP client plays for client-initiated VPNs.

Figure 1-1 Set-up process for LAC-auto-initiated VPNs

[Dr.WoW] [No.28] L2TP LAC-Auto-initiated VPNs-1229993-1

 

Each step in the set-up process is largely similar to the set-up process for client-initiated VPNs, and I won't say any more except that you can review "5.4 L2TP Client-initiated VPNs". One point to note is that in step 3, the LNS only authenticates the LAC, and after successful authentication the LNS assigns an IP address to the LAC's VT interface, not to the branch organization user. Although the LNS does not assign an IP address for the branch organization, this doesn't mean that the branch organization's IP address can be configured at will. In order to ensure normal access between the branch organization network and the HQ network, please plan separate, independent private network segments for the branch organization and HQ networks, and ensure that the network segments for the two do not overlap.

Configuration of LAC-auto-initiated VPNs is not complicated, and we can set up a network like the one shown in Figure 1-2.

Figure 1-2 LAC-auto-initiated VPN network

[Dr.WoW] [No.28] L2TP LAC-Auto-initiated VPNs-1229993-2

 

Configuration for the LAC and LNS is shown in Table 1-1. A key point is that the connections between the LAC, LNS, and internal server are direct connections, eliminating the need to configure routing. User authentication also uses relatively simple local authentication. Additionally, gateways need to be configured for both the branch organization user and the internal network server, to ensure that packets exchanged between the two are able to be sent to the LAC and LNS.

Table 1-1 Configuring an L2TP LAC-auto-initiated VPN

LAC

LNS

l2tp enable

l2tp-group 1

 tunnel authentication

tunnel password cipher Password1

 tunnel name lac

 start l2tp ip 1.1.1.2 fullusername lac //Designates an address for the tunnel's other terminal.

interface Virtual-Template 1

 ppp authentication-mode chap

 ppp chap user lac

 ppp chap password cipher Password1

 ip address ppp-negotiate

 call-lns local-user lac binding l2tp-group 1   //LAC dials LNS.

ip route-static 192.168.0.0 255.255.255.0 Virtual-Template 1  //Configures a static route to the HQ network; this is different than in client-initiated VPNs and NAS-initiated VPNs, and the LAC must configure this route to guide branch organization user packets seeking to access the HQ network into the L2TP tunnel.

l2tp enable

interface Virtual-Template 1

 ppp authentication-mode chap

 ip address 10.1.1.1 255.255.255.0

 remote address pool 1

l2tp-group 1

tunnel authentication

 tunnel password cipher Password1

 allow l2tp virtual-template 1 remote lac  //Permits remote access.

aaa

local-user lac password Password1

 local-user lac service-type ppp

ip pool 1 10.1.1.2   //As the LNS only assigns addresses for the LAC, only one IP address needs to be configured in the address pool.

ip route-static 172.16.0.0 255.255.255.0 Virtual-Template 1   //Configures a static route to the branch organization network; if a source NAT is configured on the LAC this route does not need to be configured, and more details about this are provided below.

 

 

The characteristics of LAC-Auto-initiated VPN tunnels are briefly summarized below:

As shown in Figure 1-3, in LAC-auto-initiated VPN scenarios, a permanent tunnel is established between the LAC and LNS, which only carries one permanent L2TP session and PPP connection. The L2TP session and PPP connection only exists between the LAC and the LNS.

Figure 1-3 Relationship between the L2TP tunnel/session and the PPP connection on a LAC-auto-initiated VPN

[Dr.WoW] [No.28] L2TP LAC-Auto-initiated VPNs-1229993-3

 

PPP encapsulation and L2TP encapsulation in a LAC-auto-initiated VPN are limited only to packets exchanged between the LAC and the LNS, as shown in Figure 1-4.

Figure 1-4 LAC-auto-initiated VPN packet encapsulation process

[Dr.WoW] [No.28] L2TP LAC-Auto-initiated VPNs-1229993-4

 

Additionally, there is still another issue that requires special attention, this being how return packets enter the tunnel. This process is different than in client-initiated VPNs and NAS-initiated VPNS; in LAC-auto-initiated VPNs the LNS only issues one destination address for the LAC's VT interface address's UNR route, and doesn't have a route going to the branch organization's network. In response to this the LNS asserts: "I'm only responsible for assigning IP addresses, and can ensure that the LAC's VT interface is reached. The branch organization network's addresses are not assigned by me, and I don't even know what their addresses are, so I can only say 'Sorry, I can't help you'".

How can this problem be resolved? The simplest method is to manually configure a static route to the branch organization network on the LNS, guiding the return packets into the tunnel:

[LNS] ip route-static 172.16.0.0 255.255.255.0 Virtual-Template 1

Are there other methods we can use besides configuring a static route? I've just recalled NAT, which we mentioned earlier! Even if the LNS only recognizes the IP addresses it assigns, we can configure a source NAT function on the LAC to convert the source addresses of the packets from the branch organization accessing the HQ network into the VT interface's address―this is the Easy-IP method's "source NAT". After the LNS receives a return packet, and discovers the destination address is the LAC's VT interface's address, it will forward this by a direct route into the tunnel. In this way there is no need to configure a static route on the LNS.

I will next use a real network shown in Figure 1-5 as an example to briefly introduce the whole process for packet encapsulation and decapsulation when a branch organization user accesses the HQ server following configuration of source NAT on a LAC:

Figure 1-5 The LAC-auto-initiated VPN packet encapsulation process following configuration of source NAT on the LAC

[Dr.WoW] [No.28] L2TP LAC-Auto-initiated VPNs-1229993-5

 

1.         After the LAC receives an original packet from a branch organization user seeking access to the HQ server, it checks the route according to the destination address, selects our manually configured static route, and sends the packet to the VT interface.

2.         The LAC conducts NAT conversion on the original packet at the VT interface, converting the source address into the VT interface's address, and then encapsulates a PPP header, an L2TP header and a public network address onto the packet. The LAC then checks the route based upon the public network destination address, and sends the encapsulated packet to the LNS.

3.         After the LNS receives the packet, it strips away the PPP header and the L2TP header, and checks the route based upon the destination address (this is a directly connected route), and then sends the packet to the HQ server.

4.         After the LNS receives the return packet from the HQ server, it checks the route based upon the destination address, selects the route automatically issued by the LNS, and sends the packet to the VT interface.

5.         The packet is encapsulated with a PPP header, an L2TP header and a public network address at the VT interface. The LNS checks the route based upon the public network address, and sends the encapsulated packet to the LAC.

6.         After the LAC receives the packet, it strips away the PPP header and the L2TP header, converts the packet's destination address into the branch organization user's address, and then sends the packet to the branch organization user.

An example of configuring the Easy-IP method's source NAT on the LAC is given below (this example assumes the LAC's interface connecting to the branch organization network belongs to the Trust zone, and that the VT interface belongs to the DMZ zone):

[LAC] nat-policy interzone trust dmz outbound

[LAC-nat-policy-interzone-trust-dmz-outbound] policy 1

[LAC-nat-policy-interzone-trust-dmz-outbound-1] policy source 172.16.0.0 0.0.0.255

[LAC-nat-policy-interzone-trust-dmz-outbound-1] action source-nat

[LAC-nat-policy-interzone-trust-dmz-outbound-1] easy-ip Virtual-Template 1

2 Approach to Security Policy Configuration

The overall approach to security policy configuration in LAC-auto-initiated VPNs is basically the same as the configuration approaches introduced in the previous two sections, but we'll still discuss this briefly below.

In Figure 1-6 we assume that on the LAC and LNS GE0/0/1s are connected to the private network and belong to the Trust zone; GE0/0/2s are connected to the Internet, and belong to the Untrust zone; the VT interfaces belong to the DMZ zone.

Figure 1-6 Network security policy configuration in a LAC-auto-initiated VPN

[Dr.WoW] [No.28] L2TP LAC-Auto-initiated VPNs-1229993-6

 

The process for security policy configuration is as follows:

1.         We first configure the broadest possible interzone security policy to assist L2TP VPN adjustments/testing.

The LAC's interzone default packet filtering action is set to "permit":

[LAC] firewall packet-filter default permit all

The LNS's interzone default packet filtering action is set to "permit":

[LNS] firewall packet-filter default permit all

2.         After the LAC and LNS have successfully configured L2TP, a branch organization user pings the internal network server to initiate access, and the LAC and LNS's session tables are then checked.

?       LAC session table

[LAC] display firewall session table verbose

Current Total Sessions : 2

  l2tp  VPN:public --> public

  Zone: local--> untrust  TTL: 00:02:00  Left: 00:01:57

  Interface: GigabitEthernet0/0/2  NextHop: 1.1.1.2  MAC: 00-00-00-c5-48-00

  <--packets:38 bytes:2517   -->packets:62 bytes:4270

  1.1.1.1:60416-->1.1.1.2:1701

 

  icmp  VPN:public --> public

  Zone: trust--> dmz  TTL: 00:00:20  Left: 00:00:07

  Interface: Virtual-Template1  NextHop: 192.168.0.2  MAC: 00-00-00-c5-48-00

  <--packets:1 bytes:60   -->packets:1 bytes:60

  172.16.0.2:11749-->192.168.0.2:2048

***ysis of the session table provides the direction of packets on the LAC, as shown in Figure 1-7.

Figure 1-7 LAC packet direction

[Dr.WoW] [No.28] L2TP LAC-Auto-initiated VPNs-1229993-7

 

As shown above, the LAC needs to configure a Trust-->DMZ security policy to permit the branch organization user's packets seeking access to the internal server to pass; it also needs to configure a Local-->Untrust security policy to allow the LAC and the LNS to establish an L2TP tunnel.

?       LNS session table

[LNS] display firewall session table verbose

 Current Total Sessions : 2

  l2tp  VPN:public --> public

  Zone: untrust--> local  TTL: 00:02:00  Left: 00:01:52

  Interface: InLoopBack0  NextHop: 127.0.0.1  MAC: 00-00-00-00-00-00

  <--packets:18 bytes:987   -->packets:23 bytes:2057

  1.1.1.1:60416-->1.1.1.2:1701

 

  icmp  VPN:public --> public

  Zone: dmz--> trust  TTL: 00:00:20  Left: 00:00:00

  Interface: GigabitEthernet0/0/1  NextHop: 192.168.0.2  MAC: 54-89-98-62-32-60

  <--packets:4 bytes:336   -->packets:5 bytes:420

  172.16.0.2:52651-->192.168.0.2:2048

There are two sessions on the LNS: one L2TP session, and one ICMP session. ***ysis of the session table provides the LNS's packet direction, as shown in Figure 1-8.

Figure 1-8 LNS packet direction

[Dr.WoW] [No.28] L2TP LAC-Auto-initiated VPNs-1229993-8

 

 

From the above it is obvious that a DMZ-->Trust security policy needs to be configured on the LNS to permit branch organization users' packets seeking access to the internal network server to pass; an Untrust-->Local security policy also needs to be configured to permit the LAC and LNS to establish an L2TP tunnel.

After the L2TP tunnel is established, when the PC initiates a call on the server, the packet direction is the opposite of the direction when the server accesses the PC, and we do not need to elaborate further about this

To summarize, the security policies that should be configured on the LAC and LNS under various conditions are shown in Table 1-2, and we should configure the security policies that best match existing conditions.

Table 1-2 Selecting security policies for the LAC and LNS based upon existing conditions

Direction of Transaction

Device

Source Security Zone

Destination Security Zone

Source Address

Destination Address

Used in

PC seeks access to the server

LAC

Local

Untrust

1.1.1.1/32

1.1.1.2/32

L2TP

Trust

DMZ

172.16.0.0/24

192.168.0.0/24

*

LNS

Untrust

Local

1.1.1.1/32

1.1.1.2/32

L2TP

DMZ

Trust

172.16.0.0/24

192.168.0.0/24

*

Server seeks access to the PC

LAC

DMZ

Trust

192.168.0.0/24

172.16.0.0/24

*

LNS

Trust

DMZ

192.168.0.0/24

172.16.0.0/24

*

*: Use in this instance is related to the transaction type, and can be configured according to actual circumstances (for example: TCP, UDP, and ICMP).

 

Therefore, in L2TP scenarios using the LAC automatic dial-up method, the LAC and LNS's VT interfaces must be added to security zones, and the security zones the VT interfaces belong to determine the direction of the packet within the device. If a VT interface belongs to the Trust zone, then a DMZ-Trust interzone security policy does not need to be configured, but this will add additional security risk. Therefore, it is suggested that the VT interfaces be added to separate security zones, and that the most appropriate security policy be configured for them.

3.         Finally, the default packet filtering's action is set to "deny".

Set the LAC's interzone default packet filtering action to "deny":

[LAC] firewall packet-filter default deny all

Set the LNS's interzone default packet filtering action to "deny":

[LNS] firewall packet-filter default deny all

3 Summary

Over the past three sections I've introduced three kinds of L2TP VPNs, and we'll summarize these three kinds of L2TP VPNs in Table 1-3.

Table 1-3 Comparison of three kinds of L2TP VPNs

Item

Client-initiated VPN

NAS-initiated VPN

LAC-Auto-initiated VPN

Negotiation method

The L2TP client and the LNS negotiate the establishment of an L2TP tunnel and L2TP session, and establish a PPP connection.

The access user uses PPPoE dial-up to trigger the establishment of an L2TP tunnel and L2TP session between the LAC and LNS, and the access user and LNS negotiate the establishment of a PPP connection.

The LAC initiates dialing, and negotiates the establishment of an L2TP tunnel and L2TP session and of a PPP connection with the LNS.

Tunnel and session relationship

One L2TP tunnel is established between every L2TP client and LNS, and each tunnel only carries one L2TP session and PPP connection.

Multiple L2TP tunnels can exist between a LAC and a LNS, and one L2TP tunnel can carry multiple L2TP sessions.

A permanent L2TP tunnel is established between the LAC and LNS, which only carries one permanent L2TP session and PPP connection.

Security

The LNS conducts PPP authentication of the L2TP client (PAP or CHAP); this method offers relatively high security.

The LAC authenticates access users, and then the LNS conducts secondary authentication (optional) of access users; this offers the highest in security.

The LAC does not conduct authentication of users; the LNS conducts PPP authentication (PAP or CHAP) of LAC configured users. This provides low security.

Return route

The LNS will automatically issue a UNR route, guiding the return packet into the L2TP tunnel; manual configuration is not required.

The LNS will automatically issue a UNR route, guiding the return packet into the L2TP tunnel; manual configuration is not required.

It is necessary to manually configure the LNS so that the destination address is the network segment's static route, or configure the easy-IP method's source NAT for the LAC.

IP address assignment

The LNS assigns an IP address for the client.

The LNS assigns an IP address for the client.

The LNS assigns an IP address for the LAC's VT interface.

 

Our look at L2TP VPNs has ended. It is important to note that none of the L2TP VPN methods supports encryption functions, and therefore security risks are present during the process of data transmission through the tunnel. How can this problem be resolved? The answer to this will be clear after we've studied the functionally powerful, hard-to-configure, and highly secure IPSec VPNs.

 

 

 

Questions from Dr. WoW:

1.         Are a GRE packet's outer layer IP header's source address and destination address the same as its tunnel interface's IP address?

2.         For L2TP VPNs, what is the primary difference between the scenarios for which NAS-initiated VPNs and Client-initiated VPNs should be used?

3.         For L2TP client-initiated VPNs, it is generally advised that the address pool's addresses and the HQ network's address be assigned to different network segments. If we want to configure the address pool's addresses and the HQ network address in the same network segment, what do we need to do?

4.         In L2TP client-initiated VPNs, how does the LNS ensure that return packets from HQ's internal server are able to enter the L2TP tunnel and return to the L2TP client?

5.    In L2TP NAS-initiated VPNs, which methods does the LNS have to authenticate access users?

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

user_2790689
Created Jul 14, 2015 03:40:39 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login