Connection Modes

The Cisco hardware clients, including the 3002, support two connection modes to an Easy VPN Server: client mode and network extension mode. Both of these modes were discussed in Chapter 3, "IPsec." The following sections will discuss the two modes and how to enable them.

Client Mode

The top part of Figure 3-3 from Chapter 3 shows an example of client mode. As a quick review, in client mode, the Easy VPN Server assigns the remote access hardware client a single, internal IP address. For devices behind the hardware client to access the corporate site across the tunnel, the hardware client performs PAT on the inside packets to the internal IP address assigned to it by the Server. From the corporate office's perspective, it looks as if a single device is connected to the network, when in reality, it could be a few hundred (with the 3002, the limit is 253 devices off of the private interface).

Note

The default behavior of the 3002 is to use client mode; in other words, it's already set up to PAT addresses going across the tunnel.

 

Network Extension Mode

The bottom part of Figure 3-3 shows an example of network extension mode. Network extension mode simulates an L2L tunnel. Please note that it is not, however, an L2L session. The hardware client, like the 3002, is still a client and connects to the Easy VPN Server, where in ISAKMP/IKE Phase 1, XAUTH and IKE Mode Config occur (which is not the case with a true L2L tunnel session). The main difference is that the remote access client will share the network number and subnet mask of its private interface, during ISAKMP/IKE Phase 1, with the Server via reverse route injection (RRI).

The main limitation of client mode is that the central office cannot initiate a connection to a device behind the hardware client because PAT is being used. With network extension mode, no address translation occurs; typically, the network number off of the private interface of the hardware client is a unique subnet of a network used from the corporate office. Using this mode, a device at the central office can access a device at the SOHO easily. This might be necessary for management, file-sharing, or VoIP purposes.

Note

In network extension mode, only the directly connected network of the private interface is advertised to the Easy VPN Server. If you had more than one network behind the hardware client, these additional networks would be unknown to the VPN gateway. Therefore, if you had multiple subnets behind your hardware client, you would have to use client mode or use a different VPN device that supported L2L sessions.

The configuration of network extension mode involves three configuration steps: two on the 3002 and one on the Easy VPN Server. The following sections will discuss the setup of these items on both the 3002 and VPN 3000 concentrators.

Network extension mode version L2L sessions

You might ask, Why not use an L2L session instead of using network extension mode? If you recall from Chapter 3, "IPsec," an L2L session goes through three basic steps in ISAKMP/IKE Phase 1: Negotiate the Phase 1 policies, use DH to share keying information, and perform device authentication. Network extension mode requires a hardware client device, which means additional steps will occur: XAUTH, IKE Mode Config, and RRI, the latter being discussed later in the "Routing and Reverse Route Injection" section.

Using a hardware client, you have more control over policy configuration and enforcement than you would over an L2L session. Plus, if the Easy VPN Server is a VPN 3000 concentrator, the higher-end concentrators support more remote access sessions than they do L2L sessions. Therefore, if I was using a 3020 or higher at the central site, I would prefer setting up remote access sessions to be able to support more total VPN sessions.

Given this information, this does not mean that you should always use hardware clients with network extension mode instead of L2L sessions. L2L sessions have their place. For example, one limitation of a hardware client is that since it is a client, it can have only one tunnel up at a time. With L2L sessions, you can more easily mesh your network to reduce latency, which might be important for delay-sensitive traffic, like voice or video.

Also, remote access clients typically have addresses assigned to them dynamically via their connected ISP. This means that you cannot use GRE tunnels to propagate dynamic routing protocol information (unless using DMVPN), which provides better scalability in larger networks. With remote access clients, routing typically is done statically (please note that only IOS routers, out of all the Cisco products, support GRE tunnels).

And last, if there is more than one network connected to the hardware client using network extension mode, only the network number attached to its private interface is advertised to the central office VPN gateway; the others are not, which presents reachability issues.

 

3002 Network Extension Mode Configuration

By default, the 3002 uses client mode for its connection to an Easy VPN Server. There are two configuration steps you need to perform on the 3002 to enable network extension mode:

Step 1.	Change the IP address on the private interface to something different than 192.168.10.1.
Step 2.	Disable PAT.

