List of content you will read in this article:
- 1. Configure AAA authentication
- 2. Define VPN protocols
- 3. Configure tunnel groups
- 4. Set group policies
- 5. Apply the configuration
- 6. Authenticating logic flow
- 7. Final Words
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
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
tunnel-group ANYCONN_1 webvpn-attributes
group-alias EMPLOYEES enable
tunnel-group ANYCONN_2 type remote-access
tunnel-group ANYCONN_2 type general-attributes
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-filter value STAFF_VPN_ACL
group-policy VENDOR_VPN_GROUP internal
group-policy VENDOR_VPN_GROUP attributes
vpn-filter value VENDOR_VPN_ACL
group-policy NOACCESS internal
group-policy NOACCESS attributes
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:
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:
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
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.
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: