Other VPN 3002 Software Features

Interactive Hardware Client Authentication

Interactive hardware client authentication, sometimes called interactive unit authentication, prevents VPN 3002 private LAN users from accessing the central site until the VPN 3002 unit authenticates. In this scenario, the VPN 3002 doesn’t use a saved user name and password for authentication. Instead, a valid user name and a password for the 3002 must be manually entered each time.

The VPN 3002 sends the user name and the password to the VPN Concentrator when it initiates a tunnel session. The VPN Concentrator can authenticate the connection using either an internal or an external server. The tunnel is only established if the user name/password combination is valid.

Interactive hardware client authentication is configured on the VPN Concentrator, which then pushes the policy down to the VPN 3002 at the next connection.

Configuring Interactive Unit Authentication

The Hardware Client parameters tab on the VPN 3000 Concentrator Series Manager is used to configure several features for the VPN 3002 and its users in the base group. The feature will be “pushed” down to the client devices the next time the VPN 3002 establishes a session. The menu selection is Configuration | User Management | Base Group, HW Client parameters tab.

Check the Require Interactive Hardware Client Authentication check box, as shown in Figure 15-24.

Figure 15-24: Configure Interactive Hardware Client Authentication

Individual User Authentication

Individual user authentication protects the central site from access by unauthorized individuals on the VPN 3002 private network. It accomplishes this by requiring each user to open a web-browser session and manually enter a valid user name and password combination to gain access to the network behind the VPN Concentrator, regardless of whether a VPN tunnel already exists. A successful login results in the browser displaying the appropriate default home page.

This feature can only be used with a browser, not the command-line interface. Attempts to access non-web-based resources, such as e-mail, on the network behind the VPN Concentrator will fail until a successful browser authentication occurs.

To simplify the process and make it as transparent as possible to the end users, this technology automatically intercepts any users attempting to traverse the VPN tunnel and redirects them to a browser page to authenticate. Users needn’t initiate or remember to initiate the security authentication because it’s done automatically. If users are only attempting to access the Internet via Split Tunneling, they aren’t prompted to authenticate. Each user can maintain a maximum of four simultaneous login sessions.

Individual user authentication is configured on the VPN Concentrator, which then pushes the policy down to the VPN 3002 at the next connection.

LEAP Bypass

IEEE 802.1X is a standard for authentication on wired and wireless networks providing wireless LANs with strong mutual authentication between clients and authentication servers. 802.1X provides dynamic per-user, per-session wireless encryption privacy (WEP) keys, thereby removing administrative overhead and security concerns related to static WEP keys.

Lightweight Extensible Authentication Protocol (LEAP) is Cisco Systems 802.1X wireless authentication technology that implements mutual authentication between a wireless client and a RADIUS server. The authentication credentials, including a password, are always encrypted before they’re transmitted over the wireless medium.

LEAP Bypass allows LEAP packets from devices behind a VPN 3002 to travel across a VPN tunnel before individual user authentication. This allows wireless workstations using access point devices to establish LEAP authentication, and then authenticate again using individual user authentication, if enabled.

Without this technology, LEAP users behind a VPN 3002 are caught in a Catch-22. They can’t authenticate on the wireless network because they can’t access the VPN tunnel to get to the RADIUS. They can’t access the VPN tunnel because they haven’t authenticated on the wireless network.

The VPN Concentrator administrator enables LEAP Bypass on a per group basis at the central site, using a check box on the HW Client tab on the Group configuration page. The LEAP packets travel over the tunnel to a RADIUS server via ports 1645 or 1812.

LEAP Bypass functions properly if the following conditions are met.

• Interactive unit authentication must be disabled, otherwise, a non-LEAP (wired) device needs to authenticate the VPN 3002 before LEAP devices can connect using the tunnel.

• Individual user authentication is enabled, otherwise, LEAP Bypass isn’t needed.

• The VPN 3002 device can be in either Client mode or Network Extension mode.

• Wireless Access points must be Cisco Aironet Access Points.

• The Cisco Aironet Access Point must be running Cisco Discovery Protocol (CDP).

• The wireless NICs for the PCs can be from other manufacturers.

While the LEAP and LEAP Bypass technologies are sound, some security risk always exists in allowing any unauthenticated traffic to traverse the secure tunnel.

