Chapter 15: IPSec Phase 1 (Part 1)

Overview

This chapter will introduce you to using IPSec on your appliance, focusing on the configuration of IPSec Phase 1 and its components. The information in this chapter applies to both site-to-site (Chapter 16) and remote access IPSec sessions (Chapters 17 and 18) and lays the foundation for configuring IPSec site-to-site and remote access connections. The topics included in this chapter are

• IPSec introduction

• SAKMP configuration

• Tunnel groups

• Certificate authorities

These topics will reappear in subsequent chapters on IPSec.

Note

Because of space constraints, this chapter will not provide you an overview of VPNs, IPSec, its components, and how they work together, like my previous book did on the PIXs. For a more thorough discussion of VPNs, please read my book The Complete Cisco VPN Configuration Guide (Cisco Press, 2005)—the whole first part of the book (170 pages!) discusses VPNs.

IPSec Introduction

The VPNs supported by the appliances include IPSec, SSL (called WebVPN), PPTP, and L2TP. For IPSec, the appliances support both site-to-site and remote access VPNs. With IPSec site-to-site connections, you can connect your appliance to other appliances and firewalls, other routers, and VPN concentrators or gateways. For remote access, Cisco supports the Cisco VPN client, but other software and hardware clients are supported, including for mobile devices. If the device you want to connect to your appliance is IPSec-compliant, then it shouldn’t be an issue getting a VPN up and running. Chapter 16 focuses on site-to-site IPSec connections, commonly called LAN-to-LAN (L2L) connections; Chapters 17 and 18 discuss IPSec remote access, and Chapters 19 and 20 WebVPN.

IPSec Preparations

You’ll perform six basic tasks to set up an IPSec connection to a remote IPSec peer:

1. Handle design and policy issues.

2. Allow inbound IPSec traffic.

3. Configure the policies for ISAKMP/IKE Phase 1.

4. Configure the policies for ISAKMP/IKE Phase 2.

5. Verify your configuration.

6. Check the IPSec connection.

The preceding steps detail the tasks that you’ll have to complete to successfully set up your IPSec connection.

Same Interface Traffic

One main limitation of the appliance was that it could not be the hub device in a hub-and-spoke VPN topology through version 6 of the OS. The reason is that the appliance will not allow traffic to travel between interfaces of the same security level by default. For example, assume you have a PIX connected to two spokes, PeerA and PeerB. PeerA sends traffic across the VPN connection to the PIX, which in turn needs to forward it to PeerB. The PIX would not allow this (in version 6) since the original traffic came from the outside interface and then needed to be forwarded back out of the outside interface. Recall that since this is the same interface, the security levels of the entry and exit interfaces are the same, and the appliance denies this traffic. Therefore, if you had a hub-and-spoke design, you couldn’t use the PIX as the hub in version 6 and earlier. The Cisco solution to this problem in version 6 and earlier is to use a router as the hub in the hub-and-spoke design.

In version 7, the same-security-traffic command is used to allow VPN traffic coming into and out of the same interface (physical or logical):

ciscoasa(config)# same-security-traffic permit intra-interface

By default this feature is disabled.

ISAKMP Configuration

The ISAKMP and IKE protocols define how to establish an IPSec session between two peers. Three connections make up the session: one management and two data connections. The connections are built across two phases: in Phase 1, the management connection is built, and in Phase 2, the data connections are built. The management connection is used to share IPSec-related information between the peers. The data connections are used to protect actual user traffic between the peers. The data connections are unidirectional, which is why there are two, and are protected with either the AH and/or ESP protocols. Of the two, ESP is by far the most common one used for an IPSec session.

The remainder of this chapter will focus on global and Phase 1 properties that you can or need to configure on your security appliance. Most of the commands to configure IPSec on an appliance are very similar to those used on Cisco IOS routers. Some, especially those relating to tunnel groups, are very different, though. Some of the commands introduced here will be more thoroughly covered in subsequent chapters.

Global ISAKMP Properties

This section will discuss the use and configuration of global properties for ISAKMP and IKE, like how to enable them, specify the identity type, send disconnect notices, and configure the mode to use.

Enabling ISAKMP

ISAKMP and IKE are disabled by default on the appliance in 7.2 and later—they need to be enabled on each interface you’ll terminate IPSec tunnels on. Use the following command to enable them:

