{"id":186,"date":"2015-06-23T06:54:19","date_gmt":"2015-06-23T06:54:19","guid":{"rendered":"http:\/\/www.balajibandi.com\/blog\/?p=186"},"modified":"2017-02-05T17:55:44","modified_gmt":"2017-02-05T17:55:44","slug":"using-the-cisco-routers-local-database-to-apply-different-policies-for-cisco-ios-anyconnect-users-part1","status":"publish","type":"post","link":"https:\/\/www.balajibandi.com\/?p=186","title":{"rendered":"Using the Cisco Router\u2019s Local Database to Apply Different Policies for Cisco IOS AnyConnect Users (part1)"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

IOS WebVPN Group Lock<\/strong><\/p>\n

On the Cisco IOS, the group lock feature provides a way to \u201clock down\u201d a particular (EzVPN) group so that only certain users can connect to that group. For example, in the configuration snippet below, only \u2018user1@GROUP1\u2032 will be able to connect to GROUP1 because group lock is enabled on that group; however, both \u2018user1@GROUP1\u2032 and \u2018user2@GROUP2\u2032 can connect to GROUP2 because group lock is not enabled under that group.<\/p>\n

\n
    \n
  1. username user1@GROUP1 password 0 cisco1<\/span><\/li>\n
  2. username user2@GROUP2 password 0 cisco2<\/span><\/li>\n
  3. !<\/span><\/li>\n
  4. crypto isakmp client configuration group GROUP1<\/span><\/li>\n
  5. key cisco<\/span><\/li>\n
  6. pool POOL<\/span><\/li>\n
  7. group-lock<\/span><\/li>\n
  8. save-password<\/span><\/li>\n
  9. !<\/span><\/li>\n
  10. crypto isakmp client configuration group GROUP2<\/span><\/li>\n
  11. key cisco<\/span><\/li>\n
  12. pool POOL<\/span><\/li>\n
  13. save-password<\/span><\/li>\n<\/ol>\n<\/div>\n

    Note<\/strong>: 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.<\/p>\n

    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.<\/p>\n

    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 \u2013 Sales and Administrator \u2013 with different policies and then configure the Sales staff with an authentication domain of \u201cSales\u201d and the Administrator with an authentication domain of \u201cAdministrator.\u201d<\/p>\n

    Let me use the following lab setup to show you how it works:<\/p>\n

    \"\"<\/p>\n

    The configuration on the router is as follows:<\/p>\n

    \n
      \n
    1. aaa new-model<\/span><\/li>\n
    2. aaa authentication login webvpn local<\/span><\/li>\n
    3. !<\/span><\/li>\n
    4. crypto pki trustpoint TP-self-signed-4279256517<\/span><\/li>\n
    5. enrollment selfsigned<\/span><\/li>\n
    6. subject-name cn=IOS-Self-Signed-Certificate-4279256517<\/span><\/li>\n
    7. revocation-check none<\/span><\/li>\n
    8. rsakeypair TP-self-signed-4279256517<\/span><\/li>\n
    9. !<\/span><\/li>\n
    10. username user1@Sales secret cisco<\/span><\/li>\n
    11. username user2@Administrator secret cisco<\/span><\/li>\n
    12. !<\/span><\/li>\n
    13. interface FastEthernet0\/0<\/span><\/li>\n
    14. ip address 41.1.1.2 255.255.255.0<\/span><\/li>\n
    15. !<\/span><\/li>\n
    16. interface FastEthernet0\/1<\/span><\/li>\n
    17. ip address 192.168.10.1 255.255.255.0<\/span><\/li>\n
    18. !<\/span><\/li>\n
    19. interface Virtual-Template1<\/span><\/li>\n
    20. ip unnumbered FastEthernet0\/1<\/span><\/li>\n
    21. !<\/span><\/li>\n
    22. ip local pool ANYCONNECT_POOL 192.168.10.51 192.168.10.60<\/span><\/li>\n
    23. !<\/span><\/li>\n
    24. ip http server<\/span><\/li>\n
    25. ip http secure-server<\/span><\/li>\n
    26. !<\/span><\/li>\n
    27. ip access-list standard SPLIT_ACL<\/span><\/li>\n
    28. permit 192.168.10.0 0.0.0.255<\/span><\/li>\n
    29. !<\/span><\/li>\n
    30. ip access-list extended Administrator_ACL<\/span><\/li>\n
    31. permit ip any any<\/span><\/li>\n
    32. ip access-list extended Sales_ACL<\/span><\/li>\n
    33. permit tcp any host 192.168.10.100 eq 80<\/span><\/li>\n
    34. !<\/span><\/li>\n
    35. webvpn gateway AnyConnect_RTR<\/span><\/li>\n
    36. ip address 41.1.1.2 port 443<\/span><\/li>\n
    37. ssl trustpoint TP-self-signed-4279256517<\/span><\/li>\n
    38. inservice<\/span><\/li>\n
    39. !<\/span><\/li>\n
    40. webvpn install svc disk0:\/webvpn\/anyconnect-linux-3.1.08009-k9.pkg sequence 1<\/span><\/li>\n
    41. !<\/span><\/li>\n
    42. webvpn context Sales<\/span><\/li>\n
    43. ssl authenticate verify all<\/span><\/li>\n
    44. !<\/span><\/li>\n
    45. policy group Sales_Policy<\/span><\/li>\n
    46. functions svc-enabled<\/span><\/li>\n
    47. filter tunnel Sales_ACL<\/span><\/li>\n
    48. svc address-pool “ANYCONNECT_POOL”<\/span><\/li>\n
    49. svc keep-client-installed<\/span><\/li>\n
    50. svc split include 192.168.10.0 255.255.255.0<\/span><\/li>\n
    51. !<\/span><\/li>\n
    52. virtual-template 1<\/span><\/li>\n
    53. default-group-policy Sales_Policy<\/span><\/li>\n
    54. aaa authentication list webvpn<\/span><\/li>\n
    55. aaa authentication domain @Sales<\/span><\/li>\n
    56. gateway AnyConnect_RTR domain Sales<\/span><\/li>\n
    57. inservice<\/span><\/li>\n
    58. !<\/span><\/li>\n
    59. webvpn context Administrator<\/span><\/li>\n
    60. ssl authenticate verify all<\/span><\/li>\n
    61. !<\/span><\/li>\n
    62. policy group Administrator_Policy<\/span><\/li>\n
    63. functions svc-enabled<\/span><\/li>\n
    64. filter tunnel Administrator_ACL<\/span><\/li>\n
    65. svc address-pool “ANYCONNECT_POOL”<\/span><\/li>\n
    66. svc keep-client-installed<\/span><\/li>\n
    67. svc split include 192.168.10.0 255.255.255.0<\/span><\/li>\n
    68. !<\/span><\/li>\n
    69. virtual-template 1<\/span><\/li>\n
    70. default-group-policy Administrator_Policy<\/span><\/li>\n
    71. aaa authentication list webvpn<\/span><\/li>\n
    72. aaa authentication domain @Administrator<\/span><\/li>\n
    73. gateway AnyConnect_RTR domain Administrator<\/span><\/li>\n
    74. inservice<\/span><\/li>\n<\/ol>\n<\/div>\n

      The only difference between the WebVPN contexts in our configuration are the tunnel filters that are applied: the \u201cSales\u201d context has the \u201cSales_ACL\u201d applied, which only allows HTTP to host 192.168.10.100 while the \u201cAdministrator\u201d context has the \u2018Administrator_ACL\u2019 applied, which permits all traffic.<\/p>\n

      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.<\/p>\n

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

      For testing purposes, I already have the AnyConnect client installed on my laptop so I will use this to connect.<\/p>\n

      \"\"<\/p>\n

      When the user enters his\/her username, the domain through which the user connects is attached in the form of username@domain<\/a> and this is what is authenticated against the defined AAA authentication method list (in our case \u2018webvpn\u2019 which uses local database). Therefore, in the screenshot above, \u201cuser1@Sales<\/a>\u201d is the value sent to the local DB of the router for authentication. That is the reason we configured our usernames in that format.<\/p>\n

      After successful authentication, users connected to the Sales context should only be able to open HTTP to 192.168.10.100, so let\u2019s test this.<\/p>\n

      \"\"<\/p>\n

      As you can see, the HTTP connection to 192.168.10.100 goes through but the ping doesn\u2019t. Now I will disconnect and connect to the Administrator context using \u2018user2\u2032.<\/p>\n

      \"\"<\/p>\n

      This user should have unrestricted access so both ping and HTTP should work.<\/p>\n

      \"\"<\/p>\n

      If I run the command debug webvpn aaa<\/em><\/strong>, 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, \u201cuser1@Administrator<\/a>\u201d will be sent for authentication, which does not match any configured username so the authentication fails.<\/p>\n

      \"\"<\/p>\n

      Summary<\/strong><\/p>\n

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

      In the next article, I will show you another method which I feel is better. I hope you have found this article helpful.<\/p>\n

      References and Further Reading<\/strong><\/p>\n