Using the Cisco Router’s Local Database to Apply Different Policies for Cisco IOS AnyConnect Users (part1)

June 23, 2015 / Balaji Bandi / 0 Comments

The title for this article is quite long but it is for a reason: I was faced with this situation some time ago and, after typing in this search term in Google, I could not get a definitive answer. Somehow though, I was able to figure it out and this article will document my solution with the hope that it will help someone else.

When it comes to providing network access to a user (e.g., via a remote access VPN like AnyConnect VPN), it is usually beneficial to be able to apply different policies to different users. For example, a sales staff should only be able to access the sales network subnet, but an administrator should have full access to the network.

Applying different policies to users is mostly achieved by downloading the policies from external AAA servers; however, there are times when it is desirable to be able to configure and apply these policies locally on the device terminating the VPN tunnel.

On the Cisco ASA, this is very easy to achieve because different group policies can be configured and these policies can then be attached to usernames configured on the Cisco ASA. On Cisco routers, however, things are not as clear-cut.

In this article, I will show you one of the ways by which we can apply different policies to WebVPN/AnyConnect users by relying solely on the local database of the Cisco router terminating the VPN tunnel. In summary, there will be no RADIUS or TACACS+ involved.

IOS WebVPN Group Lock

On the Cisco IOS, the group lock feature provides a way to “lock down” a particular (EzVPN) group so that only certain users can connect to that group. For example, in the configuration snippet below, only ‘user1@GROUP1′ will be able to connect to GROUP1 because group lock is enabled on that group; however, both ‘user1@GROUP1′ and ‘user2@GROUP2′ can connect to GROUP2 because group lock is not enabled under that group.

Note: The IOS EzVPN group lock is a bit different from the group lock feature on the Cisco ASA where a user is tied to a particular tunnel group; i.e., that user cannot connect to any other tunnel group. On the Cisco IOS, we can say it is the group that is locked; not necessarily the user.

The concept of group lock on the Cisco IOS can be extended to WebVPN. For WebVPN, we use authentication domains to tie a user to a particular WebVPN context. So, in essence, the IOS WebVPN group lock feature is similar to the group lock feature on the Cisco ASA.

You may be wondering how all of this is relevant to applying different policies to users. Well, if we can lock a user to a particular WebVPN context, it means that user will be subject to the policy defined under that context. To use our previous example again, we can create two WebVPN contexts – Sales and Administrator – with different policies and then configure the Sales staff with an authentication domain of “Sales” and the Administrator with an authentication domain of “Administrator.”

Let me use the following lab setup to show you how it works:

The configuration on the router is as follows:

The only difference between the WebVPN contexts in our configuration are the tunnel filters that are applied: the “Sales” context has the “Sales_ACL” applied, which only allows HTTP to host 192.168.10.100 while the “Administrator” context has the ‘Administrator_ACL’ applied, which permits all traffic.

The first thing we need to note is that the way users access the WebVPN service is now different. Without authentication domains configured, a user just needs to go to https://<webvpn-server-ip-address>/ (or http:// if HTTP port redirection is enabled) to access the WebVPN service. However, with authentication domains, the user has to specify the context he/she is connecting to.

Therefore, user1 will go to https://41.1.1.2/Sales while user2 will go tohttps://41.1.1.2/Administrator. The same thing applies if users are connecting via the AnyConnect client – instead of just specifying the IP address or hostname of the WebVPN server, they must also specify the context.

For testing purposes, I already have the AnyConnect client installed on my laptop so I will use this to connect.

When the user enters his/her username, the domain through which the user connects is attached in the form of username@domain and this is what is authenticated against the defined AAA authentication method list (in our case ‘webvpn’ which uses local database). Therefore, in the screenshot above, “user1@Sales” is the value sent to the local DB of the router for authentication. That is the reason we configured our usernames in that format.

After successful authentication, users connected to the Sales context should only be able to open HTTP to 192.168.10.100, so let’s test this.

As you can see, the HTTP connection to 192.168.10.100 goes through but the ping doesn’t. Now I will disconnect and connect to the Administrator context using ‘user2′.

This user should have unrestricted access so both ping and HTTP should work.

If I run the command debug webvpn aaa, we can confirm that user1 cannot access the Administrator context (and user2 cannot access the Sales context). If user1 tries to access the Administrator context, “user1@Administrator” will be sent for authentication, which does not match any configured username so the authentication fails.

Summary

In this article, we have covered one of the ways—the group lock feature—by which we can apply different policies to WebVPN/AnyConnect VPN users by using the local database of the terminating router.

In the next article, I will show you another method which I feel is better. I hope you have found this article helpful.

References and Further Reading

• ASA and Cisco IOS Group-lock Features and AAA Attributes and WebVPN Configuration Example:http://www.cisco.com/c/en/us/support/docs/security/ios-easy-vpn/117634-configure-asa-00.html