With more and more folks working remotely or in hybrid settings, there’s an increasing call for IT departments and MSPs to configure Cisco AnyConnect VPNs on ASA firewalls. But Cisco documentation can be extremely confusing, which leads some organizations to get the configuration wrong (and by that, we mean insecurely).

If the steps are laid out clearly, the process is actually quite simple. And that’s where our guide comes in handy.

In this article, we’ll break down the ins and outs of Cisco AnyConnect, including what it is, why it’s important and what steps are required to properly configure Cisco AnyConnect for your VPN.

What is Cisco AnyConnect?

Cisco AnyConnect is a software program developed by Cisco Systems that provides secure VPN (Virtual Private Network) connections for users. It’s primarily used by businesses and organizations to enable remote workers to securely access internal networks and resources over the internet.

Some key benefits of Cisco AnyConnect VPN include:

  1. Secure connectivity: AnyConnect provides encrypted network connectivity, ensuring that data transmitted between the remote user and the company network is secure and protected from unauthorized access.
  2. Support for multiple platforms: AnyConnect is compatible with a wide range of operating systems, including Windows, macOS, Linux, and mobile platforms like iOS and Android.
  3. Automatic network detection: The software can automatically detect when a user is on an unsecured network and establish a VPN connection to ensure secure communications.
  4. Remote access: It allows remote users to access the internal network resources as if they were physically present in the office, which is particularly useful for remote work scenarios.
  5. Customizable policies and access control: Administrators can set policies to control user access to network resources, ensuring that users have appropriate levels of access based on their roles.
  6. Endpoint assessment: AnyConnect can assess the security posture of the device being used to connect to the network, ensuring that it meets certain security standards before allowing access.

Now that you know some of the benefits, letโ€™s go through the steps you’ll need to configure Cisco AnyConnect for your VPN.

1. Configure AAA authentication

The first thing to configure is AAA authentication. My preference is to use RADIUS for authentication and authorization, but there are other options such as LDAP. The configuration is similar:

!
aaa-server MYRADIUS protocol radius
aaa-server MYRADIUS (INSIDE) host 10.10.1.1
 key ****
!

This configuration fragment says that I have a RADIUS server inside my network with IP address 10.10.1.1, which I refer to by the tag โ€œMYRADIUSโ€ in the ASA configuration. Itโ€™s accessed through the ASA interface that I called โ€œINSIDEโ€ in the interface configuration.

2. Define VPN protocols

When users connect their VPN, theyโ€™ll need an IP address for the VPN session. This is the address that will appear inside the corporate network for this user. It has nothing to do with the userโ€™s public IP address or any address they might have inside their home network. It’s just used on the inside of the network after the remote user’s traffic has passed through the ASA.

!
ip local pool ANYCONNECT_POOL1 10.99.1.1-10.99.1.254 mask 255.255.255.0
ip local pool ANYCONNECT_POOL2 10.99.2.1-10.99.2.254 mask 255.255.255.0
!

I defined two pools here because I plan to have multiple tunnel groups later.

3. Configure tunnel groups

Next, I configure my tunnel groups. Iโ€™ll create two such groups for reasons Iโ€™ll explain later.

!
tunnel-group ANYCONN_1 type remote-access
tunnel-group ANYCONN_1 type general-attributes
 address-pool ANYCONNECT_POOL1 
 authentication-server-group MYRADIUS
 default-group-policy NOACCESS
tunnel-group ANYCONN_1 webvpn-attributes
 group-alias EMPLOYEES enable
!
tunnel-group ANYCONN_2 type remote-access
tunnel-group ANYCONN_2 type general-attributes
 address-pool ANYCONNECT_POOL2
 authentication-server-group MYRADIUS
 default-group-policy NOACCESS
tunnel-group ANYCONN_2 webvpn-attributes
 group-alias VENDORS enable
!

This creates two tunnel groups called ANYCONN_1 and ANYCONN_2. Iโ€™ve assigned the first pool to the first tunnel group and the second pool to the second.

Here Iโ€™m using the โ€œgroup-aliasโ€ command, which creates a drop-down box on the AnyConnect client on the userโ€™s PC. Users will see they can select either Employees or Vendors as options. The configuration weโ€™re creating will allow people in the first group to connect only to the first tunnel group and users in the second group only to the second.

Note that the โ€œauthentication-server-groupโ€ command could be different in these two tunnel groups. So I could send my employees to one RADIUS server (perhaps one thatโ€™s integrated with my LDAP, or equivalently, I could use LDAP natively on the firewall) and the vendors to a different one.

4. Set group policies

Now we need group policies. In fact, we need three of them. We need a group policy for employees and a second one for vendors. The third policy is for anybody who somehow passed their authentication but failed their authorization. That is, they had valid credentials for logging in but they arenโ€™t authorized to use the VPN.

The main reason this could happen is if theyโ€™ve simply selected the wrong profile. But itโ€™s also possible I could have people who simply arenโ€™t authorized to use the VPN at all, even though they have legitimate credentials. This could happen because the same authentication system is used for many things.

!
group-policy STAFF_VPN_GROUP internal
group-policy STAFF_VPN_GROUP attributes
 vpn-tunnel-protocol ssl-client
 vpn-filter value STAFF_VPN_ACL
!
group-policy VENDOR_VPN_GROUP internal
group-policy VENDOR_VPN_GROUP attributes
 vpn-tunnel-protocol ssl-client
 vpn-filter value VENDOR_VPN_ACL
!
group-policy NOACCESS internal
group-policy NOACCESS attributes
 vpn-tunnel-protocol ssl-client
 vpn-simultaneous-logins 0
