Scenario 5: Extranet Issues

This scenario addresses the requirement for users that have a need to access their corporate network from a location outside of their corporate firewall, such as a customer site. These are the typical Extranet VPN situations. To ensure that your VPN works properly, it requires specific ports on your customer's firewall to be open, and if they are not, your company's VPN concentrator will be unable to communicate with the VPN client. Simply put, these cases can be described as "problems connecting through customer's site firewall."

The typical situation here is that an employee (user) from your company works on a customer site and tries to connect to the concentrator at your company, using your VPN software client (typically). The user can browse the web and ping the corporate firewall, but it cannot connect to the concentrator. When the user hits connect on the VPN client, it cycles through all the back-up concentrators and times out. The client initiates the ISAKMP key exchange but the concentrator cannot reach the client to accept it, and the client receives the error "Remote peer no longer responding."

Typically, most companies block the ports and protocols that VPN requires. In some cases, the firewall might need to allow the IP address of the concentrator that you are connecting to, but that depends on the type of firewall. The ports required to be open on a firewall to support VPN are as follows and are discussed in this section:

ESP 50
UDP 500 ISAKMP
UDP 10,000 (Allow IPSec Through NAT)

In addition, the following issues are discussed:

Tunnel keepalives
Dead Peer Detection

Protocol 50ESP

All IKE 3.x clients require that ESP protocol 50 be enabled on the corporate firewall if encryption is specified in the group's transform, and all 2.x clients require it if encryption is specified in the VPN Group. Macintosh 3.x and 2.x clients also require ESP 50. For a more detailed explanation of ESP and ISAKMP and how they work, see Chapter 19, "VPN Technology Background."

UDP 500ISAKMP

All IKE clients and LAN-to-LAN IKE tunnels require UDP Port 500 and their respective protocol to establish a tunnel. IKE negotiation uses UDP on port 500. Ensure that your access lists are configured so that UDP port 500 traffic is not blocked at interfaces that are used by IKE and IPSec. In some cases, you might need to add a statement to your access lists to explicitly permit UDP port 500 traffic. If UDP port 500 is being blocked by your firewall, you are unable to establish a VPN tunnel.

UDP 10,000 (Allow IPSec Through NAT)

Unlike the other two ports, this port number is configurable on the VPN concentrator. You have the choice of using a number between 4001 and 49,151; the default is 10,000. See Figure 22-11 to determine where to modify the port number.

Figure 22-11. The NAT Port Number Configured on the Concentrator

NOTE

In version 3.5x of the VPN client, IPSec can be encapsulated in UDP or TCP packets, which enables secure tunneling through both NAT and Port Address Translation (PAT) devices and firewalls. This feature enables the VPN client to operate in an environment where the standard ESP, Protocol 50 or IKE, UDP 500 cannot normally function, or can only function with modification to the existing firewall configuration. This provides a significant benefit to users who want to VPN from within an external network. This feature does not work with proxy-based firewalls.

Tunnel Keepalives

In some cases, the VPN tunnel can drop when going through a firewall because the port on an ESP-aware NAT/Firewall closes after short periods of inactivity. To reduce the chance of the tunnel dropping, you can modify the .pcf file for that connection. Use a text editor to open the .pcf file for the connection entry that you are using; the .pcf files are located under C:\Program Files\Cisco Systems\VPN Client\Profiles. Then set the ForceKeepAlives=1. By turning on the ForceKeepAlive, you direct the VPN client to send IKE and ESP keepalives for a connection at approximately 20-second intervals. This significantly reduces the risk of a firewall closing a port because of inactivity.

Dead Peer Detection

The Cisco VPN client supports the ability to dynamically connect to multiple gateways and uses IKE keepalives or Dead Peer Detection (DPD) to determine tunnel status. The introduction of PIX OS 6.x supports the version of keepalives used by the Cisco VPN client. The same method is used for immediate multiple peer failover with the PIX, as is used for the VPN 3000 series concentrators.

The DPD protocol is the successor to the Keepalive protocol. These protocols systematic-ally test the remote end of a VPN tunnel and notify their host when messages can no longer be passed. DPDs are passed every 30 seconds, and the concentrator drops the connection if it does not receive a reply within five minutes.

From the concentrator log, VPN administrators can see the DPD exchange with the VPN client (see Example 22-9). Both the client and the concentrator agree to use DPD.

Example 22-9. Concentrator Capture of the DPD Exchange and a DPD Disconnect

 30     17:08:51.400  01/25/2002  Sev=Info/5     IKE/0x43000001 Peer supports DPD <Output Omitted> 83     17:09:13.752  01/25/2002  Sev=Info/6     IKE/0x4300003D Sending DPD request to 10.3.3.3, seq# = 2948297981 84     17:09:13.752  01/25/2002  Sev=Info/4     IKE/0x43000013 SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 10.3.3.3 85     17:09:13.758  01/25/2002  Sev=Info/5     IKE/0x4300002F Received ISAKMP packet: peer = 10.3.3.3 86     17:09:13.758  01/25/2002  Sev=Info/4     IKE/0x43000014 RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:DPD_ACK) from 10.3.3.3 <Output Omitted> 584 02/26/2002 17:03:02.300 SEV=4 IKE/123 RPT=35497 10.3.3.3 IKE lost contact with remote peer, deleting connection (keepalive type: DPD) ! Based on DPD keepalives, after 5 minutes of no response from the client, ! the concentrator drops the connection. <Output Omitted>

Extranet issues can vary, depending on software functionality. In the VPN client version 3.5x, there are additional encapsulation options for UDP or TCP, specifically for NAT-based connections (see Figure 21-5). This functionality can reduce firewall-related issues that users experience when trying to connect from an external network, such as a customer's premises. Using the following ports are preferred because these ports are usually open in a company's firewalls: TCP port 80 (http), TCP port 22 (ssh), or TCP port 443 (https).

Extranet issues can vary depending on the software functionality. In the VPN Client version 3.5x, additional encapsulation options exist for UDP or TCP, specifically for NAT-based connections (see Figure 22-12). This functionality can reduce firewall-related issues that users experience when trying to connect from an external network, such as a customer's premises. Using the following ports are preferred because they are usually open in a company's firewalls: TCP port 80 (http), TCP port 22 (ssh), or TCP port 443 (https).