Chapter 12. AAA of VPN and PPP Sessions on IOS

Telecommuting has become a very important part of an organization today and the Internet provides the perfect medium for it. With all the benefits associated, there is also a huge security risk involved. Almost anyone with an Internet connection can try to connect to your network. To minimize the risks associated, it is very important to authenticate, authorize, and monitor users connecting to your network remotely.

This chapter discusses authentication, authorization, and accounting (AAA) on IOS in relation to different types of remote access virtual private network (VPN) methods and Point-to-Point Protocol (PPP).

Authenticating VPN Sessions

The two most commonly used Remote Access VPN methods are IPsec (also known as Easy VPN Remote or EzVPN Remote) and Secure Sockets Layer (SSL) VPNs. This section discusses how to configure authentication with each of these VPN methods. You should have some knowledge about the operation and configuration of these VPN technologies before beginning with this section. The VPN configuration shown in this section is minimal.

Authenticating IPsec Remote Access Sessions

IPsec is one of the most widely used methods for connecting to a VPN. It uses Internet Key Exchange (IKE) to handle negotiation of protocols and algorithms based on local policy and to generate the encryption and authentication keys to be used by IPsec. IKE has two phases of key negotiation:

• Phase 1: Phase 1 negotiates a security association (a key) between two IKE peers. The key negotiated in Phase 1 enables IKE peers to communicate securely in Phase 2.

• Phase 2: During Phase 2 negotiation, IKE establishes keys (security associations) for other applications, such as IPsec.

The IKE standard does not provide for user authentication. It provides only for authentication of the device. The most common implementation is using a preshared key for group authentication. As you might have realized, this raises a huge security risk. If a machine with the VPN group password saved in a profile is compromised or stolen, a malicious user can connect to the network without requiring any user authentication.

To overcome this, the IETF has developed a draft RFC for IKE Extended Authentication (Xauth). The Xauth feature is an enhancement to the existing IKE protocol feature, which allows Cisco IOS Software to perform user authentication using AAA authentication methods. The user authentication is performed after IKE phase 1 and before IKE phase 2. It is commonly referred to as phase 1.5.

Xauth uses a Request/Reply mechanism to get the credentials from the user when the VPN gateway is configured to require user authentication. It then passes the credentials to the AAA mechanism of IOS. Usually, RADIUS is used to authenticate the user with the AAA server. Figure 12-1 shows the steps involved with Xauth.

Figure 12-1. Typical Xauth Session

There are various ways of configuring an IPsec remote access VPN on IOS. Xauth configuration changes according to the method used for IPsec configuration. Before configuring Xauth, you need to define a method list for authentication using the following command:

aaa authentication login method-name {group radius | group tacacs+ | local}

You can use the default method; however, recommended practice dictates using a named method list for IPsec authentication.

The most common form of remote access IPsec VPN configuration is using dynamic crypto maps, as demonstrated in Example 12-1. Authentication can be configured using the following command when such a configuration is used:

crypto map map-name client authentication list method-name

This command ties the crypto map to an authentication method list. After this command is added, Xauth will be initiated at the end of Phase 1 and the credentials will be verified using the method specified in the authentication method list. The method-name should match the authentication method list created. Example 12-2 expands Example 12-1 to include authentication.

Example 12-1. Remote Access IPsec VPN Configuration

Example 12-2. Remote Access IPsec VPN Authentication Including Authentication

A crypto map set is a collection of crypto map entries, each with a different seq-num argument but the same map-name argument. The configuration shown in Example 12-2 applies Xauth to all entries in the crypto map (remotevpn in Example 12-2). There might be entries in the crypto map that do not require Xauth. For such entries, you will need to disable Xauth individually.

To overcome this problem, the ISAKMP profile was introduced in Cisco IOS Software Release 12.2(15)T. The ISAKMP profile is an enhancement to Internet Security Association and Key Management Protocol (ISAKMP) configurations that enables modularity of ISAKMP configuration for Phase 1 negotiations. This modularity allows mapping different ISAKMP parameters to different IPsec tunnels. It also allows different Xauth configurations for different tunnels. Example 12-3 shows a common configuration using dynamic crypto maps and an ISAKMP profile.

