IPsec Preparation

As with any type of VPN implementation, one of the first steps you'll go through is preparation. This is important for IOS-based routers because the configuration is more complex than setting up a GUI product like the Cisco VPN 3000 concentrators. The next few sections will briefly cover some basic information you'll need to gather, basic configuration tasks you'll perform on your routers, and additional ACL statements you'll need to add to perimeter routers to build IPsec sessions.

Gathering Information

The first step you'll take for your preparation is to gather information that will help you implement your IPsec sessions. If you recall from Chapter 3, "IPsec," two sets of connections are built: a management connection in ISAKMP/IKE Phase 1 and two unidirectional data connections in Phase 2. Each set of connections has protection properties you need to define. For example, with the Phase 1 connection, you'll need to minimally define the following:

• Device authentication type: pre-shared keys, RSA encrypted nonces, or RSA signatures (digital certificates)
• HMAC function: MD5 or SHA-1
• Encryption algorithm: DES, 3DES, or AES
• Diffie-Hellman (DH) group: 1, 2, or 5
• Lifetime of the connection: defaults to 86,400 seconds

For the Phase 2 connection, you'll need to define the following:

• What traffic is to be protected: crypto ACL
• To whom the protected traffic should be forwarded: IPsec peer
• How the traffic is to be protected: transform set
• What traffic should be protected to which peer: crypto map entry
• If Perfect Forward Secrecy (PFS) should be used to share new keying information for the data connections: DH groups 1, 2, or 5
• How long the data connection is valid: defaults to 3,600 seconds

Of course, the above items are the minimum items you'll need to identify and configure. In this chapter, though, I'll focus only on the first set of bullet points.

Allowing IPsec Traffic

One of the tasks you'll need to perform is to allow IPsec traffic into your network on your perimeter routers and firewalls. For a perimeter router, at a minimum you'll need to add the following entries into your ACL (assuming it's a numbered ACL and your perimeter router is using ACLs for filtering):

Router(config)# access-list ACL_# permit udp host remote_peer_IP
 host local_router's_IP eq 500
Router(config)# access-list ACL_# permit ahp host remote_peer_IP
 host local_router's_IP
Router(config)# access-list ACL_# permit esp host remote_peer_IP
 host local_router's_IP
Router(config)# access-list ACL_# permit udp host remote_peer_IP
 host local_router's_IP eq 4500

The first ACL statement allows the management connection to the router. With your ACL statements for L2L sessions, you want to be as specific as possible with the remote peer's IP address and the local router's IP address; with remote access sessions you might not know the source address, so you would typically use the keyword any for the source address and wildcard mask (this applies to the other ACL statements as well). The second statement is probably not necessary because AH doesn't work with any type of packet manipulation, such as address translation and QoS, and therefore isn't used commonly when sending protected traffic across a public network. The third statement allows the two data connections into the router. If you need to use NAT Traversal (NAT-T) because of PAT being performed or because of a firewall breaking ESP traffic, then instead of configuring the third ACL statement, you would configure the fourth. Remember that NAT-T encapsulates ESP in a UDP segment with a destination port number of 4,500.

Note

Remember that many remote access IPsec clients, like Cisco clients, have NAT-T enabled by default. Also, if you'll be using IPsec over UDP or IPsec over TCP for your data connections, you'll also need to allow this traffic in your ACLs on your perimeter devices.