!

Where do these names come from? This is where things get a little bit confusing, so bear with me. The group policy names, STAFF_VPN_GROUP and VENDOR_VPN_GROUP, are values supplied by either the RADIUS or LDAP server. The server must be configured so that, upon successful authentication, it hands back these values in its IETF type 25 field, also called Class. And it must be in a specific format: OU=STAFF_VPN_GROUP; (with the semicolon).

One other important little bit of configuration that I want to mention is the โ€œvpn-filterโ€ command. This applies a special ACL (access control list) to these users and allows us to restrict what they can and canโ€™t access. For example, if I wanted to allow the employee group to access anything in the corporate network, but to restrict the vendors to only access a particular subnet, I could do this:

!
access-list STAFF_VPN_ACL extended permit ip any any
access-list VENDOR_VPN_ACL extended permit ip any 10.99.99.0 255.255.255.0
!

5. Apply the configuration

Finally, we need to apply the configuration to the OUTSIDE interface of the firewall:

!
webvpn
 enable OUTSIDE
 anyconnect enable
 tunnel-group-list enable
!

Authenticating logic flow for Cisco AnyConnect VPN

Letโ€™s review the logical flow in this configuration example.

First, the user opens their AnyConnect client. They connect to the hostname (or IP address) of our ASAโ€™s outside interface. As soon as they connect, they get a login screen in which they can pick either Employees or Vendors from a drop-down menu. They enter their user ID and login credentials. So far weโ€™re just in the tunnel group section of the configuration.

Then the login credentials are sent to the authentication server group configured for this tunnel group. If the authentication is successful, the RADIUS server will return a value, RADIUS attribute IETF-25 (also called Class). That value includes the name of the group policy this user should be in.

At this point, we could have several different group policies for different groups of users, all of whom connected using the same drop-down menu. We could assign a different ACL to each of them to restrict what they could access depending on their group. This mechanism can only select one group policy. If you want a user to be in multiple groups, youโ€™ll need to get creative with your tunnel groups.

In the tunnel group configuration, weโ€™ve defined a catchall default group policy thatโ€™s called NOACCESS. If the RADIUS server sends back something the ASA doesnโ€™t understand, or perhaps nothing at all, then the user gets assigned to this group policy. For the sake of security, we want to deny access in these cases. We do this by making this NOACCESS group policy allow 0 simultaneous logins for each user ID:

vpn-simultaneous-logins 0

For those users who successfully gain access, we can apply an ACL using the โ€œvpn-filterโ€ command. This is an ACL applied on the firewall itself for connections heading to the destinations. So we put the specifically allowed or denied addresses in the โ€œdestinationโ€ part of the ACL:

access-list  extended permit ip any 10.99.99.0 255.255.255.0
VENDOR_VPN_ACL

The biggest mistake Iโ€™ve seen in Cisco AnyConnect VPN configurations is to set the default group policy in the tunnel group to allow access. You should always deny by default.

Follow this simple workflow, and you should have a straightforward, easily adaptable process to configure your Cisco AnyConnect VPN.


Looking to learn more about VPNs? You might be interested in these related articles:

Get templates for network assessment reports, presentations, pricing & moreโ€”designed just for MSPs.

Ebook cover - The Ultimate Guide to Selling Managed Network Services
  1. Dinakar Avatar
    Dinakar

    Is a certificate mandatory in ASA for setting up anyconnect IPSEC VPN?

    1. Ryan LaFlamme Avatar

      Hi Dinakar,

      While a 3rd party trusted certificate installed on the ASA is definitely recommended, it is not required for the AnyConnect VPN to function. If you don’t supply one, the ASA (like most other firewalls) will use a self-signed certificate. When your users connect, they’ll see a warning – but still be able to connect. Beyond the inconvenience this warning causes, it also trains users on the wrong behavior, which is to “Connect Anyway”. You wouldn’t want them to do that when browsing the web (it could be a sign of a malicious, but lazy, MITM attack), so you don’t want them coming to accept that clicking “Connect Anyway” is OK.

  2. Craig Pitkin Avatar
    Craig Pitkin

    Hi Kevin ,

    I am trying to do this in a similar way but using a single tunnel group and then applying a deny policy to it .
    I then have 2 other group policies . ISE puts the user in the correct group but I see a deny due to “simultaneous logins exceeded” I think due to the login 0 command . Any ideas ?

    group-policy GroupPolicy_DENY internal
    group-policy GroupPolicy_DENY attributes
    vpn-simultaneous-logins 0

    tunnel-group VPN type remote-access
    tunnel-group VPN general-attributes
    address-pool VPN-USERS
    authentication-server-group RADIUS
    authorization-server-group RADIUS
    default-group-policy GroupPolicy_DENY
    strip-realm
    authorization-required

    group-policy GroupPolicy_CORP internal
    group-policy GroupPolicy_CORP attributes
    wins-server none
    dns-server value 10.213.100.11 10.213.100.12
    vpn-filter value CORP
    vpn-tunnel-protocol ikev2 ssl-client
    split-tunnel-policy tunnelspecified
    split-tunnel-network-list value CORP-SPLIT
    default-domain value xxxxxxxxx

    group-policy GroupPolicy_SALES internal
    group-policy GroupPolicy_SALES attributes
    wins-server none
    dns-server value 10.213.100.11 10.213.100.12
    vpn-filter value SALES
    vpn-tunnel-protocol ikev2 ssl-client
    split-tunnel-policy tunnelspecified
    split-tunnel-network-list value SALES-SPLIT
    default-domain value xxxxxxxxx

Leave a Reply

Your email address will not be published. Required fields are marked *