Example 12-3. Remote Access IPsec VPN Configuration Using an ISAKMP Profile

Where an ISAKMP profile is used, Xauth is configured in the profile instead of the crypto map, using the following commands:

crypto isakmp profile profile-name
  client authentication list method-name

Similar to the client authentication command used with crypto map, this command ties the profile to an authentication method list. The method-name should match the authentication method list name. Example 12-4 shows the configuration required to add authentication to the configuration shown in Example 12-3.

Example 12-4. Authentication Configuration with an ISAKMP Profile

Authenticating SSL VPN Sessions

SSL-based VPNs provide remote-access connectivity from almost any Internet-enabled location using a web browser and its native SSL encryption. Unlike IPsec Remote Access VPNs, SSL-based VPNs do not require client software to be preinstalled on a machine. Any software required for application access across the SSL VPN connection is dynamically downloaded on an as-needed basis.

Cisco IOS supports the following three kinds of SSL VPN:

• Clientless mode

• Thin-Client mode

• Tunnel mode

• Discussion on the modes and their configuration is beyond the scope of this book; however, Example 12-5 shows a sample basic configuration of an SSL VPN.

Example 12-5. Sample SSL VPN Configuration

IOS supports both local and AAA server–based authentication for SSL VPNs. Before configuring authentication for an SSL VPN, you need to define a method list for authentication using the following command:

aaa authentication login method-name {group radius | group tacacs+ | local}

You can use the default method; however, recommended practice dictates using a named method list for IPsec authentication.

Authentication for SSL VPN is configured in the WebVPN context, using the following command:

aaa authentication list method-name

This command ties the method list you created earlier to the WebVPN context. For example, you can use the following commands to configure authentication for the test context from Example 12-5:

Configuring ACS 4.2 and 5.1 for IPsec and SSL VPN Authentication

Configuring ACS 4.2 and 5.1 for VPN authentication requires the steps you followed for configuring administrative authentication on IOS devices. Refer to Chapter 6, “Administrative AAA on IOS,” to recall the steps you used. A summary of steps required is as follows:

Step 1. Add a router as an AAA client with the correct shared key and protocol.

Step 2. Add a user.

Step 3. For ease of learning, ensure that you use a new group or access service so that the previous configuration does not cause problems.

Verifying and Troubleshooting VPN Authentication

Most common problems with VPN authentication are related to the communication between the router and the AAA server as discussed in Chapter 6. For the most part, when communication between the router and the AAA server is working, VPN authentication works also. If communication between the router and the AAA server is working well, but VPN authentication fails, you can verify the following:

• Ensure that the authentication command is applied correctly on the crypto map, ISAKMP profile, or WebVPN context.

• Ensure that the authentication commands are using the correct method list and server group.

• Test the local user authentication before configuring Xauth or SSL VPN authentication. This rules out problems with VPN configuration itself.

For troubleshooting VPN authentication, the following debug commands are most useful:

• debug radius: This command shows debugs of the RADIUS communication between the router and the RADIUS server. If authentication is failing, this is a good place to start troubleshooting from.

• debug crypto isakmp: This command shows debugs of Internet Key Exchange (IKE) events. Xauth-related events are also part of these debugs. You can use these debugs in combination with RADIUS debugs to find out whether Xauth is failing or Phase 1 of the VPN negotiation is failing.

• debug webvpn aaa: This command shows debugs of events and errors related to AAA during WEBVPN negotiation. If authentication is failing for WebVPN, you can use these debugs along with RADIUS debugs to identity the cause of failure.

• debug aaa authentication: This command shows information regarding the authentication process. The output is especially useful in finding the method list used by an authentication event.

Authorizing VPN Sessions

Cisco IOS supports authorization of VPN sessions using a local database as well as external AAA servers. This section looks at authorization of IPsec remote access and SSL VPN authorization using ACS 4.2 and 5.1.

Authorizing IPsec Remote Access Sessions

In cases where local authorization is configured, when Cisco IOS receives a remote access IPsec connection, it attempts to match the group name contained in the connection to a group configured on the router. This group, called the client configuration group (or the VPN group), contains all the attributes for the session, including the group preshared key (if digital certificates are not used), address pool, and so on.

When Cisco IOS is configured for authorization using RADIUS, the client configuration group is defined on the RADIUS server as a user. This user’s profile contains all group configuration options as attributes. In such cases, when IOS receives a remote access IPsec connection, it will do the following:

Step 1. It will attempt to authenticate the group name received in the IPsec connection with the RADIUS server using cisco as a password.

Step 2. On successful authentication, it will look for the group password (also called the preshared key) in the attributes received from the RADIUS server. If the password matches the one received in the IPsec connection, the session will be continued to the next phase.

Step 3. If Xauth is configured, IOS will attempt to authenticate the user with the RADIUS server. On successful authentication, the user attributes received from the server are stored.

Step 4. If the user profile received during Xauth contains any group attributes, IOS will not use any group attributes from the group profile itself. You will need to define all group and user attributes in the Xauth user profile. These attributes will be used during the MODECFG phase. If the user profile does not contain any group attributes, IOS will generate another RADIUS request to authenticate the group again to get the group attributes again.

Step 5. IOS will merge the user attributes received during Xauth and the group attributes received in reply to the third RADIUS request. The resulting list of attributes is used in the MODECFG phase to configure the client.

Before configuration authorization for VPN sessions, you must add a network authorization method list using the following command:

aaa authorization network {list-name | default} group radius

You can use the default method list; however, recommended practice dictates that you should use a named list to avoid problems between different services on a router that might be using AAA.

As with Xauth configuration, the commands required to configure VPN authorization depend on the VPN configuration method.

If you are not using an ISAKMP profile for VPN, the following command is needed for configuring authorization:

crypto map map-name isakmp authorization list method-list-name

The defined method-list-name parameter should match the list you created using the aaa authorization network command.

If you are using an ISAKMP profile for VPN, the following commands are needed for configuring authorization:

The defined group-name parameter in the match identity command should match the name of the group created on the RADIUS server and the defined method-list-name parameter should match the list you created using the aaa authorization network command.

Configuring ACS 4.2 and ACS 5.1 for IPsec Remote Access Authorization

Configuring ACS for authorization of IPsec remote access sessions requires you to create a user in ACS. The username created will be configured on the VPN client as the group name for the connection. You will recall from the previous section that Cisco IOS sends the group name of the connection to ACS for authentication and uses cisco as the password. This means that the password for the user should be kept as cisco in ACS. The user, or the group to which this user belongs, should have the following attributes configured at the least:

RADIUS IETF Attribute: Service-Type with value set to Outbound

RADIUS IETF Attribute: Tunnel-Type with value set to IP ESP

cisco-av-pair attribute with the following values:

ipsec:tunnel-type=ESP

ipsec:key-exchange=IKE

ipsec:tunnel-password=tunnel-pre-shared-key

ipsec:addr-pool=pool-name

tunnel-pre-shared-key is the group preshared key that will be used by the clients for group authentication. The pool-name is the name of the address pool configured on the router and will be used to provide address to the clients.

You can define additional group attributes as values of the cisco-av-pair attribute. Some of the valid attributes are given in Example 12-6.

Example 12-6. Some valid Group Attributes for IPsec Remote VPN

Apart from the group attributes discussed and shown in Example 12-6, there are four user attributes that can be added in the VPN user profile. Remember that the VPN user profile is the profile of the actual end user, which is used during Xauth. This differs from the group name added as a user previously. You can use these four attributes when a user or group of users need more or less privileges than the rest of the users of the VPN group. Table 12-1 lists and describes these four attributes.

Table 12-1. IPsec User Attributes

You already know how to add users and configure the RADIUS attribute in ACS 4.2 and 5.1 from previous chapters. If you cannot recall the steps, refer to Chapters 3 and 4 to add a user and refer to Chapter 8, “IOS Switches,” for the steps to add attributes for users and groups.

Authorizing SSL VPN Sessions

You will recall from the SSL VPN authentication section that user privilege is controlled by a policy group defined on the router. In Example 12-5, policy group test is defined for the context. This policy group applies on every user that connects to this context and does not allow a per-user change in the policies.

If you are using RADIUS to authenticate the users, you can define some attributes in the user profile that will override the policies in the group on IOS and provide privileges tailored to a user or a group of users.

