Cisco Secure VPN Exam Certification Guide - Cisco press

VPN 3002 Hardware Client Reverse Route Injection 409

Configuring VPN 3002 Hardware Client Reverse Route Injection

RRI can be configured in one of the following four ways:

•LAN-to-LAN remote network definitions are the injected routes as either a single network or a network list.

•The VPN 3002 Hardware Client connects using Network Extension mode, injecting its protected network address.

•VPN software clients inject their own IP address as host routes (Client RRI).

•RRI provides a hold-down route for the VPN client pool.

In addition to the preceding four options, the following sections also discuss configuring LAN- to-LAN with Autodiscovery.

Configuring LAN-to-LAN Network RRI

After navigating to the Configuration | System | Tunneling Protocols | IPSec | LAN-to-LAN | Modify screen on the VPN concentrator, which is shown in Figure 9-4, configure RRI by following these steps:

Step 1 Fill in the name, interface, and peer.

Step 2 Choose the type of digital certificate.

Step 3 Enter the pre-shared key.

Step 4 Choose the authentication type, encryption, and IKE proposal.

Step 5 Choose Reverse Route Injection in the routing field. The VPN concentrator will advertise the learned routes to the interior routers.

This process is necessary to establish RRI on the VPN concentrator. Remember that RRI will only work with RIP or OSPF. When RIP is used, the remote network can only advertise routes to the VPN concentrator. Only when using OSPF can the VPN concentrator advertise routes to the VPN 3002 Hardware Client.

Configuring LAN-to-LAN with Autodiscovery

The only configuration change necessary to enable Autodiscovery is made through the Configuration | System | Tunneling Protocols | IPSec | LAN-to-LAN | Modify screen. Here, you choose Autodiscovery instead of Network Lists. Remember that RIP is the only protocol available for use with Autodiscovery.

VPN 3002 Hardware Client Reverse Route Injection 411

Figure 9-6 Configuration | System | IP Routing | Reverse Route Injection

Configuring Hold-Down Routes

Hold-down routes are used to make remote VPN connections appear as if they were active even when there is no VPN tunnel active. This way, the stability and speed of network topology calculations by the routing protocols is enhanced. Since the networks appear to be available at all times, the routing protocols do not have to recalculate the topology every time a VPN connection is established or dropped.

Hold-down routes are entered on the Configuration | System | IP Routing | Reverse Route Injection screen in the Address Pool Hold-Down Routes box on the VPN concentrator (see Figure 9-7). Double-click on an empty line on the box and enter the IP address/Subnet mask combination. Note that a backslash (/) should be used between the IP address and the subnet mask and that the subnet mask must be entered in standard octet notation.

Figure 9-7 Address Pool Hold-Down Routes

VPN 3002 Hardware Client Backup Servers 413

connect to the next server defined, in this case, Boston. If there are other servers on the list, the next server will be tried after 8 seconds without a connection. Up to 10 backup servers may be listed in the backup server list, each being tried in turn. If all of the servers are tried unsuccessfully, the attempts to connect are stopped without automatically retrying the list.

There are nine items you need to remember regarding backup servers:

•A backup server list can only be downloaded from a primary VPN concentrator, never from a backup.

•If the primary VPN concentrator is unavailable, a backup concentrator will be contacted ONLY if a backup list is already configured.

•The VPN 3002 Hardware Client will be unaware of changes made to servers unless that VPN 3002 Hardware Client is connected to the primary VPN concentrator.

•On the VPN 3002 Hardware Client, the backup servers are set on the Configuration | System | Tunneling Protocols | IPSec screen, which only applies if Use Client Configured List is set. The Configuration | System | Tunneling Protocols | IPSec screen is shown in Figure 9-8.

•On the VPN concentrator, the configuration of the backup servers is done through the Configuration | User Management | Base Group | Mode Configuration or the Configuration | User Management | Groups | Mode Configuration screens. An example of the Configuration | User Management | Base Group | Mode Config screen is shown in Figure 9-9.

•The group name, username, and password must be identical on the primary and backup servers.

•In Network Extension Mode, the VPN 3002 Hardware Client will attempt to connect to a backup server after the default of 4 seconds.

•In Client mode, the VPN 3002 Hardware Client only attempts a connection when the user clicks the Connect Now button on the Monitoring | System Status screen or when data passes through the VPN 3002 Hardware Client.

•VPN 3002 Hardware Clients have no knowledge of each other, only of the primary and backup servers.

414 Chapter 9: Configuring Scalability Features of the VPN 3002 Hardware Client

Figure 9-9 Configuration | User Management | Base Group | Mode Config

VPN 3002 Hardware Client Load Balancing

34 Configuring the VPN 3002 load balancing feature

The devices in the VPN 3000 Concentrator series have the ability to load balance connections from remote clients or VPN 3002 Hardware Clients. VPN 3002 Hardware Clients do not actually perform the load balancing function; they are merely beneficiaries of the results.

Load balancing and Virtual Router Redundancy Protocol (VRRP) cannot be used at the same time with the same concentrators. With VRRP, the backup device stays in an idle state until it is required to become active to assume the duties of the primary device. With load balancing, all of the devices in the virtual load balancing cluster are active.

Load balancing can occur between two or more VPN concentrators that are located on the same network to process remote access VPN connections. Load balancing only works with Cisco VPN Clients running version 3.0 or later, and with Cisco VPN 3002 Hardware Clients running version 3.5 or later. Other clients and LAN-to-LAN devices can still establish VPN connections to VPN concentrators participating in load balancing, but these clients and devices will not participate in load balancing by being directed away from their primary device.

416Chapter 9: Configuring Scalability Features of the VPN 3002 Hardware Client

—Encryption—Virtual cluster communications are handled over LAN-to-LAN tunnels between VPN concentrators in the virtual cluster. Checking the encryption field forces that communication to be encrypted. The default setting is to have encryption enabled.

—IPSec Shared Secret—When you have selected to use encryption in the previous field, you will need to enter a password in this field that will be used as the preshared key when the cluster concentrators establish IPSec communication tunnels with their cluster peers.

—Verify Shared Secret—Re-enter the password in this field for verification of the entry.

•Device Configuration—This section is used to define device-specific parameters for VPN concentrators participating in load-balancing virtual clusters.

—Load Balancing Enable—This VPN concentrator will not participate in load balancing unless this field is checked. The default setting for this field is unchecked, disabling load balancing.

—Priority—This field is used to set the priority of the device. Election of the virtual cluster master uses this field as one of the determining factors in the election process. The default setting here is specific to the VPN concentrator model and was described in an earlier list within this section. The value can be a number from 1 to 10. The higher the value, the more likely the chance that the device will be selected as the virtual cluster master. When all the concentrators in the cluster are of the same model, set the priority to 10 on all of them to shorten the election process.

—NAT Assigned IP Address—The default setting for this field is 0.0.0.0, which indicates that the concentrator is not using NAT. Enter the NAT IP address here if the concentrator is protected by a firewall using NAT.

When a client attempts to connect to a load-sharing cluster, it will use the IPSec group settings to negotiate and establish the working VPN tunnel. Different clients might use different IPSec groups in order to provide different classes of service. Each VPN concentrator in the virtual load-balancing cluster must have a matching group for any potential client, and the settings for the group must be identical on every VPN concentrator in the cluster.

Overview of Port Address Translation

38 Overview of Port Address Translation

In order to understand the issues involved when using Port Address Translation (PAT), you first need to understand how Network Address Translation (NAT) works. NAT is the process of changing the source IP address on all packets sent out by a host and changing the destination

Overview of Port Address Translation 417

IP address of all incoming packets for that host. This prevents hosts outside of the LAN from knowing the true IP address of a local host. While not a true security method in itself, NAT may help security efforts through hiding the true IP address of the client. NAT may be configured in two differing ways. When NAT uses a specific global IP address for a given host, this is referred to as a static NAT. The other method of configuring NAT is to use a pool of IP addresses for all local hosts. Local hosts are assigned a global IP address on a first-come–first-served basis. The IP address of a specific local host will receive changes based on the availability of global IP addresses.

During the NAT process for a packet traveling outbound through the NAT device, the source IP within the IP packet is replaced with a global IP address. The NAT device tracks the inside IP address that is associated with the global IP address. For a packet traveling inbound through the NAT device, the destination address is replaced with the locally known IP address.

PAT is a form of NAT. When PAT is employed, not only does the source or destination address of an IP packet change, but the TCP or UDP source port is also changed. This way, the PAT device can allow multiple local devices to appear as a single global IP device with the differing source ports providing the unique identification necessary to translate the incoming packets to their respective local IP addresses. In essence, a NAT translation is a one-to-one translation of the IP address, where a PAT translation is a one-to-many translation of the IP address using the port to differentiate between the connections.

The first issue raised when using PAT is that some older programs will not work because the ports are translated. This is especially true when dealing with some Microsoft DOS programs. This can usually be overcome by upgrading the operating system and/or programs affected.

The second, and more severe issue is that traditional IPSec, discussed in the next section, relies heavily on the ports in use. As in some older DOS programs, IPSec will not work when combined with PAT. Cisco has come up with a solution when using the VPN 3002 Hardware Client that allows IPSec to run through a PAT connection. Cisco’s solution is to use either IPSec over TCP/IP or UDP NAT Transparent IPSec. Both will be discussed shortly.

You usually have fewer global IP addresses that you can use than you have local hosts. The most common way of dealing with this is to assign static global addresses to those hosts that need to be reached from the Internet at a known IP address. Next, local hosts are assigned IP addresses from the global pool on a first-come–first-served basis. After all but one of the allotted global addresses have been assigned, you use PAT with the final global address for all the remaining local hosts.