IPSec Backup Servers

The IPSec backup servers feature provides alternatives for the VPN 3002 hardware client to connect to the central site when its primary VPN Concentrator is unavailable. Backup servers can either be configured individually on the VPN 3002 device or on a per-group basis on the central-site VPN Concentrator. When configured on the central-site VPN Concentrator, the Concentrator pushes the backup server policy to all VPN 3002 hardware clients in the group.

The following characteristics apply to the IPSec backup server feature:

• Each VPN 3002 must connect to the primary VPN Concentrator at least once to download a backup server list. A backup server list can’t be downloaded from a backup server.

• If the primary VPN Concentrator is unavailable to download the backup server list and the VPN 3002 has a previously configured backup server list, it can continue to connect to the servers on that list.

• If the VPN 3002 has tried all designated backup servers on the list and can’t connect, it doesn’t automatically retry. The following trigger a new round of attempts:

  • In Network Extension mode, the VPN 3002 attempts a new connection after four seconds.

  • In Client mode, the VPN 3002 attempts a new connection when the user clicks the Connect Now button on the Monitoring | System Status screen or when data passes from the VPN 3002 to the VPN Concentrator.

• Any changes to the configuration of the backup server’s list during an active VPN 3002 session won’t take effect until the next time the VPN 3002 connects to its primary VPN Concentrator.

• The VPN Concentrator backup servers needn’t be aware of each other.

The group name, user name, and any passwords configured for the VPN 3002 must be identical for the primary VPN Concentrator and all backup servers. Also, if interactive hardware client authentication and/or individual user authentication are configured for the VPN 3002 on the primary VPN Concentrator, they must be configured on backup servers as well.

Configure IPSec Backup Servers—VPN 3002 Client

You can configure the backup server feature from the primary VPN Concentrator or the VPN 3002. Use the Configuration | System | Tunneling Protocols | IPSec screen to configure backup servers directly on the VPN 3002. From this screen, shown in Figure 15-25, you can configure up to ten servers, ranging from the highest priority on the top to the lowest priority on the bottom. The Backup Easy VPN Servers window is only a small text box allowing direct entry and insertions.

Figure 15-25: Configure backup servers directly on the VPN 3002 Client

Configure IPSec Backup Servers—VPN 3000 Concentrator

To configure backup servers for the VPN 3002 from the VPN Concentrator, use the Configuration | User Management | Base Group, Client Config tab, as shown in Figure 15-26. The backup server’s list will apply the next time the 3002 connects to its primary concentrator.

Figure 15-26: Configure backup servers on the VPN Concentrator

In the IPSec Backup Servers section, use the drop-down list box to select a method to use or disable backup servers. The three choices are as follows:

• Use client configured list

• Disable and clear client configured list

• Use list below

Enter up to ten IPSec backup server addresses/names starting from the highest priority to the lowest. Enter each IPSec backup server address/name on a single line.

IPSec Server Load Balancing

The load balancing feature makes it possible to distribute remote sessions among two or more VPN Concentrators connected on the same network. Load balancing provides efficient use of system resources, while providing increased performance and high availability by directing remote sessions to the least-loaded device.

The load balancing is used only with remote sessions with VPN Concentrators initiated by either the Cisco VPN Client (3.0 or later) or the Cisco VPN 3002 Hardware Client (3.5 or later). All other VPN clients, including LAN-to-LAN connections, can connect to a VPN Concentrator on which load balancing is enabled, but they can’t participate in load balancing.

Load balancing requires no configuration on the VPN Client or VPN 3002.

Configure a Server for Load Balancing

Before configuring load balancing on a VPN Concentrator, you must complete the following two tasks:

• Configure the private and public interfaces.

• Configure the filters for the private and public interfaces to allow the Virtual Cluster Agent (VCA) load balancing protocol.

Configure Interfaces

Use the Configuration | Interfaces window to check to see if the public and private interfaces were defined and each has status UP. If either interface is undefined, it must be defined before proceeding.

Virtual Cluster

To implement load balancing, you must group together two or more VPN Concentrators logically on the same private LAN-to-LAN network, private subnet, and public subnet into a virtual cluster. The virtual cluster appears to outside clients as a single virtual cluster IP address.