You only need to configure the SSL VPN context to authenticate users using a RADIUS server as discussed earlier in the chapter. No additional configuration is required for authorization. IOS will use any attributes received during authentication.

Configuring ACS 4.2 and ACS 5.1 for SSL VPN Authorization

Most of the attributes that can be used for SSL VPN authorization are configured as values for the cisco-av-pair attribute. These attributes start with webvpn:. A list of all valid attributes can be found at http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_ssl_vpn.html#wp1055019.

You already know how to add users and configure RADIUS Attribute in ACS 4.2 and 5.1 from previous chapters. If you cannot recall the steps, refer to Chapters 3 and 4 for steps to add a user and refer to Chapter 8 for the steps to add attributes for users and groups.

Verifying and Troubleshooting VPN Authorization

When troubleshooting VPN authorization, the following problems are most commonly seen:

• Using group attributes in Xauth user profile: This leads to IOS ignoring group attributes and causing undesirable results.

• Attributes incorrectly configured: IOS will not be able to parse attributes incorrectly spelled. Attributes should be checked if something is not working properly.

• Attribute value incorrect: Incorrect value or reference to nonexistent objects, such as address pools, will cause IOS to ignore the attribute. You should ensure that the values are correct and objects are present on the router.

The following commands are useful when troubleshooting VPN authorization:

• debug radius: This command shows debug of the RADIUS communication between the router and the RADIUS server, which includes the attributes received from the RADIUS server. If authorization results are not as desired, these debugs will help verify the attributes that were received from the server.

• debug crypto isakmp: This command shows debugs of Internet Key Exchange (IKE) events. Xauth- and MODECFG-related events are also part of these debugs. You can use these debugs in combination with RADIUS debugs to find out whether there are problems during MODECFG.

• debug webvpn aaa: This command shows debugs of events and errors related to AAA during WEBVPN negotiation. If desired results are not seen, you can use this debug along with RADIUS debugs to verify the attributes received.

• debug aaa authorization: This command shows information regarding the authorization process. The output is especially useful in finding the method list used by an authorization event.

Accounting for IPsec Remote Access and SSL VPN

IOS enables you to send accounting information for IPsec remote access and SSL VPN sessions.

Before configuring accounting for these sessions, you need to create an accounting method list using the following command:

aaa accounting network method-list-name {start-stop | stop-only} group radius

You can use the default method list; however, recommended practice dictates using a named method list.

When accounting is configured for IPsec remote access sessions, IOS sends the following information:

• Session ID

• Session Time

• Input Octets

• Output Octets

• Input packets

• Output Packets

• Framed-IP-Address (Address assigned to the client)

To configure accounting for IPsec remote access sessions, use the following command in an ISAKMP profile:

accounting method-list-name

If you are not using ISAKMP profiles, use the following command to configure accounting:

crypto map map-name client accounting list method-list-name

When accounting is configured for SSL VPN sessions, IOS sends the session ID and session time in the accounting packet. To enable accounting for SSL VPN, use the following commands:

webvpn context context-name
aaa accounting list method-list-name

Lab Scenario #15: VPN AAA

ABC Inc. has IPsec remote access VPN configured on its router. Currently it is using the router’s local database to authentication users and assign group policies. It now wants to use its ACS server to authenticate users.

Split-tunneling is disabled for the VPN sessions. For the ACS group named Admins, the company wants to allow the users to have access to their local LAN.

The crypto map used on the router is named officevpn. ABC Inc. does not use ISAKMP profiles. Your task is to configure the router and ACS to complete this requirement.

Lab Setup

The Lab Scenario requires a router, at least one Layer 2 switch, ACS, and a host with Cisco VPN client. Figure 12-2 shows the setup required.

Figure 12-2. Lab Setup for Scenario #15

Before proceeding with this lab, add the router as a client in ACS. If you are using ACS 4.2, rename a group as Admins. If you are using ACS 5.1, create an identity group name Admins. You can use the default RADIUS Access Service or create a new one. The identity policy can be left as default (Internal Users). You also need to create an Authorization rule in the Access Service. This rule should match the Admins identity group.

Apply the following VPN configuration on the router before starting the lab:

Lab Solution

