[Dr.WoW] [No.27] L2TP NAS-initiated VPNs

Latest reply: May 19, 2018 01:32:16 4354 3 1 1
In the above section we discussed how client-initiated VPNs can allow companies' mobile employees to pass through the "worm hole", just like Professor Du, and freely access the HQ network. However, company branch organization users are not as fortunate, and they generally use a dial-up network to connect to the Internet. Faced with the vast ocean of the Internet, and unable to find the entrance to the "worm hole", they can only look at this ocean and sigh sadly. Even if their dial-up network has evolved onto the Ethernet, this only solves the local Internet connection problem, but they are still unable to access the HQ network. Does this mean branch organization users are destined to be forever separated from the HQ network?

Fortunately, the arrival of LACs onto the network scene has helped branch organizations solve this problem. The LAC serves as a PPPoE server, and a branch organization user, as the PPPoE client, can establish a PPPoE connection with the LAC, allowing PPP to be used freely on the Ethernet. Additionally, as an "agent" for the LNS, the LAC provides a "worm hole" entrance for branch organizations, meaning that branch organization users can use the LAC as a portal to reaching the HQ network.

The LAC is also called the NAS on VPDNs, and so these kinds of L2TP VPNs are also called NAS-initiated VPNs. This would be easier to understand if the name "NAS-initiated VPN" was changed to "LAC-initiated VPN", because on our representations of network organization the name LAC is clearly displayed, but we still have to use this now-discarded "former name", which might be a bit confusing to newcomers.

The process of constructing a NAS-initiated VPN is a bit complicated, and to aid in remembering this I have drawn a simple figure (Figure 1-1), to aid in your understanding of the following.

Figure 1-1 Process for establishing a NAS-initiated VPN

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-1

 

In order to review our understanding of PPPoE, we've used a firewall as the PPPoE client, while a virtual PC's PPPoE client is shown in Figure 1-2.

Figure 1-2 NAS-initiated VPN network schematic

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-2

 

A key point to remember is that the connections between the PPPoE client, the LAC, the LNS, and the internal server are direct connections, eliminating the need to configure routing; user authentication also uses local authentication, which is relatively simple. In addition, the internal server needs to configure a gateway to ensure that the packets it gives the PPPoE client in response are able to be sent to the LNS.

1 Step 1: Establishing a PPPoE Connection―The Dialing Interface Dials the VT Interface

After PPP changed to PPPoE so that it could settle down in the Ethernet "world", in order to simulate the PPP dial-up process on the Ethernet, PPPoE invented two virtual interfaces―the dialer interface and the VT interface. When PPPoE runs on a firewall, these two interfaces are also used: when a firewall serves as the PPPoE client it uses the dialer interface, and when a firewall serves as the PPPoE server it uses the VT interface. Related PPPoE parameters are configured on these two interfaces, as shown in Table 1-1.

Table 1-1 Configuring an NAS-initiated VPN's PPPoE

PPPoE Client

PPPoE Server (LAC)

interface dialer 1

dialer user user1

dialer-group 1

dialer bundle 1

ip address ppp-negotiate  //Configures the negotiation mode, so that IP addresses are dynamically assigned.

ppp chap user user1  //Indicates the PPPoE client's user name.

ppp chap password cipher Password1   //Indicates the PPPoE client's password.

dialer-rule 1 ip permit

interface GigabitEthernet0/0/1

pppoe-client dial-bundle-number 1  //Enables the PPPoE client on the physical interface and binds dial-bundle.

interface Virtual-Template 1

ppp authentication-mode chap

interface GigabitEthernet 0/0/1

pppoe-server bind virtual-template 1        //Enables the PPPoE server on the physical interface and binds the VT interface.

aaa

local-user user1 password Password1

 local-user user1 service-type ppp

 

 

The VT interface on the PPPoE server (LAC) only completes PPPoE work, providing PPP authentication functions for the PPPoE server, but doesn't contain a function for cooperation with L2TP.

In L2TP, all user IP addresses are uniformly assigned by HQ (the LNS or AAA server), so there is no need to configure an address pool on the LAC (even if an address pool is configured, so long as the L2TP tunnel has already been established, the HQ address pool will be preferentially used for address assignment), but ordinary PPPoE dialing needs an address pool to be configured on the PPPoE server.

We can use the below packet capture to ***yze the process of establishing a PPPoE connection.

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-3 

The negotiation process in the PPPoE discovery step is quite important. As shown in Table 1-2, the PPPoE client and PPPoE server exchange PADI, PADO, PADR and PADS packets to confirm each other's Ethernet address and PPPoE session ID.

Table 1-2 Negotiation process in the PPPoE discovery stage

Step 1

PADI

PPPoE Client: Attention, attention, I want to connect to PPPoE, who will come help me?

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-4

Step 2

PADO

PPPoE Server: PPPoE client, look for me, I'll help you!

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-5

Step 3

PADR

PPPoE Client: That's great PPPoE Server! I'd like to establish a PPPoE session with you.

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-6

Step 4

PADS

PPPoE Server: Fine. I'll send the session ID to you, and we can simply use this ID to establish a PPPoE session.

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-7

 

Then, following PPP LCP negotiation and PPP CHAP authentication, the PPPoE connection is established.

2 Step 2: Establishing the L2TP Tunnel― Three Pieces of Information to Negotiate Entrance to the Worm hole

Let's first look at the specific configuration of the LAC and LNS, as shown in Table 1-3.

Table 1-3 Configuring the NAS-initiated VPN's L2TP

LAC

LNS

l2tp enable

l2tp-group 1

 tunnel authentication   //Avoids counterfeit LACs from connecting to the LNS.

tunnel password cipher Password1

 tunnel name lac

 start l2tp ip 1.1.1.2 fullusername user1  //Designates the address of the other tunnel terminal.

l2tp enable

interface Virtual-Template 1

ppp authentication-mode chap

ip address 172.16.0.1 255.255.255.0

remote address pool 1

l2tp-group 1

tunnel authentication  //Avoids counterfeit LACs from connecting to the LNS.

 tunnel password cipher Password1

 allow l2tp virtual-template 1 remote lac  //Designates the VT interface and allows a remote LAC connection.

aaa

local-user user1 password Password1

local-user user1 service-type ppp

ip pool 1 172.16.0.2 172.16.0.100

 

 

The LAC and the LNS exchange three pieces of information in negotiating the L2TP tunnel. We've already covered this process in "5.4 L2TP Client-initiated VPNs", and we'll review this again here. See the packet capture information below:

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-8

The tunnel ID negotiation process is shown in Table 1-4.

Table 1-4 Tunnel ID negotiation process

Step 1

SCCRQ

LAC: LNS, use "1" as the Tunnel ID to communicate with me.

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-9

Step 2

SCCRP

LNS: OK. LAC, make sure you also use "1" as your tunnel ID to communicate with me.

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-10

Step 3

SCCCN

LAC: OK.

-

 
 

 

3 Step 3 Establishing an L2TP Session―Three Pieces of Information to Awaken the Worm hole Gatekeeper

The LAC and the LNS exchange three pieces of information to negotiate a session ID and establish an L2TP session. We'll likewise review this process again. See the packet capture information below:

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-11

 

Table 1-5 gives the session ID negotiation process.

Table 1-5 Session ID Negotiation Process

Step 1

ICRQ

LAC: LNS, use "4" as the session ID to communicate with me.

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-12

Step 2

ICRP

LNS: OK, LAC, and make sure you also use "4" as the session ID to communicate with me.

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-13

Step 3

ICCN

LAC: OK.

-

 

4 Steps 4-5: LNS Authentication and IP Address Assignment―the LNS Sternly Accepts the LAC

1.         LNS authentication and secondary authentication (optional)

The LAC sends user information to the LNS for authentication. However, the LNS understands all too well that the LAC is only an "agent", and the LNS can adopt one of three attitudes towards this:

?       LAC agent authentication: the LNS doesn't trust that the LAC is trustworthy, and directly carries out authentication of the user information sent by the LAC.

?       Enforce mandatory CHAP authentication: the LNS doesn't trust the LAC, and requires that a "qualification inspection" be carried out anew of the user (enforce new CHAP authentication of the user).

?       LCP re-negotiation: the LNS not only doesn't trust the LAC, but also expresses its dissatisfaction with the aforesaid "service contract" that was signed, and requires the user to again 'negotiate services' (re-initiate LCP negotiation, and negotiate MRU parameters and authentication methods).

The latter two methods are together called LNS secondary authentication. If the LNS is configured for secondary authentication but the PPPoE client does not support secondary authentication, this means the L2TP VPN cannot be established. The common point between these two secondary authentications is that the LNS skirts around the LAC and carries out direct verification of the user information provided by the PPPoE client, providing increased security protections for VPN services. Configuration methods for the three kinds of authentication methods are shown in Table 1-6.

Table 1-6 Configuring a NAS-initiated VPN's LNS authentication

Authentication Method

Configuration Method

Packet Capture Analysis

LAC proxy authentication

Default, don't need to configure

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-14

The LNS directly authenticates the user information sent by the LAC, and if authentication is successful a PPP connection is established.

Mandatory CHAP authentication

★★

l2tp-group 1

 mandatory-chap

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-15

The LNS re-conducts CHAP authentication of the user. The LNS sends a challenge, the PPPoE client uses the challenge to send the user name and encrypted password to the LNS, and after the LNS authenticates this, a PPP connection is successfully established.

LCP re-negotiation

★★★

interface virtual-template 1

ppp authentication-mode chap // designates authentication mode after re-negotiation

l2tp-group 1

 mandatory-lcp

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-16

The LNS re-initiates LCP negotiation, negotiates MRU parameters and an authentication method, and then conducts CHAP authentication. After successful negotiation, a PPP connection is established.

Represents degree of excellence; configuring LCP re-negotiation is the most preferable of these three methods.

 

 

 

 

 

 

2.   IP address assignment

The LNS assigns an IP address for the PPPoE client through PPP IPCP negotiation.

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-17

 

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-18

 

We went over the address pool's address planning problem in section "Client-initiated VPNs", and you can go back and review this if you wish.

Let's summarize the characteristics of NAS-initiated VPNs:

As shown in Figure 1-3, in NAS-initiated VPNs, multiple tunnels can be established between a LNS-LAC pair (one is built for every L2TP group), and every tunnel can carry multiple sessions. This means that each LAC can carry sessions for all dial-up users of the branch organization it belongs to. For example, PPP connection 1 and L2TP session 1 are established between access user 1 and the LNS, and PPP connection 2 and L2TP session 2 are established between access user 2 and the LNS. When a user dials-in, this triggers establishment of a tunnel between the LAC and the LNS. So long as this user doesn't go offline, when other users dial-in, they will establish sessions in the existing tunnel rather than re-triggering tunnel establishment.

Figure 1-3 Relationship between an L2TP tunnel and session with the PPP connection on a NAS-initiated VPN

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-19

 

5 Step 6: Data Encapsulation Transmission― Obstacle-Free Communication

After the PPPoE client packets bound for the HQ server reach the LAC, the LAC gives the packets three layers of "alter-egos", these being the L2TP header, the UDP header and the public network IP header, and then sends these to the LNS. After the LNS receives the packets, it strips off these three layers of "alter-egos", and then forwards the packet to the internal server.

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-20

 

Figure 1-4 shows the process of packet encapsulation and decapsulation in a NAS-initiated VPN scenario.

Figure 1-4 NAS-initiated VPN packet encapsulation process

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-21

 

As with client-initiated VPNs, in NAS-initiated VPN scenarios, the LNS will also automatically issue a host route (UNR route) for the PPPoE client that obtained the private network IP address, and use this to guide return packets from the internal server bound for the PPPoE client into the tunnel.

6 Approach to Security Policy Configuration

NAS-initiated VPN security policy configuration is a bit more troublesome than for client-initiated VPNs because both the LAC and the LNS need to be configured. However, the approach to configuration is similar.

As shown in Figure 1-5, in our hypothetical scenario, the LAC's GE0/0/2 is connected to the Internet, and belongs to the Untrust zone. On the LNS, GE0/0/1 is connected to the private network, and belongs to the Trust zone; GE0/0/2 is connected to the Internet, and belongs to the Untrust zone; the VT interface belongs to the DMZ zone; the IP address assigned by the LNS for the PPPoE client is 172.16.0.2.

Figure 1-5 Network organization for VPN security policy configuration in a NAS-initiated VPN

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-22

 

The security policy configuration process is as follows:

1.         We first configure the interzone security policy to be as broad as possible, to aid in L2TP VPN adjustment/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 also set to "permit":

[LNS] firewall packet-filter default permit all