Either you can perform these steps from Quick Configuration mode (go to Configuration > Quick Configuration), which I discussed in the "Quick Configuration" section earlier in the chapter, or do them from the main menu Configuration section.

Within Quick Configuration, you need to click to the Private Intf hyperlink first and change the private interface IP address to something different from 192.168.10.1 (Figures 14-6 and 14-7) and then click the PAT hyperlink and select the No, use Network Extension mode option (Figure 14-10 shows an example where the IP address wasn't changed from 192.168.10.1). Click the Done hyperlink when you're finished with Quick Configuration mode.

If you are going to do it using the latter method, to perform the first step, go to Configuration > Interfaces and click the hyperlink labeled Ethernet 1 (Private). Change the IP address and, possibly, subnet mask, and click the Apply button. Once you have done this, then go to Configuration > Policy Management > Traffic Management > PAT > Enable and uncheck the check box labeled PAT Enabled. Click the Apply button to accept your change.

Concentrator Network Extension Mode Configuration

The last step you must perform is on the Easy VPN Server, such as a VPN 3000 concentrator. On a concentrator, this is performed under the group configuration (Configuration > User Management > Groups). Select the group name and click the Modify button; then click the HW Client tab. If you refer back to Figure 14-17, the last option under this tab is Allow Network Extension Mode; click the check box for this option and click the Apply button at the bottom. Now, if any hardware client in the group is set up for network extension mode, the connection mode will be allowed.

Note

It is important to point out that if you don't enable network extension mode on the VPN 3000 concentrator, the 3002 can only use client mode; and if you have disabled PAT, then devices behind the 3002's private interface won't be able to access the central site via the IPsec tunnel.

 

Network Extension Mode Verification

There are a few ways that you can verify if your IPsec tunnel to the VPN 3000 concentrator is using network extension mode. First, on the 3002, go to Monitoring > System Status. Examine Figure 14-16. If you see the line Assigned IP Address and an internal IP address assigned by the Easy VPN Server, then you're operating in client mode. You won't see this line when operating in network extension mode.

On the VPN 3000 concentrator, go to Monitoring > Sessions and scroll down to the Remote Access Sessions section, like that shown in Figure 14-23. Examine the Assigned IP Address Public IP Address column. With a session using client mode, you'll see the assigned IP address from the address pool the concentrator is using (or from an AAA or DHCP server if the address pool is defined externally); with network extension mode, you'll see the network number of the hardware client's private interface. In Figure 14-23, this is 192.168.10.0.

Figure 14-23. Verifying Network Extension Mode on a Concentrator

If there is a problem connecting using network extension mode, the 3002's Event Log is not too illuminating about this particular problem; however, if you look at the concentrator's Event Log, you'll see something like that shown in Example 14-2. In this example, a 3002 with an address of 192.1.1.10 is trying to make a connection. Event 823 indicates that device and XAUTH authentication are successful. Event 826, however, displays that the group the 3002 belongs to is not configured for network extension mode, but the 3002 is trying to use it (PAT is disabled). Given this, the ISAKMP/IKE Phase 1 connection will fail.

Example 14-2. Network Extension Mode Misconfiguration

817 02/26/2005 15:49:05.310 SEV=5 IKEDBG/64 RPT=45 192.1.1.10
IKE Peer included IKE fragmentation capability flags:
Main Mode: True
Aggressive Mode: True


819 02/26/2005 15:49:05.800 SEV=5 IKE/172 RPT=45 192.1.1.10
Group [hwclients]
Automatic NAT Detection Status:
 Remote end is NOT behind a NAT device
 This end is NOT behind a NAT device


823 02/26/2005 15:49:06.120 SEV=4 IKE/52 RPT=43 192.1.1.10
Group [hwclients] User [hw3002]
User (hw3002) authenticated.
824 02/26/2005 15:49:06.150 SEV=5 IKE/184 RPT=43 192.1.1.10
Group [hwclients] User [hw3002]
Client Type: VPN 3002
Client Application Version: 4.1.7.A


826 02/26/2005 15:49:06.150 SEV=4 IKE/174 RPT=34 192.1.1.10
Group [hwclients] User [hw3002]
Hardware Client connection rejected!
Network Extension Mode is not allowed for this group!

If the negotiation of network extension mode is successful, instead of seeing event 826 in Example 14-2, you would see the event in Example 14-3. In this example, you can see the client type and version. Of course, this message has nothing to do with network extension mode, but this is what you will see if policies are successfully negotiated.

Example 14-3. Successful Negotiation of Network Extension Mode

1679 02/26/2005 15:54:59.910 SEV=5 IKE/184 RPT=114 192.1.1.10
Group [hwclients] User [hw3002]
Client Type: VPN 3002
Client Application Version: 4.1.7.A

Note

To use network extension mode, the 3002's IP address cannot be 192.168.10.1. However, this does not mean you have to change the network addressing scheme; you can easily change the IP address to 192.168.10.2, which would fulfill the address change requirements. In Figure 14-23, the 3002 has this address on its private interface. However, each hardware client needs a unique network number for its private interface.

 

Routing and Reverse Route Injection

One of the problems with remote access clients connecting to a central office using client mode or network extension mode is that if there are two Easy VPN Servers, like that shown in Figure 14-24, then which of the Servers should central office devices use to reach the client? This is especially problematic if you're using VCA load balancing or VRRP redundancy. Which of the Servers is the client connected to? And even if you would find out this information, it might change based on the next session the client builds to the central office.

Figure 14-24. Remote Access Clients, Central Site Redundancy, and Routing Issues

 

Routing Features

The only way to deal with this reachability problem is to:

• Use a dynamic routing protocol on the VPN gateways and have the gateways advertise this information to the central site layer-3 devices; this is necessary if an AAA RADIUS or DHCP server will be assigning addresses to the clients using client mode or the client is using network extension mode
• Use static routing on the layer-3 devices to point to the correct concentrator; this will only work for client mode connections where each concentrator has its own pool of addresses it assigns to clients

Assuming you're using the first bullet point as your solution. No matter what Easy VPN Server a remote access client is connected to, the Servers will propagate the updated routing information to the internal layer-3 devices so that corporate office devices can reach the remote access clients.

One of the interesting things about this process is that remote access clients don't advertise routing information via a routing protocol. Instead, either the internally assigned IP address (client mode) or the network number of the private interface (network extension mode) is shared with the Easy VPN Server. Only the Server understands this and associates these numbers with the IPsec SAsthis information doesn't even appear in the Server's routing table.

However, Cisco Easy VPN Servers support a process called reverse route injection (RRI) to place the client's routing information in the Easy VPN Server's local routing table as a static route and allow the static routes to be redistributed via a local routing protocol out of the Server's other interfaces. With the VPN 3000 concentrators, the static routes can be redistributed using RIPv1, RIPv2, or OSPF.

RRI Configuration

Configuring RRI is an Easy VPN Server configuration task: the remote access clients have no clue, nor do they care, that this process is occurring. On the VPN 3000 concentrators, this configuration is done in two steps:

Step 1.	Enable RRI.
Step 2.	Configure the dynamic routing protocol.

I already discussed Step 2 in Chapter 10, "Concentrator Management." You need to configure the routing protocol, if it happens to be OSPF, and enable the routing protocol on the private, and possibly external, interface of the concentrator. In this section, I'll only discuss the first step: Enabling RRI.

To enable RRI on your VPN 3000 concentrator, go to the Configuration > System > IP Routing > Reverse Route Injection screen, shown in Figure 14-25. If you use both types, select both check boxes: Client Reverse Route Injection and Network Extension Reverse Route Injection. If you don't select an RRI type, that type doesn't show up as a static route in the concentrator's local routing table and thus can't be redistributed to other central office devices. The Address Pool Hold Down Routes allows you to list routes the concentrator will always advertise as reachable: this option can be used if a client always connects to the same concentrator no matter what, and you always want the concentrator to advertise the route, especially with RIP, to reduce convergence time when an IPsec tunnel is being built or rebuilt by the client. Once you've configured the information on the screen, click the Apply button to save your changes.

Figure 14-25. RRI Configuration on a Concentrator

Once you have configured RRI, you can verify that it's working by examining the concentrator's local routing table: Monitoring > Routing Table. For clients using network extension mode, you should see their private interface network numbers show up as static routes in the routing table; for clients using client mode, you should see their internal IP addresses show up as static host routes.