The following solution provides steps for both ACS version 4.2 and version 5.1:

Step 1. Add the ACS server on the router:

Router(config)#aaa new-model
Router(config)#radius-server host 192.168.1.10 key abckey

Step 2. Configure the router for Xauth using ACS:

Router(config)#aaa authentication login vpnauth group radius
Router(config)#crypto map officevpn client authentication list vpnauth

Step 3. (For ACS 4.2 only) Add the user-include-local-lan attribute to the group:

Select Admins group from Group Setup and click Edit Settings.

Scroll down to the RADIUS (IOS/PIX 6.0) section and select cisco-av-pair.

In the text box below cisco-av-pair, enter ipsec:user-include-local-lan=1.

Click Submit+Restart.

Step 4. (For ACS 5.1 only) Create an authorization profile:

Authorization profiles can be created from Policy Elements > Authorization and Permissions > Network Access > Authorization Profiles.

The authorization profile should have the following cisco-av-pair attribute:

ipsec:user-include-local-lan=1

Step 5. (For ACS 5.1 only) Apply the authorization profiles created in step 5 to the authorization rule created during Lab Setup.

Lab Verification

To verify the solution, create a user in the Admins Group/Identity Group in ACS. Create a new connection on the VPN Client according to the client group configuration on the router and connect. When prompted for Xauth, authenticate with the user you created. The authentication should succeed and you should have access to the local LAN even when connected to the VPN.

Authenticating PPP Sessions

PPP is probably one of the best known and time-tested protocols for transporting IP traffic across point-to-point links. It is commonly used to transport IP traffic across plain old telephone service (POTS) dialup, ISDN, or point-to-point leased lines. This section looks at how to use RADIUS to authenticate PPP dial-in sessions on IOS. The concepts and configuration discussed in this section can be used for authentication of any kind of PPP session, including PPPoE, with little or no change.

There are three phases over which PPP sessions are established:

• Phase 1: The two hosts use Link Control Protocol (LCP) to configure and optionally test the data link. Among other things, an authentication protocol is decided on during this phase.

• Phase 2: This is an optional authentication phase. The authentication protocol negotiated during the first phase is used to authenticate the client. The authentication is usually one-way with the called party (an IOS router) authenticating the calling party (a remote dial-in user). IOS allows using PAP, CHAP, MS-CHAP, and MS-CHAPv2 as authentication protocols.

• Phase 3: Network Control Protocol (NCP) is used to choose and configure a network layer protocol such as IP.

IOS allows using the local database as well as a RADIUS or TACACS+ server for authentication for PPP sessions.

Before configuring PPP for authentication using RADIUS, you need to add an authentication method list using the following command:

aaa authentication ppp {default | method-list-name} group radius

You can use the default method list and this is one time where you should use it unless you want a different authentication method or servers for different type of PPP sessions.

There are different ways of configuring PPP on IOS. Whichever method you use, it will have a ppp authentication protocol command. If you use the default method list for PPP authentication, it will apply to all kinds of PPP configuration and force an authentication using the RADIUS servers. If you use named method lists, you will need to modify the ppp authentication protocol command to the following:

ppp authentication protocol method-list-name

Example 12-7 shows an example of PPP configuration using named method list.

Example 12-7. PPP Authentication Configuration Using Named Method List

Configuring ACS for PPP Authentication

Configuring ACS 4.2 and 5.1 for VPN authentication requires the steps you followed for configuring administrative authentication on IOS devices. Refer to Chapter 6 to recall the steps you used, although a summary of the required steps is as follows:

Step 1. Add Router as an AAA Client with correct shared key and protocol.

Step 2. Add a user.

Step 3. For ease of learning, ensure that you use a new group or access service so that previous configuration does not cause problems.

Verifying and Troubleshooting PPP Authentication

Most common problems with PPP authentication are related to the communication between the router and the AAA server as discussed in Chapter 6. For the most part, when communication between the router and the AAA server is working, PPP authentication works as well. If communication between the router and the AAA server is working well but PPP authentication fails, you can verify the following:

• Authentication command is applied in the correct place.

• Ensure that the authentication commands are using the correct method list and server group.

• Test the local user authentication before configuring RADIUS authentication. This rules out problems with the PPP configuration itself.

For troubleshooting PPP authentication, the following debug commands are most useful:

• debug ppp negotiation: This command shows packets sent during PPP startup, where PPP options are negotiated. You can use these debugs to see the authentication negotiation.

• debug radius: This command shows debugs of the RADIUS communication between the router and the RADIUS server. If authentication is failing, this is a good place to start troubleshooting from.

• debug ppp authentication: This command shows authentication protocol messages, including Challenge Authentication Protocol (CHAP) packet exchanges and Password Authentication Protocol (PAP) exchanges. You can use these debugs along with the previous two debugs to isolate the root cause of authentication failure.

Authorizing PPP Sessions

When authenticating PPP sessions using RADIUS, you can configure authorization to do the following:

Permit or deny PPP sessions for a user or a group of users.

Configure different attributes for a user or a group of users to provide them with different access levels.

To enable authorization using RADIUS, use the following global configuration command:

aaa authorization network {default | method-list-name} group radius

You can use the default method list or create a named method list and apply it to the PPP configuration using the following command:

ppp authorization method-list-name

Configuring ACS 4.2 and 5.1 for PPP Authorization

Configuring ACS for PPP authorization requires configuring RADIUS IETF and RADIUS (IOS/PIX 6.0) attributes in an ACS 4.1 user or group profile or in an authorization profile applied to an authorization rule in ACS 5.2.

The following attribute and value pairs should be present in the user/group profile or the authorization profile to permit PPP sessions:

RADIUS IETF Attribute: Service-Type = Framed

RADIUS IETF Attribute: Framed-Protocol = PPP

You can set the Service-Type attribute to something other than Framed if you want to deny PPP access to a user or group of users. Apart from the preceding attributes, there are various attributes that can be used to change various aspects of a PPP session for a user or group of users. Table 12-2 outlines some of the more common attributes.

Table 12-2. Common RADIUS Attributes for PPP

You already know how to add users and configure RADIUS attributes in ACS 4.2 and 5.1 from previous chapters. If you cannot recall the steps, refer to Chapters 3 and 4 for steps to add a user and refer to Chapter 8 for the steps to add attributes for users and groups.

Verifying and Troubleshooting PPP Authorization

When troubleshooting PPP authorization, the following problems are most commonly seen:

• Attributes incorrectly configured: IOS will not be able to parse attributes incorrectly spelled. Attributes should be checked if something is not working properly.

• Attribute value incorrect: Incorrect value or reference to nonexistent objects, such as address pools, will cause IOS to ignore the attribute. You should ensure that the values are correct and objects are present on the router.

• User attributes override group attributes: Remember that user attributes will override group attributes. Ensure that you do not have conflicting attributes in user and group profiles.

The following commands are useful when troubleshooting PPP authorization:

• debug ppp negotiation: This command shows packets sent during PPP startup, where PPP options are negotiated. You can use these debugs to see the authorization negotiation.

• debug radius: This command shows debugs of the RADIUS communication between the router and the RADIUS server, which includes the attributes received from the RADIUS server. If authorization results are not as desired, these debugs will help verify the attributes that were received from the server.

Accounting for PPP Sessions

IOS enables you to send accounting information for PPP sessions to a RADIUS server.

Before configuring accounting for these sessions, you need to create an accounting method list using the following command:

aaa accounting network method-list-name {start-stop | stop-only} group radius

You can use the default method list; however, recommended practice dictates that you use a named method list.

When accounting is configured for PPP sessions, IOS sends the following information:

• Session ID

• Session Time

• Input Octets

• Output Octets

• Input packets

• Output Packets

• Framed-IP-Address (address assigned to the client)

• Session Terminate Cause

If you use a named method list, you can apply it to the PPP configuration using the following command:

ppp accounting method-list-name

Summary

In this chapter you learned about authentication, authorization and accounting of IPsec Remote Access VPN (EzVPN), SSL VPN, and PPP sessions.

This is the right place to stress of the importance of RADIUS attributes because this chapter exhibits the difference these attributes can make when properly used. The attributes can be used extensively to design your security policies and exceptions on per-user or per-group basis.

This chapter also forms the basis for the next chapter, which looks at AAA of IPsec remote access VPN on ASA.