Several postings previous to this one, some VPN misconceptions were discussed (ed. note: here). This post will elaborate, as promised, on the two filtering options briefly mentioned to secure the VPN tunnel: 1) Group policy based filters and 2) Downloadable ACLs. The first of these applies to both site-to-site and remote access VPNs, while the second applies only to client-based remote access with either IPSec or SSL.
Unless otherwise specified, all connection profiles, or tunnel groups, on the ASA utilize the group policy entitled DfltGrpPolicy. This corresponds to what was previously called the Base Group on the VPN Concentrator and arguably is a mix of both secure and insecure default settings.
We will briefly examine how to add a new policy in the rest of this post. The screenshot below illustrates that a new Connection Profile created with ASDM defaults to using the DfltGrpPolicy as the Group Policy applied to the new Tunnel Group.
If the Add button is clicked, an entry field appears to name the new policy, and on the third line, after the Inherit check box is deselected, you are given the option to apply an already existing filter or create a new one. By clicking on the Manage button, another window opens prompting for adding an ACL (Access Control List) name as well as adding at least one ACE (Access Control Entry). This series of screens are seen as follows:
Note above that the additional feature of an optional Time Range is available to further constrain the user or site to access within a discrete time period!
For Downloadable ACLs (remote access IPSec or SSL clients only), the bulk of the configuration would be done on a RADIUS server. We will illustrate how to implement this functionality using CiscoSecure ACS below.
Note the checkbox for User-Level Downloadable ACLs. This is necessary for this feature to be visible under the Shared Profile Components Button.
Once this button has been clicked, and the corresponding hyperlink for Downloadable IP ACLs has also been clicked, a screen is presented for entry of a label for what can best be described as a group of ACLs. In the example below, the TestACL group was created with two access-lists, Test_ACL and Alternate_ACL. The configuration is purposely incomplete, as AAA clients would be added to the drop-down menus on the right.
Although the naming conventions shown here appear to be redundant, this ACS functionality allows different permissions to be extended to the remote user depending on the device with which they authenticate. For clarity and completion, the access-list contents for the two lists shown above are depicted below:
Author: Doug McKillip