ciscoasa(config)# [no] crypto isakmp enable logical_if_name

Note

You need at least a DES encryption key to set up VPNs on your appliance.

ISAKMP Identity

The ISAKMP identity type is used with IPSec L2L sessions and defines how you will refer to remote peers: based on their IP address or their name. The identity type is controlled by the crypto isakmp identity command:

ciscoasa(config)# crypto isakmp identity {address | hostname |
                       key string | auto }

The configuration of this command will affect the syntax of other IPSec commands on the appliance. By default the identity type is address for peers, which is the IP address of the peers. The hostname parameter specifies that the fully qualified domain name will be used to identify remote peers. The key parameter specifies a custom string value to uniquely identify peers. The auto parameter specifies that IP addresses identify peers that use pre-shared keys for authentication and that fully qualified domain names identify peers that use digital certificates.

Phase 1 Modes—Aggressive and Main

ISAKMP and IKE go through two phases in setting up an IPSec session. During Phase 1, the management connection is built. Two modes can be used to establish the management connection: aggressive and main. Aggressive mode is faster in the setup process, but less secure; main mode is slower, but more secure. The authentication method chosen will depend on the mode used. By default aggressive mode is used when pre-shared keys are configured for authentication, and main mode is used when certificates are configured. The following command disables aggressive mode and forces the appliance to use main mode for the Phase 1 connection:

ciscoasa(config)# crypto isakmp am-disable

Disconnect Notice

When tearing down IPSec tunnels, you can have the appliance send a disconnect notification with the following command:

ciscoasa(config)# crypto isakmp disconnect-notify

ISAKMP Policies

Phase 1 policies define how the management connection can be protected. During Phase 1, the policies are shared between the two peers, where a matching policy must be found in order for the two peers to continue building the management connection. The negotiated policies are then used to secure the management connection.

The configuration of a Phase 1 policy on the appliance is the same as on an IOS router:

ciscoasa(config)# crypto isakmp policy policy_number
ciscoasa(config-isakmp-policy)# authentication {pre-share | rsa-sig |
                                 crack}
ciscoasa(config-isakmp-policy)# encryption {3des | aes | aes-192 |
                                 aes-256 | des}
ciscoasa(config-isakmp-policy)# group {1 | 2 | 5 | 7}
ciscoasa(config-isakmp-policy)# hash {md5 | sha}
ciscoasa(config-isakmp-policy)# lifetime {seconds | none}

When setting up a policy, if you don’t specify a command in the policy, the appliance will use a default: pre-shared keys for authentication, 3DES for encryption, Diffie-Hellman (DH) group 2 keys, SHA HMAC function, and a lifetime of one day (86,400 seconds).

The policy number ranks the policies on the appliance: you might need more than one policy if you have different peers with different capabilities. The policy with the lowest number (1) is the highest-priority policy, and the policy with the highest number (65,535) is the lowest-priority policy. You can choose from three authentication methods: pre-shared keys, certificates (RSA signatures), and the Challenge/Response for Authenticated Cryptographic Keys (CRACK). CRACK is commonly used with mobile and smart phone devices. If you will be using DH group 5, you must use AES as an encryption algorithm. The lifetime command specifies how long the parameters should be used for the negotiated management connection before either they should be changed or the management connection torn down; if you specify none for the lifetime, the management connection will never time out, and thus won’t be rekeyed. To view your ISAKMP policies, use the show run crypto isakmp policy command.

NAT Traversal and IPSec over TCP

The management connection, which is protected by the negotiated policy, is encapsulated in UDP and sent to port 500. The two data connections in Phase 2 use ESP and/or AH to encapsulate the data for users. These latter protocols, however, pose problems when going through address translation or stateful firewall devices.

AH and ESP Issues

When going through an address translation device, AH breaks, since the input for the digital signature it creates includes the source and destination IP addresses in the outer IP header. On top of this, AH is a layer 3 protocol and thus lacks ports needed when PAT is performed. Therefore, AH is unsupported when going through any type of address translation. Also, I know of no stateful firewall that supports AH—for example, with Cisco appliances, you must use an ACL to allow returning AH traffic.

ESP also supports digital signatures, but excludes the outer IP header when generating its digital signature; therefore, ESP doesn’t break when NAT is performed. However, like AH, ESP is also a layer 3 protocol and thus is not supported by PAT or most stateful firewall products. The following two sections discuss two solutions to this problem for ESP—there are no solutions for AH.

