IPsec Traffic and Networks

There are two important issues you might have to deal with concerning the sending and receiving of IPsec traffic:

• Address translation

• Firewalls

• Other IPsec issues

The following three sections will discuss these issues in more depth.

IPsec and Address Translation

Address translation translates addressing and, possibly, port information inside IP, TCP, or UDP headers. My goal here is to not discuss what address translation is; I'm assuming you are already familiar with it. My other Cisco Press book, Cisco Router Firewall Security, covers the mechanics of address translation on Cisco routers, if you're not that familiar with the process.

As you already know, there are three IPsec connections between two IPsec peers:

• A management connection, which uses UDP port 500

• Two data connections, which use AH (protocol 51) or ESP (protocol 50)

The following two sections will discuss issues with address translation and IPsec, and possible solutions.

Address Translation Issues

Devices performing address translation typically don't create any issues for the management connection, but can cause problems with the data connections. However, some earlier PAT devices would force all management connections to use UDP port 500 for both the source and destination, which could cause problems for multiple simultaneous connections to the same endpoint through the PAT device; this shouldn't be a problem with most translation devices today, though.

As I mentioned in the "Phase 2 Security Protocols" section, AH breaks completely when any type of address translation is performed on an AH packet. PAT isn't supported because PAT requires an outer TCP or UDP headerand AH is a Layer-3 protocol that lacks this. AH also won't work with NAT because AH includes most of the fields in the entire IP packet in the input of the HMAC function. Therefore, if the source or destination address is changed, this would invalidate the ICV signature by the destination IPsec device.

ESP actually works with NAT, since the outer IP header isn't included in the ICV computation for the digital signature; only the ESP and user data parts are included. However, like AH, ESP doesn't work with PAT because PAT requires the use of TCP or UDP in the outer header and ESP is a Layer-3 protocol that lacks this functionality.

Address Translation Solutions

Given the above issues with address translation, there are some solutions available to you assuming you are willing to forgo the use of AH and stick with only ESP. Remember that ESP will work with NAT, but breaks with PAT. To have ESP interoperate with devices performing PAT, you could insert a TCP or UDP header between the outer IP header and the ESP part, as shown in Figure 3-8. By inserting either a TCP or UDP header, you make the address translation device happy and it can perform PAT; plus, because this information is in the outer header, it is not included in the HMAC process to create the digital signature (only the ESP header and user data are included).

Cisco products have three separate solutions, which are compared in the heading of Table 3-2. Of the three solutions, IPsec over UDP and IPsec over TCP are proprietary to Cisco. With IPsec over UDP, a standard UDP header is always inserted after the outer IP header and before the ESP header. This solves the address translation issue for PAT; however, the device is always performing this process even if no address translation device resides between the two IPsec peers performing PAT. The main problem of the Cisco UDP is that you always have the overhead of the UDP segment even if no address translation is occurring. The default destination port number that Cisco uses for the UDP port is 10,000, but this is customizable. Another limitation is that only Cisco VPN 3000 concentrators and Cisco VPN clients support this feature.

Table 3-2. Address Translation Solutions

Comparisons	NAT-T	IPsec over UDP	IPsec over TCP
Standard versus proprietary	RFC	Cisco	Cisco
Encapsulation method	UDP	UDP	TCP
When encapsulation is done	Tested	Always	Always

NAT transversal or traversal (NAT-T) provides an alternative solution with the UDP encapsulation process. Unlike IPsec over UDP, NAT-T is defined by RFC 3947/3948 and thus is an open standard. With NAT-T, a test ESP packet is sent between the two IPsec devices with a standard UDP segment header between the IP outer header and the ESP header. The destination UDP port number must be 4,500.

Note that the UDP header contains a checksum of the header information. This same UDP segment is protected and placed after the UDP header. When the destination receives the NAT-T packet it checks the checksum in the outer and inner UDP headers: if they don't match, an address translation device is performing PAT; otherwise, no address translation device is performing PAT. If the latter is true, then no UDP encapsulation is used; normal ESP packets are sent, thus reducing the overhead involved. Therefore, NAT-T is more efficient than Cisco IPsec over UDP, because the UDP encapsulation is done only if PAT is being performed on the ESP packet.

IPsec over TCP inserts a TCP header between the outer IP header and the ESP header. The default destination port number is 10,000, but this is customizable. IPsec over TCP has one disadvantage over IPsec over UDP: it adds more bytes of overhead than UDP.

IPsec and Firewalls

There are two basic ways VPN traffic is terminated in your network: on your firewall or on a device behind a firewall. First, in either case, you'll need to permit IPsec traffic into your network. Second, you might experience problems with stateful firewall products and allow returning IPsec traffic back into your network.

The next two sections will discuss both of these issues and how to deal with them when IPsec traffic has to travel to or through a firewall.

Allowing IPsec Traffic into Your Network

Given that IPsec traffic will probably be coming into your network from a public network, there are certain kinds of traffic you'll have to deal with at the perimeter of your network. You'll need to allow some of the following IPsec traffic into your network:

• Management connections: UDP port 500

• Data connections using AH: protocol 51

• Data connections using ESP with no address translation: protocol 50

• Data connections using ESP with NAT-T: UDP port 4,500

• Data connections using ESP with IPsec over UDP: UDP port 10,000 by default, but this can be changed

• Data connections using ESP with IPsec over TCP: TCP port 10,000 by default, but this can be changed and can include multiple ports for different remote peers

You want to be as specific as possible when allowing this traffic into your network to prevent any errant packets from getting through a packet filter.

Using Stateful Firewalls

Another issue can result if you are using a stateful firewall. A stateful firewall is an enhanced version of a packet filtering firewall. Packet filtering firewalls filter only on Layer-3 and Layer-4 information that they find in packet headers; they don't look at anything higher. Stateful firewalls also look at the session layer and keep track of sessions. For example, a stateful firewall would look at an outbound Telnet and know that because this session is allowed out, the returning traffic for that particular Telnet session should be allowed back in.

With TCP, the returning traffic can be inspected easily by the stateful firewall; examining the TCP flags in the TCP header allows the firewall to determine the beginning and end of the TCP session. With IPsec, this can be more problematic in tracking the IPsec connections. First, the management connection uses UDP and all messages are encrypted (with the exception of the first few). Therefore, determining when the connection is finished can be problematic; you don't want to leave the connection in the filtering table forever if it doesn't exist. Most stateful firewalls will use a timer for UDP traffic; if it's idle for more than X number of seconds, the firewall's assumption is that the connection is over, and it is removed from the state table. However, this can still pose a problem with the management connection if an outside peer initiates the connection. Then you would need a filtering rule to allow the inbound traffic.

However, most stateful firewalls don't support AH or ESP, which are Layer-3 protocols. A vendor could, for instance, use idle timers to approximate the end of a data connection session, but this could create problems. If the IPsec devices are idle, but still using the connection, and the stateful firewall would remove the connection from its state table, the data connection would fail. Because of this issue, vendors typically require you to use packet filtering rules to allow IPsec data connections into (or out of) your network, or they have a bypass feature that allows all AH and/or ESP packets through the firewall.

Another alternative solution is to use NAT-T or IPsec over UDP and then employ a keepalive function that periodically generates NAT keepalives across the ESP connection. This option was mentioned in the Note at the end of the "Address Translation Solutions" section.

Other Issues Using IPsec

There are two other issues to discuss before I end this chapter. The first issue deals with detecting dead peers. The second issue deals with a remote access client losing its connection and then trying to reestablish its connection to the same IPsec gateway.

Dead Peer Detection

Dead Peer Detection (DPD) is a fancy name for ISAKMP/IKE keepalives. DPD allows two peers to detect a dead management connection. This is a Cisco-proprietary feature, in an IETF draft state, which allows an IPsec device to discover a dead, or stale, set of IPsec connections.

This feature is important in both site-to-site and remote access implementations where redundancy is required. In other words, for remote access sessions, you need a method that allows a client to discover if the gateway is no longer responding, enabling it to tear down its current session and building a new one to a backup VPN gateway.

Likewise, for the VPN gateway in a remote access implementation, this allows the gateway to detect and remove dead connections, which can affect allowing the addition of new clients based on the license limit in effect on the VPN gateway. For example, the Cisco VPN 3005 concentrator (VPN gateway) supports 100 or 200 IPsec sessions, depending on the version of software running on the product. Dead remote access client sessions count against this license limit, so detecting and removing them is important.

Both of the above features also apply to site-to-site sessions. If your primary IPsec peer dies, you need a method to quickly discover this and build a new IPsec connection to a backup peer. Likewise, site-to-site devices have license limits that restrict the number of IPsec sessions, so removing dead ones is important in an environment that has a large number of IPsec sessions, especially if they're dynamic sessions.

Initial Contact

Initial contact is a Cisco-proprietary feature used in remote access IPsec VPNs. Initial contact is a necessary feature for remote access VPNs, especially where the client uses a dialup connection.

For example, a remote access client dials up to his ISP and establishes an IPsec session to a corporate VPN gateway. Then the client loses his dialup connection and redials, obtaining a different IP address from his last one. This can cause problems with the VPN gateway, because when the client connects again, using the same username and password for XAUTH, the concentrator might deny the connection, seeing that the connection is already "established" from the previously disconnected dialup connection.

DPD can be used to deal with this problem; however, depending on how often keepalives are generated, and how many have to be missed before the connection is considered dead, the user might not be able to reconnect for a few minutes. Therefore, Cisco developed initial contact, which allows the VPN gateway to remove the previously authenticated "dead" connection and reconnect the client by going through ISAKMP/IKE Phase 1 and 2 again.