All devices in the virtual cluster are used to distribute session loads. The virtual cluster master directs incoming calls to the other devices, referred to as secondary devices. By monitoring all devices, the virtual cluster master can distribute the session load based on the activity of each device. The virtual cluster master role isn’t assigned to a specific physical device, but can shift among devices, as needed. This flexibility is particularly important if the current virtual cluster master fails. In this case, one of the secondary devices takes over and immediately becomes the new virtual cluster master.

A VPN Client wanting to initiate a session connects to the virtual cluster IP address. The virtual cluster master returns the public IP address of the cluster host with the least load to the client. The process is transparent to the user because the VPN client connects directly to that designated host without any user involvement or messages.

If a cluster machine fails, the terminated sessions reconnect immediately to the virtual cluster IP address where the virtual cluster master repeats the reassignment process. Even if the failed device is the virtual cluster master, one of the secondary cluster devices immediately and automatically takes over as the new virtual session master. Multiple device failures in the cluster should also be resolved, as long as one cluster device remains available.

Configure Filters

Use the following VPN Concentrator steps to configure the filters for the private and public interfaces to allow the VCA load balancing protocol.

1. In the Configuration | Interfaces window, select Ethernet1 (Private). The Configuration | Interfaces | Ethernet1 window appears.

2. Choose the General tab.

3. Use the drop-down Filter menu button and select Private (Default).

4. Click on Apply.

5. In the Configuration | Interface window, select Ethernet2 (Public). The Configuration | Interfaces | Ethernet2 window appears.

6. Choose the General tab.

7. Use the drop-down Filter menu button and select Public (Default).

8. Click Apply.

9. Go to the Configuration | Policy Management | Traffic Management | Filters window.

10. Choose Private (Default) from the Filter list.

11. Select Assign Rules to Filter. The Configuration | Policy Management | Traffic Management | Assign Rules to Filter window appears.

12. Verify that VCA In (forward/in) and VCA Out (forward/out) are in the Current Rules in Filter list. If necessary, add them to the list.

13. Click on Done.

14. In the Configuration | Policy Management | Traffic Management | Filters window, choose Public.

15. Choose Assign Rules to Filter. The Configuration | Policy Management | Traffic Management | Assign Rules to Filter window appears.

16. Verify VCA In (forward/in) and VCA Out (forward/out) are in the Current Rules in Filter list. If necessary, add them to the list.

17. Click Done.

18. Click the Save Needed icon in the upper-right corner to save the changes.

Configure Load Balancing

Use the Configuration | System | Load Balancing screen to enable load balancing on the VPN Concentrator, as shown in Figure 15-27. The process takes two steps:

Figure 15-27: Configuring load balancing

1. Configure the cluster—Define the common virtual cluster IP address, UDP port (if necessary), and IPSec shared secret value for every device in the cluster.

2. Configure the device —Enable load balancing on the device, and then define the device-specific properties. These values can vary, based on device type and option features.

   VPN Virtual Cluster IP Address	A single IP address identifying the virtual cluster. This address must be within the address range shared by all VPN Concentrators in the cluster.
   VPN Virtual Cluster UDP Port	A UDP destination port number to use for load balancing if another application is already using the default port.
   Encryption	Specifies all load-balancing communication between the VPN Concentrators is encrypted.
   IPSec Shared Secret	Available only if Encryption is checked. The shared secret is a common password used to authenticate all virtual cluster members. IPSec uses this shared secret as a preshared key to establish secure tunnels between virtual cluster peers.
   Priority	Priority (1 to 10) for this VPN Concentrator within the virtual cluster. The higher the value, the more likely this device could become the virtual cluster master either at startup or when an existing master fails.

H.323 Support in PAT Mode

VPN 3002 client software supports H.323, the packet-based multimedia communications standard developed by the International Telecommunication Union (ITU). A variety of multimedia applications use the H.323 standard to implement real-time audio, video, and data communications. This H.323 support allows the VPN 3002 to support Microsoft NetMeeting. H.323 support requires no configuration on the VPN 3002.

Simple Certificate Enrollment Protocol (SCEP)

You can enroll and install digital certificates on the VPN 3002 manually or automatically. The automatic method is a new feature that uses the Simple Certificate Enrollment Protocol (SCEP) to streamline enrollment and installation. SCEP is a secure messaging protocol that requires minimal user intervention and was introduced in Chapter 11.