Tip

If the management and data connections are established, but data can’t be successfully transmitted between the two peers, a translation or stateful firewall device might be causing the problem. Remember that during Phase 2, even though the data connection parameters can be successfully negotiated, this does not mean that the devices can successfully transmit data across these connections.

NAT Traversal

NAT Traversal, sometimes called NAT Transparency (or NAT-T for short), is an IPSec standard that inserts a UDP header between the outer IP header and the ESP header. The destination port for NAT-T is 4500. Intelligence is used with NAT-T: a discovery phase takes place during Phase 1 to determine if the two peers support NAT-T, and if they do support it, whether inserting a UDP header is necessary for the data connections to be successful in protecting and transmitting data. This is a dynamic process: if inserting a UDP header is needed, then it is done; if it is unneeded, then it is not inserted (inserting a UDP adds an additional 8 bytes of overhead).

NAT-T is globally enabled by default. One of its features is that keepalives are sent across the data connections to ensure that address translation or stateful firewall devices don’t remove any idle data connections. The default idle period is 20 seconds. To change the keepalive timer interval, use the following command:

ciscoasa(config)# crypto isakmp nat-traversal [seconds]

The period can range from 10 to 3600 seconds.

IPSec over TCP

There are two problems with NAT-T, however:

• It uses UDP, which typically has a much smaller idle timeout than TCP connections for translation and stateful firewall devices.

• You are forced into using destination UDP port 4500 (it cannot be changed), which might be filtered by an intermediate device.

Cisco created a proprietary encapsulation method, called IPSec over TCP, to overcome these two problems. With IPSec over TCP, a TCP header is inserted between the outer IP header and the ESP header. IPSec over TCP is disabled, but can be enabled with the following command:

ciscoasa(config)# crypto isakmp ipsec-over-tcp {[port prt_#]...[prt_#]}

One advantage that IPSec over TCP has over NAT-T is that you can control what port or ports (up to 10) can be used; by default port 10000 is used.

Note

There are two problems with IPSec over TCP: it is Cisco-proprietary, which means the endpoints must be Cisco devices, and IPSec over TCP inserts a 20-byte header, almost three times as much as NAT-T inserts. Also, NAT-T and IPSec over TCP are commonly used for remote access connections, where intermediate firewalls and translation devices are more likely to be encountered.

VPN Traffic and ACLs

The following two sections will discuss how to deal with IPSec traffic flowing to or through the appliance.

IPSec Sessions Terminated on the Appliance

If your appliance has IPSec sessions terminated on it, you have two options to allow the traffic to flow from a lower- to higher-level interface:

• ACLs

• ACL bypass feature

For the first option, you’ll need to add ACL statements for the decrypted IPSec traffic on the external interface ACL: once the traffic is decrypted, it is passed through the external interface ACL and must match a permit statement, or it is dropped.

The second option exempts the decrypted VPN traffic from being processed by the external interface ACL, assuming that the VPN session is terminated on the appliance. To configure the ACL bypass feature, use this command:

ciscoasa(config)# sysopt connection permit-vpn

The problem with this command is that any traffic coming out of the VPN tunnel is permitted; as you will see in subsequent chapters, you can control which traffic uses the VPN tunnel.

IPSec Sessions Terminated Behind the Appliance

If IPSec sessions are terminated on devices behind the appliance, you’ll need ACL entries on your external interface to allow the management and data connections through the appliance to the internal IPSec endpoint:

ciscoasa(config)# access-list ACL_ID permit udp src_IP src_mask
                       dst_IP dst_mask eq isakmp
ciscoasa(config)# access-list ACL_ID permit esp src_IP src_mask
                       dst_IP dst_mask
ciscoasa(config)# access-list ACL_ID permit udp src_IP src_mask
                       dst_IP dst_mask eq non-isakmp

ciscoasa(config)# access-list ACL_ID permit tcp src_IP src_mask
                       dst_IP dst_mask eq IPSec_over_TCP_port

The first command allows the management connection. The following three connections allow the data connections: the second allows the ESP protocol, the third allows NAT-T, and the fourth allows IPSec over TCP. You’ll need to configure the entries appropriate for your network and its configuration.