2.         After both the LAC and LNS have configured L2TP, we ping the internal server with the PPPoE client, and then look at both the LAC and LNS session tables.

?       LAC session table

[LAC] display firewall session table verbose

 Current Total Sessions : 1

  l2tp  VPN:public --> public

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

  Interface: GigabitEthernet0/0/2  NextHop: 1.1.1.2  MAC: 00-00-00-53-62-00

  <--packets:26 bytes:1655   -->packets:11 bytes:900

  1.1.1.1:60416-->1.1.1.2:1701

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

Figure 1-6 LAC packet direction

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-23

 

There is no ICMP session on the LAC, just the one L2TP session. Therefore, a Local-->Untrust security policy needs to be configured on the LAC permitting the LAC and LNS to build an L2TP tunnel. Moreover, the PPPoE client's packets accessing the internal server will first be encapsulated into PPPoE packets, then be directly encapsulated into L2TP packets when the LAC receives the PPPoE packet, and finally enter the L2TP tunnel, and so these are not controlled by the security policy. Therefore, only a Local-->Untrust security policy needs to be configured on the LAC.

?       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 direction of packets on the LNS, as shown in Figure 1-7.

Figure 1-7 LNS packet direction

[Dr.WoW] [No.27] L2TP NAS-initiated VPNs-1337999-24

 

The above figure shows that a DMZ-->Trust security policy needs to be configured on the LNS permitting PPPoE client packets seeking access to the internal server to pass; an Untrust-->Local security policy permitting the LAC and LNS to build an L2TP tunnel also needs to be configured.

After the L2TP tunnel is established, when the internal server initiates a call on the PPPoE client, the packet direction is the opposite of when the PPPoE client accesses the server, and there is no need to further elaborate on this.

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

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

Direction of Transaction

Device

Source Security Zone

Destination Security Zone

Source Address

Destination Address

Used in

PPPoE client accesses the server

LAC

Local

Untrust

1.1.1.1/32

1.1.1.2/32

L2TP

LNS

Untrust

Local

1.1.1.1/32

1.1.1.2/32

L2TP

DMZ

Trust

172.16.0.2~172.16.0.100

address pool addresses

192.168.0.0/24

*

Server accesses the PPPoE client

LNS

Trust

DMZ

192.168.0.0/24

172.16.0.2~172.16.0.100

address pool addresses

*

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

 

 

NOTE

In this scenario, the LNS only passively accepts the LAC's request to establish the tunnel, but will not actively initiate a request to the LAC to establish the tunnel, so only an Untrust-->Local security policy needs to be configured on the LNS for the L2TP tunnel.

Therefore, in L2TP VPNs using the NAS-initiated method, the LNS's VT interface must be added to a security zone, and the security zone the VT interface belongs to determines the packet's direction within the device. If the VT interface belongs to the Trust zone, a DMZ-Trust interzone security policy doesn't need to be configured, but this will also carry with it additional security risks. Therefore, it is advisable to add the VT interface to a separate security zone, and then configure the most appropriate security policy.

3.         Finally, the default packet filtering's action is changed 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

In NAS-initiated VPNs, the branch organization user must dial-in before using the L2TP VPN, and packets also need to be encapsulated into PPPoE, which is too much trouble. Moreover, dial-up networks are gradually disappearing, and Ethernet is becoming mainstream―does this mean that branch organization users cannot access the HQ network directly on the Ethernet? Of course they can. Mankind's desire to reduce work is the real driver of advances in science and technology, and in the next section I'll introduce LAC-auto-initiated VPNs to everyone, in which the LAC automatically dials the LNS, eliminating the dial-up process for branch organization employees―this is known as being the L2TP VPN that involves the least work.

 

 

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

  • x
  • convention:

user_2790689
Created Jul 7, 2015 00:36:18 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

user_2890713
Created Sep 13, 2017 10:57:24 Helpful(0) Helpful(0)

Finally I found a great post with interesting topic. I read every points of this post that is really so enjoyable and I have bookmark your site for get back again here. gmail account login | gmail email login | hotmail.com login
:):):):) 本帖最后由 user_2890713 于 2017-09-13 10:58 编辑
  • x
  • convention:

w1
Created May 19, 2018 01:32:16 Helpful(0) Helpful(0)

:):)
  • 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