March 13, 2011, 8:16 p.m.
posted by ansi
Designing and Implementing L2TP Compulsory/NAS-Initiated Tunnel Mode Remote Access VPNs
As discussed at the beginning of this chapter, there are two modes of operation with L2TP: voluntary/client-initiated tunnel mode and compulsory/NAS-initiated tunnel mode. Up to this point in the chapter, the focus has been on voluntary tunnel mode; this section examines compulsory tunnel mode.
Figure depicts compulsory tunnel mode L2TP.
Compulsory Tunnel Mode L2TP
As shown in Figure, PPP connections (PPP over ATM [PPPoA] or PPP over Ethernet [PPPoE]) from users are transported via a DSL Access Multiplexor (DSLAM) and aggregation router over an L2TP tunnel to the a tunnel termination device (the VPN gateway). In Figure, the aggregation router functions as the LAC, and the tunnel termination device functions as the LNS. It is also possible that a DSLAM could function as a LAC.
Although Figure shows the tunneling of PPP connections via a DSLAM and aggregation router (LAC) to an LNS, it does not really matter how PPP frames arrive at the LAC for tunneling to the LNSthey could arrive, for example, via analogue dialup lines, via ISDN lines, or they could as already discussed arrive via a DSLAM.
Figure shows the operation of L2TP compulsory tunnel mode (when a remote access client initiates connectivity).
Operation of L2TP Compulsory Tunnel Mode
If you compare Figure with Figure on page 717, you can see that the operation of L2TP compulsory tunnel mode differs a little from the operation of L2TP voluntary tunnel mode.
As shown in Figure, when a remote access client connects to the LAC, the remote access client and the LAC negotiate LCP. In addition, partial PPP authentication is performed.
During partial PPP authentication, the LAC obtains the username of the remote access client and uses the username (or part of the username) to assign the PPP connection to the correct L2TP tunnel (there may be more than one).
At this point, if the L2TP tunnel has not already been established, the LAC will complete L2TP tunnel setup with the LNS. The LAC initiates L2TP tunnel setup by sending an SCCRQ message to the LNS (see Figure on page 716), the LNS replies with an SCCRP, and the LAC completes tunnel setup by sending an SCCCN.
After the L2TP tunnel has been established, the LAC and LNS will negotiate L2TP session setup. The LAC begins L2TP session establishment by sending an ICRP to the LNS. The LNS replies with an ICRP, and session setup is complete when the LAC sends an ICCN.
The LNS and the remote access client now complete PPP negotiation by completing PPP authentication and NCP negotiation. Note that it is also possible for the LNS to reinitiate LCP negotiation and authentication with the remote access client (rather than just completing the process).
L2TP Compulsory Tunnel Mode Setup: LAC Perspective
Figure shows L2TP compulsory tunnel mode setup from the LAC perspective.
L2TP Compulsory Tunnel Mode Setup from the LAC Perspective
In highlighted lines 1 and 2, the PPP phase changes to ESTABLISHING, and LCP state changes to Listen. LCP negotiation is about to begin. The LCP state changes to Open in highlighted line 3LCP negotiation has been completed. Next, in highlighted line 4, the PPP phase changes to AUTHENTICATING(partial) PPP authentication is about to begin.
Highlighted line 5 and 6 show an outgoing CHAP challenge message (from the LAC to the remote access client) and an incoming CHAP Response message (from the remote access client to the LAC). You will notice, however, the absence of either a CHAP Success or Failure messagethese messages are used to complete CHAP authentication. So, CHAP authentication is partial between the LAC and the remote access client.
The remote access client's username is included in the CHAP Response message shown in highlighted line 6, and this is used by the LAC to associate this PPP connection with an L2TP tunnel to the LNS, mjlnet.London.LNS.01.
Because there is no existing L2TP tunnel between the LAC (mjlnet.brux.lac) and the LNS (mjlnet.london.lns), the LAC begins L2TP tunnel establishment by sending an SCCRQ to the LNS (highlighted line 7).
The LNS then replies with an SCCRP in highlighted line 8. In highlighted line 9, the LAC responds with an SCCCN, and the tunnel is established. The LAC now begins L2TP session establishment by sending an ICRQ (see highlighted line 10). The LNS replies to the ICRQ with an ICRP (not shown in the debug output), and finally, the LAC finishes L2TP session setup by sending an ICCN to the LNS (highlighted line 11).
L2TP Compulsory Tunnel Mode Setup: LNS Perspective
Figure shows L2TP tunnel setup and PPP negotiation from the LNS perspective.
L2TP Compulsory Tunnel Mode Setup from the LNS Perspective
Highlighted lines 1 to 3 show the exchange of SCCRQ, SCCRP, and SCCCN messages used to establish the L2TP tunnel between the LAC and the LNS.
In highlighted line 4 to 6, you can see the ICRQ, ICRP, and ICCN messages that set up the L2TP session.
Now that the L2TP session has been set up, the LNS can begin PPP negotiation with the remote access client (see highlighted line 7).
In highlighted line 8 and 9, the LNS processes LCP messages passed from the LAC during L2TP session setup (remember that the LAC negotiates LCP with the remote access client).
Highlighted line 10 shows that PPP authentication is about to begin, and in highlighted line 11, the LNS sends a CHAP Success message to the remote access client. The LAC also passed authentication information to the LAC during L2TP session setup, and so the LNS now only needs to send either a CHAP Success or Failure message to the remote access client depending on whether authentication was successful.
As soon as the LNS has authenticated the remote access client, it begins NCP (in this case IPCP) negotiation by sending an IPCP Configure-Request (CONFREQ, see highlighted line 12).
The IPCP state changes to Open in highlighted line 13, and IPCP negotiation is complete. The L2TP tunnel (and session) has been set up between the LAC and the LNS, and PPP negotiation has been completed between the LNS and the remote access client.
Configuring the LAC for Compulsory Tunnel Mode
The configuration of the LAC consists of the following steps:
Figure shows a sample configuration of a LAC when using compulsory tunnel mode.
Sample Configuration of a LAC When Using Compulsory Tunnel Mode
The vpdn search-order domain command (line 2) then configures the LAC to attempt to associate the remote access clients' PPP connections to an L2TP tunnel using the domain name contained in the username of the remote access client (specified by the remote user using the syntax [email protected]_name, and communicated to the LAC during PPP authentication).
The next step is to configure the VPDN group (Step 3). Line 3 shows the vpdn-group name command, which configures the VPDN group name. A VPDN group is used to collect together the configuration for a particular VPN/VPDN. It is worth noting that the VPDN group name is locally significant on the LAC.
The first command configured under the VPDN group is (in this case) request-dialin (line 4). This command is used to configure the LAC to initiate L2TP tunnel/session establishment with the LNS on reception of PPP connections from remote access clients.
Next is the protocol l2tp command is used to configure L2TP as the tunneling protocol (line 5).
In line 6, the domain domain_name command is used to match the domain name in the username of the remote access user ([email protected]_name).
Line 7 contains the initiate-to ip ip-address command. This command configures the IP address of the LNS (the L2TP tunnel endpoint).
The l2tp authentication password password command (line 8) is used to configure the L2TP tunnel password, which is used by the LAC to authenticate the LNS and vice versa (during tunnel setup).
Lines 9 and 10 show the configuration of the interface that provides connectivity to the LNS (via intervening networks).
In this example, the access connectivity to remote access clients is provided via a Primary Rate ISDN line (clients connect over the PRI to digital MICA modems in the LAC).
Lines 11 and 12 show the configuration of the E1 controller. The pri-groups timeslots timeslot-range command in line 12 specifies timeslots 1 to 31.
The encapsulation ppp command (line 15) is used, unsurprisingly, to configure PPP encapsulation on the line.
Line 16 shows the isdn switch-type switch-type, used to configure the ISDN switch type.
The isdn incoming-voice modem command (line 17) configures the LAC to switch asynchronous calls received on the PRI to the internal MICA modems.
The no peer default ip address command (line 18) ensures that the LAC does not assign an IP address to any remote access clients whose calls are received on the PRI. This command makes sense because IP addresses are assigned (if at all) during IPCP negotiation, and IPCP is not negotiated between the remote access clients and the LAC (it is instead negotiated between the remote access clients and the LNS).
Line 19 contains the ppp authentication chap command. This command configures the LAC to use CHAP authentication with the remote access clients.
Lines 20 to 26 show the configuration of the asynchronous interfaces. These interfaces are configured together in a group (thus ensuring consistency).
The encapsulation ppp command (line 21) again configures PPP encapsulation.
Line 22 shows the async mode interactive command. This configures allows users to initiate interactive mode on the lines.
The no peer default ip address command (line 23) again ensures that the LAC does not assign IP addresses to the remote access clients.
The group-range interface-range-start interface-range-finish command in line 24 then applies the configuration under interface Group-Async1 to the MICA modem lines.
In lines 25 to 28, you can see the configuration of the asynchronous lines.
The modem InOut command (line 26) ensures that the modems on the specified lines are able to both receive and make calls.
In line 27, the modem autoconfigure type mica command automatically configures the modems as type MICA.
Line 28 contains the autoselect ppp command ensures that the LAC can auto-detect PPP encapsulation on the modem lines.
Configuring Tunnel Definitions on a RADIUS Server
Although the configuration shown in Figure functions perfectly well, it is also common to store the VPDN/VPN configuration (configured under the VPDN group in Figure) on a RADIUS server in the form of a tunnel definition.
Figure shows the most relevant IETF standard tunnel attributes.
If you want to store tunnel configuration on a RADIUS server, you can remove the VPDN group configuration (no vpdn-group name) from the LAC and instead specify the commands shown in Figure.
AAA Configuration on the LAC
The aaa new-model command enables AAA on the LAC.
The aaa authentication ppp default group radius command is used to enable authentication for PPP using a RADIUS server (as specified using the default method list).
The aaa authorization network default group radius command configures the LAC to use a RADIUS server to authorize network connections. Again, the default method list is specified.
The radius server host command specifies the IP address or DNS name of the RADIUS server, the UDP ports used for authentication (auth-port) and accounting (acct-port) requests, and the key used to authenticate communications used between the LAC and the RADIUS server.
Figure shows the configuration of IETF tunnel attributes on Cisco Secure ACS.
Configuration of IETF Tunnel Attributes on Cisco Secure ACS
Figure shows the equivalent configuration of IETF tunnel attributes on a Merit RADIUS server.
Configuration of IETF Tunnel Attributes on a Merit RADIUS Server
Figure shows the configuration of Cisco AV-pairs on Cisco Secure ACS.
Configuration of Cisco AV-Pairs Tunnel Attributes on Cisco Secure ACS
In Figure, you can see the equivalent configuration of Cisco AV-pair tunnel attributes on a Merit RADIUS server.
Configuration of Cisco AV-Pair Tunnel Attributes on a Merit RADIUS Server
Configuring the LNS for Compulsory Tunnel Mode
Configuration of the LNS consists of the following steps:
Figure shows a sample configuration of an LNS when using compulsory tunnel mode.
Sample Configuration of an LNS When Using Compulsory Tunnel Mode
Some of the commands configured on the LNS are the same as those configured on the LAC. These commands will not be reexamined heresee the descriptions of these commands earlier in this chapter for more information.
Lines 1 and 2 show the configuration of a local username/password database using the username username password password command. These usernames and passwords are used to authenticate remote access user during PPP negotiation.
The accept-dialin command (line 3) under the VPDN group is used to configure the LNS to accept L2TP tunnel and session setup initiated by the LAC. This command is the counterpart of the request-dialin command on the LAC.
Line 4 shows the virtual-template template-number command used to configure the virtual template from which virtual access interfaces will be cloned. These virtual access interfaces are used to terminate PPP connections that are tunneled from the remote access clients via the LAC to the LNS (one virtual access interface per PPP connection).
Next, the terminate-from hostname hostname command in line 5 is used to specify the hostname of the LAC from which L2TP tunnel and session setup will be accepted.
In lines 6 and 7, the async-bootp dns-server address and async-bootp nbns-server address commands are used to configure DNS server and NetBIOS Name Server (WINS server) addresses that are supplied to the remote access client during PPP (IPCP) negotiation.
Lines 8 and 9 show the configuration of the interface that provides connectivity (via intervening networks) to the LAC, and line 10 and 11 show the configuration an internal interface.
The virtual template interface is configured in lines 12 to 15. This is the virtual template referenced in the VPDN group using the virtual-template command (see line 4).
The ip unnumbered interface command (line 13) configures the virtual template to "borrow" the IP address from interface fast Ethernet 1/1.
Line 14 shows the peer default ip address pool pool-name command. This command is used to link to the pool of IP addresses from which an IP address will be assigned to the remote access clients during PPP (IPCP) negotiation.
Theppp authentication chap command (line 15) configures the LNS to use CHAP to authenticate remote access clients.
In line 16, the ip local pool pool-name command configures the IP address pool from which IP addresses are assigned to remote access clients. This is the pool referenced using the peer default ip address pool command in line 14.
The sample configuration shown in Figure includes the configuration of a local username/password database that is used for remote access user authentication. Although a local database works well for a small number of users, it does not scale well. It is common, therefore, to use a AAA server (often a RADIUS server) for user authentication.
If you want to use a RADIUS server for user authentication, you can remove any local username and passwords for remote access users from your LNS configuration and instead configure the commands shown in Figure on the LNS.
Configuration for User Authentication Using a RADIUS Server
You will notice that these commands are the same as those configured on the LAC in Figure (the only difference is the IP address of the RADIUS server), and so they are not explained again here. See the explanation of these commands earlier in chapter for more information.
When configuring user accounts on the RADIUS server, make sure that the Service-Type (attribute type 6) is specified as Framed, and the Framed-Protocol (attribute type 7) is specified as PPP. These attributes can be configured under the group to which the user is assigned if you are using a Cisco Secure ACS.
It is also possible to store per-user interface configuration in the form of virtual profiles on a RADIUS. In this case, only the most generic configuration remains on the virtual template interface, and per-user (or per-group) configuration is configured on the RADIUS server.
Per-user interface configuration can be stored on the RADIUS server in the form cisco-avpair = "lcp:interface-config=".
Figure shows the configuration of per-user (group) interface commands on a Cisco Secure ACS. These commands can be configured under group setup.
Configuration of Per-User (Group) Interface Commands on a Cisco Secure ACS
As you can see in Figure, the commands ip unnumbered loopback100 and peer default ip address pool vpn1_pool are configured within the group setup. When a user that belongs to the group in question connects to the LNS, this configuration is downloaded and applied to the virtual access interface (in addition to any configuration configured on the virtual template).
Figure shows an equivalent configuration of per-user interface configuration on a Merit RADIUS server.
Configuration of Per-User Interface Configuration on a Merit RADIUS Server
One thing to notice in Figure is \n in lcp:interface-config=ip unnumbered loopback100\npeer default ip address pool vpn1_pool. \n is simply used to indicate the beginning of a new command line.
Now, if per-user configuration is stored on the RADIUS server, you can remove the corresponding configuration on the LNS. This means that the ip unnumbered and peer default ip address pool commands can be removed from the configuration shown in Figure if the per-user interface configuration is stored on the RADIUS server as shown in Figure/Figure. Figure shows the resulting virtual template interface configuration.
Resulting Virtual Template Interface Configuration When Storing Per-User Configuration on the RADIUS Server
The debug vtemplate (cloning) command can be used to examine the cloning of virtual access interfaces from the virtual template when remote access users connect to the LNS.
Figure shows the output of the debug vtemplate cloning command when using the per-user interface configuration on a RADIUS server. Note that only the relevant portion of the output is shown.
Figure. debug vtemplate cloning Command Output When Using Per-User Interface Configuration
Line 2 shows that the LNS is now cloning configuration from the virtual template and from the AAA (RADIUS) server.
In line 3, the LNS begins to clone per-user interface configuration that it has received from the RADIUS server.
The two per-user interface configuration commands configured on the RADIUS server are applied to the virtual access interface in lines 4 and 5.
Finally, in line 6, the line protocol on virtual access 2 changes state to up. The remote access user has completed PPP negotiation with the LNS.
To ensure that per-user interface configuration is downloaded from the RADIUS server and applied to the virtual access interface, only the configuration shown in Figure is required in newer versions of Cisco IOS Software. In older versions of Cisco IOS Software, the virtual-profile aaa command is also required.