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.

It trends 2024: industry report

Planning for the year ahead?

Find out how IT professionals are managing day-to-day operations, dealing with talent shortages, and preparing for future needs.

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:

It trends 2024: industry report

Planning for the year ahead?

Find out how IT professionals are managing day-to-day operations, dealing with talent shortages, and preparing for future needs.

  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

  3. ibrahim hamid Avatar
    ibrahim hamid

    Dear Dr. Kevin Dooley,

    Thank you for good information about the VPN configuration, you made simple to understand .. THANK YOU.

    I have just one question, if I do not have a Radus server, can the VPN remote user be authenticated using a command in the firewall, if so what will be the command to replace (authentication-server-group MYRADIUS) looks like.

    Thank you

Leave a Reply

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