CCNP Security VPN: Advanced Easy VPN Authorization

Foundation Topics

Configuration Procedures, Deployment Strategies, and Information Gathering

The role of authorization in any virtual private network (VPN) deployment is an important one. With it, you can control which of your remote users can or cannot access corporate servers, email, financial and personnel records, and even the Internet. However, not only can you control the level of access each remote user has in your corporate environment, you can also control the user’s connection experience through maximum connection times, timeout settings, simultaneous logins, portal customization, and so on.

You can restrict or allow access to specific internal resources from remote users using the available policy options on the ASA device, whether you allow full access from all remote users to all of your internal resources (really not recommended) or, as shown in Figure 17-1, you provide remote users access to only the internal resources they require. (For example, Client A can access the corporate finance server and file server but not the corporate email server, but Client B can access the corporate email server and file server but not the corporate finance server.) Specifically, this chapter focuses on the role of group policies for user authorization purposes, and as you will see in the next section, you can assign IPv4 and IPv6 access lists in group policy objects that allow or deny access to internal servers for a particular group, access hours, maximum connection time, and so on.

Figure 17-1 ASA Authorizing (or Not) Remote Users

In addition to the available authorization attributes that can be applied by local group policies to remote users, you can extend the role of authorization to a remote (internal) authentication, authorization, and accounting (AAA) server. After the remote user has been authenticated, the remote AAA server is queried for the authorization attributes that should be applied to their session.

Configuring Local and Remote Group Policies

Via group policies, you can assign attributes to users and groups based on their individual user account, group membership, or the connection profile used to connect to the ASA device.

Using group policy objects, you can define the following user authorization settings (and many more, as discussed momentarily):

• Set the maximum connection time applied to remote users before they are required to carry out the connection process and reauthenticate.
• Control the number of simultaneous logins that can be made using the particular user account.
• Restrict access only to the internal resources and subnets using IPv4 filters (access control lists [ACL]).
• Define the networks used for split tunneling.
• Control remote user access hours (the time they can and cannot log in).

Recall from the information shown in Chapter 2, “Configuring Policies, Inheritance, and Attributes,” covering group policies, you can configure two types of group policy objects. The location of the policy attributes contained in them dictates the type of policy it is:

• Local group policies (also known as internal group policies) are policy objects that have been configured locally on the ASA along with the attributes they contain. They are assigned either to local users directly (local user accounts configured on the ASA) or in connection profiles.
• Remote group policies (also known as external group policies) are applied either to remote users or groups. The attributes contained in a remote group policy are configured on a remote (typically internal) AAA server (for example, RADIUS or Lightweight Directory Access Protocol [LDAP]) in the form of attribute/value (A/V) pairs. However, the remote group policy container (name) must also be configured on the ASA device, even though authorization attributes are imported from the AAA server.

Local group policy and the remote group policy containers are both configured on the ASA using the group-policy name [internal | external] global configuration command via the command-line interface (CLI) or within Configuration > Remote Access VPN > Network (Client) Access > Group Policies if you have chosen to use the Adaptive Security Device Manager (ASDM) for configuration purposes. Within the ASDM, begin by clicking Add. Then, from the Add menu, choose either Internal Group Policy or External Group Policy. For this example, as shown in Figure 17-2, the Add External Group Policy option was selected.

Figure 17-2 External Group Policy Configuration

In the Add External Group Policy window, enter the following details:

• Name: Enter a name for the group policy object. This is the actual username used by the ASA and configured within the RADIUS server’s database for authentication purposes between the ASA and the RADIUS server.
• Server Group: Choose an existing AAA server group or create a new one.
• Password: Enter a password to be used for authentication with the AAA servers. This is the password configured for the previously defined username also used for the group policy name.

The group policy object is then used as a container for the A/V attributes received from the internal AAA server. Example 17-1 displays the configuration of an external group policy object when working from the CLI.

Example 17-1 External Group Policy Object Configuration

CCNPSec# conf t
CCNPSec(config)# group-policy Remote_EzVPN_Policy external server-group
 RADIUS password security

If you want to create a new AAA server group instead of selecting an existing one, you can choose New > New RADIUS Server Group or New > New LDAP Server Group in the ASDM’s Add External Group Policy window. After choosing the appropriate server group type to create, enter the following information into the Add AAA Server Group window:

• Server Group: Enter a name for the server group.
• Protocol: Uneditable. This displays either RADIUS or LDAP depending on your chosen group.
• Accounting Mode: Choose either Simultaneous (the ASA sends accounting data to all servers in the group) or Single (the ASA sends accounting data to only one server); this option is not available for LDAP server groups.
• Reactivation Mode: Choose either Depletion (servers that have failed in the group are only reactivated when all other servers in the group are inactive) or Timed (failed servers are reactivated after 30 seconds). If you choose Depletion, you can also modify the dead timer (default 10 minutes), which is time that elapses between disabling the last server in the group and the reenabling of all servers.
• Max Failed Attempts: Enter the maximum number of attempts that will be used to connect to a server configured in the server group until declaring it dead; the default is 3.
• Enable Interim Accounting Update: Choose this option to enable multisession accounting for both AnyConnect and clientless Secure Sockets Layer (SSL) VPNs.
• Enable Active Directory Agent mode: Not relevant for VPN configuration, but it is related to the identify firewall feature.
• VPN3K Compatibility: Choose Do Not Merge (to disable merging of RADIUS downloadable ACLs with received A/V pair ACLs), Place the Downloadable ACL After the Cisco AV Pair ACL, or Place the Downloadable ACL Before the Cisco AV Pair ACL.

After creating your new AAA server group, you then need to add AAA servers to it in the AAA Server Groups window (Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups), as shown in Figure 17-3. Note that for this configuration to be fully usable and valid, configurations on the remote LDAP or RADIUS servers need to be performed. (LDAP and RADIUS configuration is beyond the scope of this book.)

Figure 17-3 AAA Server Configuration

Example 17-2 displays the commands required to create a new AAA server group and add a new external server to the group.

Example 17-2 Creating a New AAA Server Group and Adding an External Radius Server

CCNPSec# !!First create your new AAA server group ready to add your exter
 nal AAA server!!
CCNPSec# conf t
CCNPSec(config)# aaa-server RADIUS protocol radius
CCNPSec(config-aaa-server-group)# !!Now enter the details of your AAA
 server and add it to the new group!!
CCNPSec(config-aaa-server-group)# exit
CCNPSec(config)# aaa-server RADIUS (outside) host 172.30.255.5
CCNPSec(config-aaa-server-host)# key security
CCNPSec(config-aaa-server-host)# radius-common-pw security

When creating a new internal group policy object using the CLI, use the global configuration command group-policy name internal from name. The from name options available with the command are optional enable you to specify an existing group policy object that can be used as a template and its settings copied from. After you create the group policy object, you can enter the group-policy name attributes to set any specific attributes required using the commands shown in Table 17-2 in group policy attributes configuration mode.

When using the ASDM, click Add > Add Internal Group Policy to open the Add Internal Group Policy window, shown in Figure 17-4. As you can see, many more options are available for this configuration, because all attributes of the group policy are configured and stored on the ASA. Begin by giving the policy a name, which is the only mandatory attribute required when configuring a new policy. All other attributes are by default inherited from the default group policy object (DfltGrpPolicy).

Table 17-2 lists the General window fields and values that you can use to configure the remaining general attributes you want to set explicitly. In addition, the table includes the corresponding CLI commands in case you have chosen to configure your ASA using the CLI. Note that before configuration is possible, you must uncheck the respective field’s Inherit option. However, you do not have to do so when you are using the CLI to configure the attributes; as soon as you configure a setting, the default inheritance is overridden.

Figure 17-4 Internal Group Policy Configuration

Table 17-2 Internal Group Policy Attributes

After setting the specific general attributes required in your local group policy, you can assign the policy either directly to a local user account or globally to all users of a connection in the connection profile’s properties.

Assigning a Group Policy to a Local User Account

Begin this task by entering the user attributes configuration mode using the username- name attributes global configuration command. Within this mode, you can apply the group policy using the vpn-group-policy policy name command, as shown in Example 17-3.

Example 17-3 Assigning a Group Policy Directly to a User

CCNPSec# conf t
CCNPSec(config)# username EzUser1 attributes
CCNPSec(config-username)# vpn-group-policy EasyVPN

When using the ASDM, start by opening your user’s account properties in Configuration > Remote Access VPN > AAA/Local Users > User Accounts. In the User Accounts window, choose the local user account to apply the group policy object to and click Edit.

As shown in Figure 17-5, in the Edit User Account window that opens, we choose VPN Policy from the menu on the left and uncheck the Inherit check box next to the Group Policy section. Using the drop-down list, we then choose the group policy object we want applied to the user account.

Figure 17-5 Assigning a Group Policy Directly to a User

Assigning a Group Policy to a Connection Profile

You can assign a group policy object to a connection profile using the CLI of ASDM. Via the CLI, issue the default-group-policy policy name command within tunnel-group general-attributes configuration mode. Alternatively, open the ASDM connection profile properties window by navigating to Configuration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Profiles. Select the connection profile to assign the group policy object to from the list and click Edit.

In the Edit IPsec Remote Access Connection Profile Name window, use the drop-down list in the Default Group Policy section of the window to select the group policy object to be applied, as shown in Figure 17-6.

Figure 17-6 Assigning a Group Policy to a Connection Profile

In addition to the more general properties that you can assign using a group policy object, you can assign advanced properties (for example, split-tunneling exceptions and rules).

The configuration in Figure 17-7 shows the split-tunneling properties located in the Advanced > Split Tunneling section of the Edit Internal Group Policy - Name window.

Figure 17-7 Group Policy Split-Tunneling Configuration

For this example, the domain name vpn.lab has been added as a Domain Name System (DNS) name, indicating to the Easy VPN clients that any requests for DNS information for hosts in this domain should be tunneled (for example, secretfiles.vpn.lab). In addition to the configuration of DNS names, the option to tunnel only the list specified in the preconfigured ACL Internal_Servers by using the Policy and Network List fields has been configured. Example 17-4 displays the same configuration achieved via the CLI.

Example 17-4 Configuring Split Tunneling

CCNPSec# conf t
CCNPSec(config)# group-policy Internal-EzVPN-POLICY attributes
CCNPSec(config-group-policy)# split-tunnel-policy tunnelspecified
CCNPSec(config-group-policy)# split-tunnel-network-list value Internal_
 Servers
CCNPSec(config-group-policy)# default-domain value VPN.LAB

The configuration shown in Figure 17-7 and Example 17-4 results in DNS requests for devices in the domain name vpn.lab, or traffic matching that of the ACL Internal_Servers, to be sent by Easy VPN clients through the VPN tunnel to the ASA and on to the corporate network. All other traffic (for example, the remote user device’s LAN or Internet data) travels directly to the destination rather than through the VPN tunnel.

Accounting Methods for Operational Information

You have at your disposal the following logging mechanisms on the ASA to monitor remote user activity and connection state:

• Syslog
• NetFlow 9
• RADIUS accounting
• Simple Network Management Protocol (SNMP)

Syslog can provide a large amount of information for statistics-based analysis or information regarding the current ASA’s health and the status of our remote connections. In addition to being able to send syslog (debugging, informational, and so on) information to remote servers for offline inspection, you can choose to store it in a local buffer on the ASA for later viewing when working on the device.

Figure 17-8 shows the ASDM’s Logging Setup window available via Configuration > Device Management > Logging > Logging Setup. To enable logging, just check the Enable Logging check box. You can also optionally include debugging information when troubleshooting a feature/error on the ASA by checking the Send Debug Messages as Syslogs check box.

Figure 17-8 Enable Logging in the ASDM and Specify Location

In the Logging Setup window, you can also enable logging on the failover device if you are running two ASAs in a hardware failover pair, and you can select to send your syslog information in EMBLEM format. (This is required if you are running CiscoWorks software as applications. For example, RME [Resource Manager Essentials] processes syslog information in EMBLEM format.) In addition to these options, in the Logging to Internal Buffer section of the window, you can increase or decrease the size of the internal buffer used to store the logging information (default is 4096 bytes) on the ASA. The internal buffer is a rolling log, meaning as soon as it becomes full, any new information starts to overwrite the older information in the buffer. For example, if your ASA device is logging a large amount of information while you are trying to troubleshoot an error, it is worthwhile to increase the size of the logging buffer to prevent the information you might require being overwritten before you have had a chance to look at it. In this section, you can also configure the ASA to store the buffer information in a file on the ASA’s flash device or upload it to an FTP server when it reaches a specific size. This can also prevent your valuable log information from being overwritten. In the final section of the window, you can select the amount of information that is written to the ASDM log viewer (visible on the home page). The default is 100 messages.

After you have enabled logging on the ASA device, you can navigate to Configuration > Device Management > Logging > Syslog Servers and configure the remote servers to which the ASA will send its generated syslogs.

Figure 17-9 shows the Syslog Servers window and the Add Syslog Server window that opens when you click Add. In the Add Syslog Server window, select the interface your server is available on, enter the IP address of the server, and select either TCP or UDP (default) and the port (514 by default). In addition, you can check to enable the option Log Messages in Cisco EMBLEM Format (UDP only) or the option to Enable Secure Syslog Using SSL/TLS (Secure Sockets Layer/Transport Layer Security). (This latter option is available only when using TCP for communications between the ASA and server.)

Figure 17-9 Creating a New Syslog Entry

After you have entered your syslog servers, you need to then specify the level of logging information that will be sent to our syslog server. In Configuration > Device Management > Logging > Logging Filters, you can choose from the following:

• Emergencies
• Alerts
• Critical
• Errors
• Warnings
• Notifications
• Informational
• Debugging

As shown in Figure 17-10, you can choose the level of logging per function on the ASA. For example, you might want to send informational messages to the console but debugging information to the ASA’s internal buffer.

Figure 17-10 Choose the Logging Level per Function

And that’s it! Well... not quite. At the moment, enough options have been selected and enough information entered for the ASA to be able to log to the internal buffer, syslog, and servers. Now you can start to get really granular with the control you have over syslog information. For example, if you are interested in only a particular log message or set of messages, you can create a filter in the Event Lists window. After creating a filter, you can select this in the Logging Filters window instead of selecting a predefined logging level.

You can optionally rate limit the number of log messages sent per second per logging level, or even per log message, in the Rate Limit window. You can set up a dedicated facility per logging level, if you want to view or filter the different logging levels easily on our syslog server. And in the E-Mail Setup and SMTP windows, you can set up the parameters and options used to send syslog information to a recipient via email.

The process of configuring logging on your ASA when working from the CLI is, as you can imagine, a lot faster because you do not have to open and close all the different windows or check on uncheck any of the options. However, which method you choose to use to configure your ASA is up to you, although for the exam it is a good idea to have an understanding of the various CLI commands that are available and their corresponding ASDM locations and values.

For example, to enable informational logging to the local buffer of the ASA, you can enter the following commands in enable mode:

logging buffered informational
logging enable

For logging to become operational, the latter command must be issued.

Similarly, to set up logging to an external server, you can enter the following enable mode commands:

logging trap informational
logging host [nameif] {hostname | ip address} port [format emblem]

Again, you can use the format emblem keywords along with the command to enable the use of the EMBLEM format when working with a supported RADIUS server. When configuring logging to a destination or the local buffer, the same logging levels are available (for example, notifications, emergencies, debugging) as shown in Example 17-5. You have the choice of either entering the name of the level (for example, informational) or the corresponding severity level (6); both achieve the same result.

Example 17-5 Available CLI Logging Severities

CCNPSec(config)# logging buffered ? 

configure mode commands/options:
  <0-7>          Enter syslog level (0 - 7)
  WORD           Specify the name of logging list
  alerts         Immediate action needed           (severity=1)
  critical       Critical conditions               (severity=2)
  debugging      Debugging messages                (severity=7)
  emergencies    System is unusable                (severity=0)
  errors         Error conditions                  (severity=3)
  informational  Informational messages            (severity=6)
  notifications  Normal but significant conditions (severity=5)
  warnings      Warning conditions                 (severity=4)

You can view logging information held in the ASA’s internal buffer in Monitoring > Logging > Log Buffer. Alternatively, you can enter the show logging command when using the CLI. Choose the logging level you are interested in viewing and click View. Figure 17-11 shows an example of the log buffer contents in the internal logging buffer viewed using the ASDM.

Figure 17-11 ASA Internal Log Buffer

NetFlow 9

With NetFlow logging, you can view information on a flow-by-flow basis based on Layer 3 and Layer 4 information of a conversation. Unlike sending information to a collector in tuple format (which can lead to limitations in the amount of information sent in any one packet, like its predecessor NetFlow 5), NetFlow 9 uses a template-based method of transferring information to a server running the NetFlow collector service. The template is sent to the server at specific intervals (30 minutes) and is used to format the information it receives from the ASA.

The ASA can send NetFlow 9 information to a server running the NetFlow 9 collector service (all other versions are incompatible) based on the following packet-flow actions occurring:

• Created
• Denied (excluding flows denied by Ethertype ACLs).
• Torn down

Figure 17-12 shows the configuration of NetFlow on the ASA device using the ASDM.

Figure 17-12 ASA NetFlow Configuration

In the NetFlow window (Configuration > Device Management > Logging > NetFlow), you can enter a value in minutes for the interval used to send the Version 9 template to the collection service running on your remote server (default 30). Optionally, you can choose to delay the sending of flow-creation events by a specific time you enter in seconds (which can help minimize the amount of information sent at any one time if, for example, a lot of flows are created at once on the ASA device). You also enter your flow collector’s (server) IP address, the interface they are available on, and the UDP port that will be used for the communication of NetFlow information to them. After entering this information, you can then specify the type of event for which NetFlow information is sent to the servers. As shown in Figure 17-12, three events can cause the information to be sent. You can specify the event using a service policy that, if you recall from earlier chapters, you have already seen when used to create quality of service (QoS) policies on the ASA.

However, unlike QoS policies, NetFlow policies can be applied only globally, not per interface. By default, the ASA has an existing default service policy that is applied globally to the ASA. However, you cannot edit this in the ASDM, so you must create a new global service policy and either use an access list to define the IP addresses for which your NetFlow flow information will be generated or use the class-default class of your policy.

To configure NetFlow via the CLI, enter flow-export option global configuration command (with the exception of service policy configuration, which is shown in a moment). Table 17-3 lists the options/values available for this command. Notice how these are also the same options that are available when using the ASDM.

Table 17-3 flow-export CLI Commands

In this example, a new global service policy is created using the class-default class to match all traffic for NetFlow flow information. Begin by opening the service policy in the ASDM Service Policy Rules window (Configuration > Firewall > Service Policy Rules) and clicking Add. Then choose Add Service Policy Rule. In the Add Service Policy Rule Wizard - Service Policy window, choose Global - Applies to All Interfaces and click Next.

On the next screen, Add Service Policy Rule Wizard - Traffic Classification Wizard, choose the Use Class-Default as the Traffic Class and click Next.

Then, in the Add Service Policy Rule Wizard - Rule Actions window, open the NetFlow tab. On this tab, click Add. In the new Add Flow Event window that opens, shown in Figure 17-13, choose the event that will trigger the sending of NetFlow information from the Flow Event Type drop-down box and check the box next to the host for which you want to enable this rule. Finally, click OK and Finish to apply the new rule.

Figure 17-13 ASA NetFlow Service Policy Configuration

Example 17-6 displays the same configuration as the earlier ASDM example, but this time configured using the CLI.

Example 17-6 NetFlow Export Configuration

CCNPSec(config)# flow-export destination inside 192.168.1.100 5010
CCNPSec(config)# policy-map global_policy
CCNPSec(config-pmap)# class class-default
CCNPSec(config-pmap-c)# flow-export event-type flow-create destination 192.168.1.100

RADIUS VPN Accounting

You can enable RADIUS accounting information so that your support representatives can interrogate the RADIUS logging information to see whether a VPN connection has succeeded or failed (and if failed, why).

To enable RADIUS accounting in a connection profile, as shown in Figure 17-14, navigate to Configuration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Profiles. Choose your connection profile from the list and click Edit. In the Edit IPsec Remote Access Connection Profile: Name window, choose Advanced > Accounting from the menu on the left. In the Accounting window, from the drop-down list choose the RADIUS server group that contains the RADIUS servers to which the ASA will be sending its accounting information. You can also create a new server group by clicking Manage if no groups are currently available.

Figure 17-14 IKEv1 Connection Profile RADIUS Accounting Configuration

The CLI configuration is just as simple. You configure the accounting servers within the now familiar tunnel-group general-attributes configuration mode with accounting-server-group name, as shown in Example 17-7.

Example 17-7 Connection Profile Accounting Server Configuration

CCNPSec(config)# tunnel-group DefaultRAGroup general-attributes
CCNPSec(config-tunnel-general)# accounting-server-group RADIUS

After configuring RADIUS accounting servers in a connection profile, you can inspect the received RADIUS accounting information on your RADIUS server implementation using the various logging options that are available.

SNMP

The ASA can support access for device and statistical interrogation using SNMP Version 1, Version 2c, and Version 3. Many texts and books already explain the differences between these versions, so to save you from reading it all again, this discussion assumes that you know enough about SNMP already to have made the decision that if Version 3 is available on a device, you use Version 3 to access it.

You configure the various SNMP options (traps, location, global community string, and hosts) in Configuration > Device Management > Management Access > SNMP, as shown in Figure 17-15.

Figure 17-15 ASA SNMP Configuration

In the SNMP window, you can configure all the familiar options for the protocol, such as the community string, contact, location, and listening port (UDP 161 by default). You can configure the criteria for trap information to be sent by clicking Configure Traps and choosing from the available options in the SNMP Trap Configuration window that opens.

In addition, in the SNMP window, in the SNMP Host Access List section, you can explicitly enter the addresses of your servers that will be accessing your ASA device. You can also create the users and groups that will be used for SNMPv3 access in the SNMPv3 Users section of the window.

To configure SNMP hosts, options, and attributes via the CLI, enter the snmp-server option global configuration mode command. Table 17-4 describes the configuration options you have for this command. Note that these are the same as those available within the ASDM SNMP window shown earlier in Figure 17-15.

Table 17-4 snmp-server CLI Commands