Anyconnect server is a safe and mobile client workaround for secure VPN accessibility in the teleworking apparatus, providing highly secure access to the remote-work network using any device from anywhere at any time. This elevated work surface is free to cost for businesses or even home-office networks. 

This is a very easy, widely used and safe method when you want to work from home or anywhere in the world; it offers you secure access without the risk of being hacked, is fast, and doesn't cost much. 

In other words, and in short, Anyconnect is a more optimized alternative to the old Cisco VPN client and supports SSL and IKEv2 IPsec. Regarding SSL, the ASA provides two SSL VPN modes: Clientless and WebVPN. In the following, we consider the workaround ins and outs.

The Drawback of Anyconnect Solution

The trouble with this method is that people and organizations are unfamiliar with it—there is no good documentation to teach how to work with it. To prevent the drawback, we create this article, so join us in solving this problem.

Configure AAA authentication

The first step to configure Anyconnect is AAA authentication; a good lever is to use RADIUS for authentication and authorization; however, there are other choices, such as LDAP. The configuration is similar:

________________________________

aaa-server MYRADIUS protocol radius

aaa-server MYRADIUS (INSIDE) host 10.10.1.1

 key ****

____________________________________________________________

The configuration fragment asserts that I have a RADIUS server inside my network through IP address 10.10.1.1, which I refer to by the tag “MYRADIUS” in the ASA configuration. It’s available on the ASA interface, called “INSIDE”, in the interface configuration.

Define VPN protocols

As far as users connect their VPN, they have to get an IP address for the VPN session. This address will show up inside the corporate network for the user. It has nothing to do with the user’s public IP address or any address they may have inside their home office network. It’s merely gotten on the network the insider after the remote user’s traffic has passed by 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 touched off two pools here because I would go for multiple tunnel groups in this respect then.

Configure tunnel groups

The next step begins when I configure my tunnel groups of mine. I’m going to create two other groups alike for reasons I have to explain later around.

______________________________________________________________

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 produces two different tunnel groups named ANYCONN_1 and ANYCONN_2; I’ve assigned the first pool to the first tunnel group and the second pool to the second one.

I’m leveraging the “group-alias” command that makes a drop-down box on the AnyConnect client on the user’s PC. Users will see that they can select Employees and Vendors as options. The configuration we’re creating will permit users in the first group to connect just to the first tunnel group and users in the second group solely to the second one.

Remember that the “authentication-server-group” command could also be different in these two tunnel groups. Thus, I could send over my employees to one RADIUS server—maybe one that’s integrated with my LDAP, or even I could use LDAP naturally on the firewall; and the vendors otherwise.

Set group policies

In this stage, we have to establish group policies. I need three sorts of policies. We need a group policy in groups includes:

  • For employees;
  • For vendors;
  • Anybody who somehow passed their authentication but failed their authorization, which means they had valid credentials for logging in but aren’t authorized to use the VPN.

This could happen mainly if they’ve selected the wrong profile. That it’s possible I could have people who aren’t authorized to utilize the VPN, even when they have to have legitimate credentials. This could happen due to the same authentication system used for many hurdles.

_______________________________________________________________

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 issues get a little bit complicated, so stay sharp. The group policies, STAFF_VPN_GROUP and VENDOR_VPN_GROUP, are values supplied by the RADIUS and LDAP servers. The server should be configured so that it hands back these values in its IETF type 25 field by a successful authentication called Class as well. 

  • It should be in a certain format: OU=STAFF_VPN_GROUP; (with the semicolon).

The momentous issue, a little configuration that I need to mention, is the “vpn-filter” command. This provides a special ACL (access control list) to these users and allows us to restrict what they can do so, and can’t be accessed. For instance, if I wanted the employee group to have access to anything in the corporate network but to restrict the vendors only to 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

_______________________________________________________

Apply the configuration

In the end, we have to apply the configuration to the OUTSIDE interface of the firewall:

_________________________

webvpn

 enable OUTSIDE

 anyconnect enable

 tunnel-group-list enable

____________________________________________

Authenticating logic flow

Here we are going through the logical flow example in this configuration.

Firstly, the users open their AnyConnect client. They can’t access our ASA's outside interface's hostname (or IP address). As soon as they get connected, they receive a login screen in which they can pick Employees or Vendors from a drop-down menu. They enter their user ID and login credentials, as far as we’re only 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 maintains the name of the group policy this user should have been in.

  • At this level, we can have several group policies for several groups of users, all connected while using the same drop-down menu.

We could assign a different ACL to each of them to restrict what they could access contingent upon their group. This mechanism can only select one certain group policy. You must be creative with your tunnel groups if you want a user in multiple groups.

In the tunnel group configuration, we’ve verified a catchall default group policy called NOACCESS. If the RADIUS server sends back and some of the ASA doesn’t read, or maybe nothing at all, after that, 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 every single user ID:

vpn-simultaneous-logins 0

For those users, who have access glibly and with ease, we can also set up an ACL using the “vpn-filter” command. This ACL is applied on the firewall for the connections head-on to the destinations. So, we put the specifically eligible 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 error I’ve seen in AnyConnect configurations is putting the default group policy ahead in the tunnel group to allow access. You have to deny it every time.

Final Words

Whether you want to provide access to work emails or professional administration, we have seen the advantages of Anyconnect and how to set it up in this article. If you want to use our consulting services, facilities, and products, email us. So don't be hesitant, and place your order.

People also read: