Setup for an IPSec remote-access connection is more complex than that for an L2L connection. Basically, when setting up an IPSec remote access connection, seven steps occur:
The following sections cover these steps in more depth.
In Step 1, the client initiates the IPSec connection to the server. The same kinds of things that occur with an L2L connection in this step also occur with the remote-access client. Based on the client's authentication configuration, the client uses one of the two following connection modes:
Aggressive mode? Used if the client is configured for preshared keys. (When using this mode, Cisco recommends that your client device have a unique host name and that the identity type be configured for host name, not IP address. On Cisco EVC routers, this is done with the crypto isakmp identity hostname command.)
Main mode? Used if the client is configured for certificates using RSA signatures.
In Step 2, the client creates a list of its IKE Phase 1 policies. This is done by having the client generate all possible combinations of parameters for IKE Phase 1 components that it supports (and that are supported by EasyVPN). These parameters include encryption algorithms, hashing functions, DH groups, and authentication methods. For example, assume that the client supports the following:
Encryption algorithms? DES, 3DES
Hash functions? SHA, MD5
DH group? 2
Authentication? RSA signatures
Here is the list of policies that the client would create based on the supported IKE Phase 1 parameters previously listed:
3DES, SHA, DH 2, RSA signatures
3DES, MD5, DH 2, RSA signatures
DES, SHA, DH 2, RSA signatures
DES, MD5, DH 2, RSA signatures
This process reduces the manual configuration of these policy lists on the client. The client then sends its list of IKE Phase 1 policy permutations to the server.
In Step 3, the server accepts one of the client's IKE Phase 1 policy proposals. The server does this by comparing its own IKE Phase 1 policies with the client's policies, starting with the server's highest-priority policy (the one with the lowest number). Based on this process, make sure that the server's list of policies has the most secured policies in the highest-priority policies, and the least secured policies with the lowest-priority policies.
When a match is found, the associated authentication method is used to perform device authentication. If the device authentication is successful, the management connection is built, completing IKE Phase 1.
In Step 4, the server performs XAUTH, authenticating the user using the client. XAUTH is used to ensure that an authorized user is using the client device. The client sends its username and password to the server. The server can authenticate the user using a local username database or can forward the authentication information to a AAA server, such as Cisco Secure ACS. Assuming that the user is authenticated successfully, the process continues to Step 5.
In Step 5, the server downloads (pushes) configuration and policy information to the client using IKE mode config. This information includes the following:
Internal address of the client
DNS server addresses
WINS server addresses
Split tunneling policies
Split DNS policies
List of backup servers
Firewall filtering policies
Besides this information, many other components are shared in IKE mode config. This information is based on the group that the user belongs to, as well as the user's configuration itself: Both are defined on the server.
In Step 6, the server uses RRI to create a static route to reach a client's internal IP address. RRI is necessary unless you are using generic route encapsulation (GRE) between the client and the server. RRI routes then can be redistributed to a routing protocol, such as OSPF, and advertised to the rest of the server's network.
Two types of RRI exist: client and network RRI. Figure 20-2 shows an example of the two types. Typically, when a client connects, such as with EVC_A and EVC_B, the EVS assigns a single IP address to the client. This host address is advertised, through RRI and redistribution, to a dynamic routing protocol such as OSPF at the EVS site.
However, with some types of clients, such as a 3002 or a small-end router or PIX firewall, this can pose a problem. For example, how do devices behind the EVC reach the corporate network? Cisco accomplishes this by providing two connection modes: client and network extension modes. In client mode, the EVC, such as EVC_B, uses PAT on the assigned internal address, translating its local devices to this assigned address: Any address in 192.168.1.0/24 is translated to 172.16.199.1 through PAT, making the network behind EVC_B appear as one logical device (EVC_B). In network extension mode, the client's locally connected network addresses are left as they are, as is the case with EVC_C. Typically, client mode is used when devices on the EVS side do not need to access resources on the EVC side; the EVC devices only need to access corporate resources. Network extension mode is used when both sides of the tunnel need to access resources on the other side and, therefore, the EVC-side devices need unique IP addresses.
In either situation, RRI helps internal devices find the respective remote-access client. In client extension mode, the EVS builds a host address route. In network extension mode, the EVC shares with the EVS the locally connected route, and the EVS builds a network static route. Through redistribution, the EVS then can advertise these static routes to other routers so that other devices at the central site can reach any type of remote-access client.
The static routes that RRI creates are temporary ones. When the VPN connection is lost or terminated, the associated RRI static route is removed. With these temporary static routes, RRI allows the router to act as a proxy, responding to ARP requests to the VPN clients when an internal machine is trying to reach the remote client's internal address. Since the EVS needs to respond to local ARP requests for destination EVCs, you need to ensure that proxy ARP is enabled on your router's internal interface(s).
RRI is not necessary if you have only one EVS. RRI is used when there is more than one EVS and there might be issues surrounding which EVS an internal device should use to reach a remote client. If you are using static routes on your EVS pointing to your clients, you do not need RRI; likewise, if you have a GRE tunnel to share routing information between the EVC and EVS, you do not need RRI. Therefore, RRI is optional, depending on your setup.
In Step 7, the two IPSec peers share their IKE Phase 2 policies (transforms) and attempt to build the two unidirectional data connections. Again, the client sends all possible permutations of transform sets based on its capabilities. Assuming that the two sides can find a matching transform set, the two unidirectional data connections are built and IKE Phase 2 completes. At this point, the two sides can send user traffic to each other.