This automatic method is quicker than enrolling and installing digital certificates manually, but is available only if the following two conditions are met.

• The CA must support SCEP.

• Enrolling must be done via the Web.

If the CA doesn’t support SCEP or if digital certificates are enrolled by other means, such as e-mail or floppy disk, then they must be processed using the manual method.

To allow retrieving the CA certificate via SCEP, use the Administration | Certificate Management | Install | CA Certificate | SCEP, as shown in Figure 15-28.

Figure 15-28: Using SCEP to enroll certificates

XML Management

The VPN 3002 now supports an XML-based interface that allows the administrator to use an external management application. These management applications can be Cisco products or third-party tools. XML data can be sent to the VPN Concentrator using HTTPS, SSH, or standard file transfer protocols, such as FTP or TFTP.

This feature is enabled by default and doesn’t require configuration.

Reverse Route Injection (RRI)

A VPN Concentrator can be configured to add routes to its routing table for remote hardware or software clients. The VPN Concentrator then advertises these routes to its private network via RIP or OSPF, making the VPN 3002 protected networks known to the main network. This feature is called reverse route injection (RRI) and it was introduced in version 3.5 of the VPN 3000 Concentrator code.

Figure 15-29 shows the VPN scenario used earlier. The scenario assumes the main office has reserved the networks 192.168.0.0 to 192.168.127.0 for its internal use. The other private class C addresses were assigned as needed to branch locations. RRI could be implemented so all main office routers know about the branch office LAN. This assumes the branch office is configured for Network Extension mode.

RRI requires no configuration on the VPN 3002.

Figure 15-29: VPN scenario network with the main office using RRI

Network Extension RRI

This option is for VPN 3002 Client in Network Extension mode (NEM) only. To configure Network Extension RRI on the VPN Concentrator, go to Configuration | System | IP Routing | Reverse Route Injection and select the check box for Network Extension Reverse Route Injection. This selection adds a network route for each network behind a VPN 3002 Hardware Client to the routing table on the VPN Concentrator. The VPN Concentrator adds the route when the VPN 3002 connects and deletes the route when it disconnects. This box is unchecked by default.

Figure 15-30 shows the Configuration | System | IP Routing | Reverse Route Injection screen where both of the RRI features can be configured. The example shows adding the protected LAN from the scenario example.

Figure 15-30: Configuring Reverse Route Injection

AES Support and Diffie-Hellman Group 5

VPN software version 3.6 introduced support for Advanced Encryption Standard (AES), which is more secure than DES and more efficient than 3DES. AES supports 128-, 192-, and 256-bit key strengths. 128-bit AES is significantly faster than 168-bit 3DES and little performance difference exists between 256-bit AES and 168-bit 3DES. AES support was also added to the PIX Firewall with v6.3(1).

VPN software version 3.6 also introduced support for Diffie-Hellman Group 5 (1,536-bit key), which provides greater key exchange security. This feature is set as part of IPSec configuration on the VPN Concentrator, as shown in Figure 15-31.

Figure 15-31: Configuring IKE proposals, including AES and DH 1, 5, and 7

Push Banner to VPN 3002

An administrator can create a banner on the VPN 3000 Concentrator and push it to the VPN 3002. This allows the organization to provide information to users about their network, terms for use, liability, and other issues. The maximum banner length is 510 characters. Any characters, including newline (ENTER key) can be used. Use the Configuration | User Management | Base Group, Client Configuration parameters tab on the VPN Concentrator, as shown in Figure 15-32.

Figure 15-32: Configuring a banner to be pushed to VPN 3002s

The banner displays only when individual user authentication is enabled.

Delete with Reason

Delete with reason is a part of the system-messaging process that can be used for alerts and troubleshooting. Delete with reason causes the VPN Concentrator to send reasons for VPN Concentrator-initiated disconnects to any impacted software clients or VPN 3002 hardware clients. The client device then decodes the reason and displays it in the event log.

Similarly, the VPN 3002 sends reasons for any VPN3002-initiated disconnects to the VPN Concentrator at the central site. The VPN Concentrator decodes the reason and displays it in the event log.

The feature isn’t currently supported by the Cisco PIX Firewalls.

The feature is active by default, but an administrator can disable it.