Worldwide Locations
There are some common misconceptions on the part of some of my students as to how VPN sessions are established from either a remote location or remote user to the ASA firewall. In particular, a “gray area” seems to be when the attributes from the tunnel group are applied versus the attributes particular to the group policy associated with the user.
This flowchart shows the VPN connection process and decision points that occur both before and after a user would “log in” to gain access.
Let’s examine the flow starting with the entering arrow on the left. A packet first arrives which needs to be matched to a tunnel group. If an ISAKMP/IKE (Internet Security Association Key Management Protocol/Internet Key Exchange) packet is used in IKE Phase I Main Mode, an IP Address or digital certificate is matched to determine the tunnel group.
If a Phase I Aggressive Mode is used instead (preshared key remote access), the presented Group Name is matched against the Tunnel Group name. Note that in the chart, the usage of a Group Name is associated with IPSec Remote Access, while the IP Address identification correlates to a Site-to-Site VPN.
Since Cisco implements SSL VPNs strictly for Remote Access, the TCP port 443 connection (HTTPS/SSL) attempt can only be matched against one type of SSL VPN Tunnel Group. For this VPN type, either a digital certificate or a selectable Group Alias/Group URL is used to identify the tunnel group. If none of the criteria identified for either IPSec or SSL VPNs match what is configured on the ASA, we say that the VPN “lands” on a default L2L (LAN-to-LAN; another name for Site-to-Site), RA (Remote Access), or WebVPN tunnel group, usually an undesired situation.
So far we have been examining what happens with either a Site-to-Site IPSec (where there is no user login) or Remote Access IPSec/SSL VPNs in the “pre-login” phase.
For the latter case, once the user successfully authenticates, the ASA needs to associate the appropriate group policy to the user, seen in the right-hand side of the chart. If the username is defined locally on the ASA, the applicable policy is easily derived from this entry.
Externally defined users present a more challenging situation, however. In this second scenario, the administrator would need to define a RADIUS or LDAP attribute associated with the user on the external server which would be returned in the authorization response.
Author: Doug McKillip
References: