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.

CCNA Training – Resources (Intense)

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.

username user1@GROUP1 password 0 cisco1
username user2@GROUP2 password 0 cisco2
!
crypto isakmp client configuration group GROUP1
 key cisco
 pool POOL
 group-lock
 save-password
!
crypto isakmp client configuration group GROUP2
 key cisco
 pool POOL
 save-password

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:

aaa new-model
aaa authentication login webvpn local
!
crypto pki trustpoint TP-self-signed-4279256517
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-4279256517
 revocation-check none
 rsakeypair TP-self-signed-4279256517
!
username user1@Sales secret cisco
username user2@Administrator secret cisco
!
interface FastEthernet0/0
 ip address 41.1.1.2 255.255.255.0
!
interface FastEthernet0/1
 ip address 192.168.10.1 255.255.255.0
!
interface Virtual-Template1
 ip unnumbered FastEthernet0/1
!
ip local pool ANYCONNECT_POOL 192.168.10.51 192.168.10.60
!
ip http server
ip http secure-server
!
ip access-list standard SPLIT_ACL
 permit 192.168.10.0 0.0.0.255
!
ip access-list extended Administrator_ACL
 permit ip any any
ip access-list extended Sales_ACL
 permit tcp any host 192.168.10.100 eq 80
!
webvpn gateway AnyConnect_RTR
 ip address 41.1.1.2 port 443
 ssl trustpoint TP-self-signed-4279256517
 inservice
 !
webvpn install svc disk0:/webvpn/anyconnect-linux-3.1.08009-k9.pkg sequence 1
 !
webvpn context Sales
 ssl authenticate verify all
 !
 policy group Sales_Policy
   functions svc-enabled
   filter tunnel Sales_ACL
   svc address-pool "ANYCONNECT_POOL"
   svc keep-client-installed
   svc split include 192.168.10.0 255.255.255.0
 !
 virtual-template 1
 default-group-policy Sales_Policy
 aaa authentication list webvpn
 aaa authentication domain @Sales
 gateway AnyConnect_RTR domain Sales
 inservice
!
webvpn context Administrator
 ssl authenticate verify all
 !
 policy group Administrator_Policy
   functions svc-enabled
   filter tunnel Administrator_ACL
   svc address-pool "ANYCONNECT_POOL"
   svc keep-client-installed
   svc split include 192.168.10.0 255.255.255.0
 !
 virtual-template 1
 default-group-policy Administrator_Policy
 aaa authentication list webvpn
 aaa authentication domain @Administrator
 gateway AnyConnect_RTR domain Administrator
 inservice

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 to https://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