Why Anyconnect SSL VPN.
- Cisco Split-tunnel-policy Tunnelall
- Split Tunnel Policy Tunnelspecified Asa
- Split-tunnel-policy Tunnelspecified
Cisco AnyConnect is one of the most popular method of remote access. Since the Cisco stopped develop IPsec VPN Client, you should consider AnyConnect in current deployments. Depending on the licence model, it provide many features like for example Clientless SSL VPN access or Cisco Secure Desktop. You can find more detailed licences description on Cisco site. My project didn’t require client less access so Essential license was enough.
Project Requirement.
Last project I worked on, included three main requirements:
- Users Accounts and tokens are provided from RSA SecureID.
- Different VPN Policies for different users groups.
- Dynamic access policies for contractors and external support.
Users Accounts.
I received an ready to use RSA SecureID server with implemented tokens and integrated with Active Directory. So it’s no necessary to set cooperation between Cisco ASA and AD for users accounts, all is delivered from RSA server.
There are two options for integrate Cisco ASA and RSA Server, using SDI or RADIUS. Under this link you can find more detailed description, about this two protocols. In my case I didn’t use ACS, so by choosing a RADIUS I could assign a radius attributes to Users.
Radius Configuration:
Group-policy Profile-SSL-VPN internal group-policy Profile-SSL-VPN attributes vpn-simultaneous-logins 4 vpn-idle-timeout 10 vpn-session-timeout 60 vpn-tunnel-protocol ssl-client ssl-clientless split-tunnel-policy tunnelspecified split-tunnel-network-list value Split-Tunnel default-domain value xxxxxxxxxx.com address-pools value SSL-VPN-POOL. The code attached is the un-changed code that works with the Cisco VPN client but without Internet browsing and no split-tunnel active. When I add the commands of access-list SPLIT-TUNNEL standard permit 192.168.150.0 255.255.255.0 split-tunnel-policy tunnelspecified split-tunnel-network-list value SPLIT-TUNNEL. Group-policy VPNPOLICY internal group-policy VPNPOLICY attributes dns-server value 8.8.8.8 vpn-idle-timeout 15 split-tunnel-policy tunnelspecified split-tunnel-network-list value SPLITTUNNEL! Group-policy VPNPOLICY internal group-policy VPNPOLICY attributes dns-server value 8.8.8.8 vpn-idle-timeout 15 split-tunnel-policy tunnelspecified split-tunnel-network-list value SPLITTUNNEL! Username VPNUSER password MYPASSWORD tunnel-group MYTUNNEL type remote-access tunnel-group MYTUNNEL general-attributes address-pool VPNPOOL.
Under RSA Secure Console go to RADIUS -> RADIUS CLIENTS -> ADD NEW and configure all mandatory parameters:
Next, go to ASA and add radius server:
VPN Policies.
One of the most important requirement was to implement different access policies for three user’s categories: Standard, IT Users, and External Support/Contractors.
Because Cisco ASA can assign a user to the group policy based on their OU group, thats gives a pretty flexible solution for applying a policies to the vpn session. This is possible by a RADIUS attribute 25. During authentication process of an VPN session Cisco ASA tries to match a value from RADIUS attribute 25 with configured group policies. When the attribute 25 value = Group-Policy name, then all policies from this group are applied. When no group-policy is found, then ASA applies group-policies configured with tunnel-group.
Cisco Split-tunnel-policy Tunnelall
So in this case, you can assign radius attribute to the user under RSA Secure Console, and configure an adequate group-policy on the Cisco ASA.
To do this go to Secure Console: RADIUS -> RADIUS Profiles -> Add New and set a profile like this:
Attribute Class[M] is an attribute 25.
Split Tunnel Policy Tunnelspecified Asa
Next, this profile should be assign to user account, to do this go to Identity -> Users -> Manage Existing, search for the user and by right click go to User Authentication Setting. Under a RADIUS section choose configured profile from User RADIUS Profile list.
On Cisco ASA configure a group-policy with with the same name like Profile Name from the screen above, for example:
So in this way, it is possible to apply different policies to the user categories mention in the project.
Dynamic Access Policies.
Additionally when you need to apply additional setting like for example access-list on a vpn session or access method, etc. Dynamic Access Policies is a good option for that. It can be configured only over ASDM. Go to Remote Access VPN -> Network (Client) Access -> Dynamic Access Policies. Add a new policy, under Selection Criteria set a radius.25 attribute value, and at the bottom you can configure additional options like for example Network ACL Filters (client) which refer to the proper Access-List:
So as a final result this configuration when a VPN session is established an user with radius profile ITuser got a setting from group-policy ITuser and access only to resources defined in Dynamic Access Policy ITUser.
This is a brief description of the concept, I decided to not describe a whole configuration on AnyConnect VPN, because there is a lot information about that in the Internet. It’s only proposal, for this kind of requirements. I hope you will find something interesting for your design.
Split tunneling controls what traffic is or isn’t protected by the tunnel. By default the Easy VPN server forces the client to tunnel all user traffic to the server; you can ease this restriction and define split tunneling policies for your users, which your server downloads to the remote and which the remote enforces.
Split tunneling defines what traffic from the user must go across the tunnel and what traffic can leave the client in clear text. Split tunneling policies are defined with the split- tunnel-policy command. The default split-tunneling policy is tunnelall, which means that, with the exception of DHCP and ARP packets, all traffic from the remote must go across the tunnel. You can exclude networks from being tunneled (excludespecified parameter) or include networks that should only be tunneled (tunnelspecified parameter). When overriding the default split tunneling policy, you must use the split-tunnel-network-list command to specify what destination networks are (tunnelspecified) or are not tunneled (excludespecified). These are defined in an extended or standard ACL. For a standard ACL, the addresses or networks you enter are addresses that the remote is trying to reach (destination addresses). For an extended ACL, the addresses off of the higher-level interface of the appliance (corporate office networks) are the source addresses in an ACL statement, and the destination addresses are the internal addresses of the remotes.
Also, if you have split tunneling disabled (the default), this means that all remote access traffic has to come to the appliance first, before it goes anywhere else, including the Internet. In this case, the appliance by default drops traffic that enters and leaves the same interface. To allow this behavior, configure this command:
Split-tunnel-policy Tunnelspecified
ciscoasa(config)# same-security-traffic permit intra-interface