Table 7.1 lists the primary products in the Cisco product portfolio that can be used to deploy VPNs.

TABLE 7.1 Cisco VPN Products

VPNs have many benefits, including the following:

    Cost Savings. The use of cost-effective, high-speed Internet technologies versus dedicated WAN links makes VPNs attractive.

    Security. Advanced encryption, integrity, and authentication protocols provide for the highest protection against unauthorized access and data loss.

    Scalability. VPNs can grow seamlessly without the need to add extra infrastructure, particularly when using the Internet.

    Compatibility with Broadband Technology. VPN technology is largely independent of the underlying infrastructure, meaning that organizations can leverage on the most convenient broadband technology for the greatest flexibility.

There are two main types of VPNs:

    Site-to-site

    Remote-access

With a site-to-site VPN, host devices operate behind network devices, such as IOS routers, which act as VPN gateways. This is an evolution of WAN technology. The host devices do not need any special software because the fact that there is a VPN between sites is immaterial to them, as the VPN is established between other devices, possibly their own default gateway in the simplest case.

For example, if we configure IOS routers to be VPN gateways, the IP hosts in the production network behind the router would only have to attempt to establish a connection with a device on the inside of a peer network’s router. The host’s own VPN router would recognize that this site-to-site traffic from the local site to the remote site needs to be protected by the VPN and it would launch a tunnel (that is, the VPN) to its peer if one doesn’t already exist. This is illustrated with a small modification to the reference network layout that was first introduced in Figure 5.1 of Chapter 5, “Using Cisco IOS Firewalls to Implement a Network Security Policy.”

In Figure 7.1, all traffic between the A and B networks is protected inside a site-to-site VPN between router A and router B.

FIGURE 7.1 Site-to-site VPN.

A device inside network A’—the system administrator PC, for example—would already have router A as its default gateway. Something magic happens from that PC’s perspective because when it tries to communicate with the private (RFC 1918) addresses in network B’, it gets a response. Breaking it down just a little bit, this is what happens:

    Confidentiality. The IP packet from the system administrator’s PC, from network A’ to network B’, is encrypted before it is encapsulated in another IP packet to router B. Similarly, upon receipt, router B decrypts the A’ to B’ packet before delivering it to the destination host on the B network.

    Integrity. As we see in the section, “Conceptualizing a Site-to-Site IPsec VPN,” it’s possible that when the encrypted packet is sent to router B from router A, there is some integrity information added to the packet to add some assurance that the packet has not been tampered with in transit.

    Authentication. Additionally, some authentication information might have been added to the encrypted IP packet to add assurance that it actually came from router A. Remember the C-I-A triad from Chapter 1, “Network Insecurity”? The “A” in the VPN C-I-A triad stands for authentication.

The optional integrity and authentication information will add some extra overhead per unit of data transmitted. It is up to the guidelines contained in the organization’s comprehensive security policy as to whether an acceptable tradeoff has been achieved between security and performance. Many VPN implementations implement confidentiality only, relying on other layers of the OSI model to provide for integrity and authentication outside the context of the VPN.

In the same way that site-to-site VPNs evolved from traditional WANs, remote-access VPNs are an evolution of dial-up networking technology. Certainly the same principles of C-I-A apply here. The two most evident differences between remote-access and site-to-site VPNs are the following:

    Remote-access VPN clients initiate the VPN on demand.

    The remote-access client (whether a PC or a Cisco hardware device) requires Cisco VPN client software to connect.

When implemented as a software solution on a remote user’s PC, this can be a very flexible solution. The teleworker can benefit from the same confidentiality, integrity, and authentication services of a site-to-site VPN, while using whatever Internet technologies are at their immediate disposal.

Referring to Figure 7.2, a corporate knowledge worker could be sipping designer coffee at their local coffee shop’s wireless hotspot while protecting corporate secrets on network A’ from hackers and the merely curious.

FIGURE 7.2 Remote Access IPsec VPN.

Cisco specifies another type of VPN that uses a web browser’s built-in Secure Sockets Layer (SSL) encryption to encrypt at the transport layer of the OSI model. One advantage of this solution is that in its simplest form, it doesn’t require the installation of additional software on a client PC. SSL VPN offers two modes of operation:

    Clientless. Uses a web portal to access hosts behind the gateway. Access to file and print shares, email servers, web servers, and other services is provided by the web portal’s interface.

    Client. Uses a thin client that provides an IP address and thus the ability to access applications with their native interface.

The SSL VPN solution is an emerging technology that complements Cisco’s IPsec VPN offerings.

Some disadvantages of the SSL VPN solution are as follows:

    Software-Only. One disadvantage is that it is a software-only solution in IOS routers; thus, it doesn’t take advantage of the hardware-accelerated onboard encryption in many router models. The router (and the client) CPU processes all the encryption.

    Cryptographic Security. Does not currently support the same level of encryption security as IPsec.

SSL VPNs have compatibility advantages. SSL VPNs can be configured and operate alongside other features on Cisco network devices. SSL VPNs are compatible with the following:

    Dynamic Multipoint VPNs (DMVPNs)

    Cisco IOS Firewalls

    IPsec

    Intrusion Protection Systems (IPSs)

    Cisco Easy VPN (Cisco’s remote-access IPsec VPN solution)

    Network Address Translation (NAT)

Here are some of the VPN features of the Cisco VPN-enabled IOS routers:

    Voice and Video Enabled VPN (V3PN). Integration of QoS, IPsec, and VoIP (IP telephony).

    IPsec Stateful Failover. Provides for network resiliency in site-to-site VPN configurations, in both stateless and stateful failover solutions. Options include the following:

    Dead Peer Detection (DPD)

    Hot Standby Router Protocol (HSRP)

    Reverse Route Injection (RRI)

    Stateful Switchover (SSO)

    DMVPN. Enables automatic provisioning of site-to-site IPsec VPNs, putting together three Cisco IOS features:

    Next Hop Resolution Protocol (NHRP)

    Multipoint GRE

    IPsec VPN

    Cisco Easy VPN. Cisco’s common framework for remote-access IPsec VPNs.

As you can infer from Table 7.2, the primary purpose of the ASA 5500 Series security appliances is as a perimeter security device that implements the organization’s comprehensive security policy. Because the IT security staff own the policy, they also own the security appliance and any policies, including the VPN, which are configured on it. In the context of VPN technology, the ASA 5500 Series of security appliances is Cisco’s direct replacement for the 3000 Series VPN concentrators, of which many tens of thousands still exist in the field. Here are some of the features of the ASA 5500 Series of security appliances:

    Flexible Platform. IPsec and SSL VPN solutions on one platform that also supports application inspection firewall and IPS.

    Resilient Clustering. VPN load balancing and backup server in a mixed environment of ASAs and VPN concentrators.

    Cisco Easy VPN. Cisco’s common framework for remote-access IPsec VPNs. Also supports automatic Cisco VPN Client updates.

    Cisco IOS SSL VPN. Both clientless and client-based solutions.

    Web-Based Management. The Cisco Adaptive Security Device Manager (ASDM) configures and manages all the security and VPN features of the appliance.

Let’s eliminate confusion here before it even begins! Cisco’s product planners have been hard at work coming up with worthy names for their VPN remote-access solutions, both IPsec and SSL:

    Easy VPN. If it’s a remote-access IPsec VPN solution, regardless of whether the client uses Cisco software on a PC or the client is a device such as a router, it is called Easy VPN. Of course, it would be too easy if the client was called a client! The client is called an Easy VPN Remote. The VPN server is called an Easy VPN Server. See how easy that is?

    WebVPN. If it’s a remote-access SSL VPN solution, it is called WebVPN, regardless of whether the client is a web browser accessing servers behind the server’s web portal, or a thin client such as the SSL VPN Client (SVC) or the newer standalone AnyConnect VPN Client (currently only supported on the ASA 5500 Series Adaptive Security Appliance).

Here are some Cisco VPN clients. See if you can determine which broad category, Easy VPN or Web VPN, they fall into (the answers are after the list):

    Certicom Client. IPsec VPN client software that runs on wireless PDAs with either the Palm OS or Windows Mobile operating systems.

    Cisco VPN 3002 Hardware Client. (EOS February 2007) Dedicated remote-access VPN client appliance. Connects SOHO LANs to the VPN.

    Cisco VPN Software Client. Software loaded on an individual’s PC or laptop that initiates an IPsec VPN to a central site VPN server. Comes in versions for Linux, Mac, and Windows OSs.

    Cisco AnyConnect VPN Client. SSL VPN client software loaded on an individual’s PC or laptop that initiates an SSL VPN to a central site VPN server. Currently supports Windows Vista, XP, and 2000 OSs, as well as MAC OS X (version 10.4 or later) and Red Hat Linux (version 9 or later).

Answers: Certicom Client = Easy VPN; Cisco VPN 3002 Hardware Client = Easy VPN; Cisco VPN Software Client = Easy VPN; Cisco AnyConnect VPN Client = WebVPN.

Cisco offers hardware modules for modular routers, security appliances, and concentrators that will offload encryption processing from the device’s CPU and thus increase encrypted throughput:

    AIM-VPN (Advanced Integration Module). Certain modular IOS router models.

    Cisco IPsec VPN SPA (Shared Port Adapter). Catalyst 6500 Series switches and 7600 Series routers.

    SEP-E (Scalable Encryption Processor–Enhanced). VPN 3000 Series concentrators.

    VAC+ (VPN Accelerator Card +). Modular PIX Firewalls.

Cisco’s VPN product portfolio consists of both IPsec and SSL VPN solutions in order to give the most choices to their customers. Whether you choose IPsec or SSL for your VPN solution, there are some tradeoffs between usability and security. The AnyConnect SSL VPN solution, for example, is simple to use and tolerates very well NAT devices on the path between the client and the server. In IPsec VPN’s favor is the strong authentication that can be used to secure the communication path.

TABLE 7.3 IPsec Compared to SSL

You can see IPsec’s many strengths in Table 7.3. We will now turn our focus to IPsec VPNs, specifically site-to-site configurations.

IPsec is an Internet Engineering Task Force (IETF) standard that defines a framework of open standards for secure, real-time communication using IP. Like IP, it works at the network layer, and while it is deliberately security algorithm-independent, it does provide an environment into which various encryption, authentication, and keying algorithms can be plugged in. It is described in RFCs 2401–2412 and was designed as a native component of IPv6, but has been ported to IPv4, where our focus lies. IPsec can be recognized inside an IP packet by its protocol IDs, 50, and 51, which are reserved for ESP (Encapsulating Security Payload) and AH (Authentication Header), respectively.

IPsec’s framework provides its own C-I-A triad (actually C-I-A-A):

    Confidentiality. Uses encryption algorithms (encryption is optional with IPsec VPNs. See the following note).

    Integrity. IPsec policies must implement hashing algorithms to assure date integrity.

    Authentication. Peers must authenticate during tunnel establishment. Optionally, origin authentication is specified to verify that packets come from an authenticated peer. Authentication is managed by the Internet Key Exchange (IKE) and can take different forms.

    Anti-Replay. IPsec must provide assurance of each packet’s uniqueness and that it hasn’t been duplicated through sequencing and the use of a sliding window.

IPsec is versatile as it allows for new and better security protocols in every facet of IPsec’s C-I-A because it is security algorithm-independent. Think of the different components that fit into IPsec as modular, hot-swappable plug-ins. Let’s look at the different elements of C-I-A separately.

Confidentiality: Encryption Algorithms

Confidentiality is assured through the use of encryption algorithms (or ciphers) and encryption keys. Only the VPN peers know what encryption algorithms they have negotiated and which keys they have arrived at (calculated). This information is never transmitted with the encrypted payload, so good luck breaking the code if you’re an attacker! Of course, the shorter the key, the easier it is to guess. The longer the key, the harder it is to guess, and the longer it takes to create encrypted data because the key is used with the encryption algorithm to create encrypted data, or ciphertext. This is where it would be useful for the VPN peer to possess hardware-accelerated encryption as this can be burdensome on the CPU, again pointing at the classic tradeoff between security and usability. This becomes a critical issue when the VPN peer supports hundreds or thousands of VPN connections simultaneously.

Figure 7.3 gives a high-level overview of the relationship between cleartext, ciphertext, encryption, decryption, and encryption algorithms and encryption keys.

FIGURE 7.3 Overview of the relationship between encryption algorithms, encryption keys, and VPNs.

Where do these keys come from? How long are they? We’re getting a bit ahead of ourselves because we haven’t considered how the encryption algorithms and encryption keys are negotiated between the peers. As we will see in the later section, “IKE Phase I: The IKE Protocol,” the keys are either manually configured or dynamically negotiated (calculated) when the VPN is being established during the Diffie-Hellman (DH) key exchange phase. See the next section for a bit more information on DH.

Here are some encryption algorithms and their associated key lengths that VPNs use:

    DES (Data Encryption Standard). This cipher uses 56-bit keys. It is a symmetric key crypto system.

    3DES (“Triple” or “Three” DES). Using DES as a verb, 64-bit blocks of data are DES’d three times. The base key is still 56 bits. Often described as a 168-bit cipher, but we know better, right? 3DES is a symmetric key crypto system.

    AES (Advanced Encryption Standard). 128-, 192-, or 256-bit keys. AES has stronger security than DES and is computationally more efficient than 3DES. It was adopted by the National Institute of Standards and Technology (NIST) as a replacement for DES and as a result of a competition.

    RSA (Rivest, Shamir and Adleman). Not used by IPsec for encryption (C), though RSA encryption can be used during peer authentication (A). RSA uses 512-, 768-, 1024-bit, or larger keys. It is an asymmetric key crypto system.

    SEAL (Software-Optimized Encryption Algorithm). Stream cipher that uses a 160-bit key for encryption.

Creating an Encryption Key: The Diffie-Hellman Key Exchange

Again, we will put off the discussion for where and how the DH key exchange occurs during IPsec tunnel establishment. For now, it is important to know that it is a necessary component of IPsec and is a way for VPN peers to arrive at a share-secret encryption key for symmetric protocols, such as DES and 3DES, which require it. It describes a secure method for VPN peers to calculate a shared-secret key over a public network without having to resort to some out-of-band method such as a courier or a phone call for transmission. This sounds impossible, and was in fact considered as such by cryptographic experts for many years. DH makes VPNs more practical because the shared encryption key is negotiated on demand during the VPN setup.

DH algorithms supported on Cisco IOS routers include DH Groups 1, 2, 5, and 7 (DH1, DH2, DH5, and DH7 for short).

In every mode of operation, the payload of the IP packets transmitted between the peers is encrypted and not the IP packet header, where the routing information resides. Because IPsec is just cargo (same as TCP, UDP, ICMP, and so on) from the perspective of an IP network, implementing IPsec is transparent.

Other strengths of IPsec include the following:

    Data Link Layer independent and Application Layer independent. Because IPsec operates at the network layer, it is supported by all data link layer protocols.

    Extremely scalable. With careful design, IPsec can scale to very large networks.

Before we start looking at the details, we should look at IPsec at a high level. It’s easy to over-simplify and speak of a single VPN tunnel. In reality, IPsec constructs two tunnels called Internet Key Exchange (IKE) security associations (SAs):

    IKE Phase I SA. All negotiation and authentication between VPN peers occurs in this security association.

    IKE Phase II SA. Data is transformed (encrypted, verified, authenticated) and transmitted in this security association.

Figure 7.4 depicts a high-level overview of IKE Phase I and IKE Phase II security associations.

FIGURE 7.4 High-level view of IKE Phase I and IKE Phase II.

If you understand how the File Transfer Protocol (FTP) works, then you also have a good idea about how IPsec VPNs work. As with FTP, IPsec creates two security associations; one that manages the control plane (Phase I) and another which manages the data plane (Phase II).

IKE Phase I: The IKE Protocol

Negotiating what? Authenticating what? No surprise that IKE Phase I is where all the separate components of the IPsec framework are negotiated between the peers. Encryption algorithms, encryption keys, HMACs, authentication method, and other parameters are negotiated between the peers. Even how to negotiate is negotiated! Once the peers agree on the parameters for the Phase I SA, the peers authenticate to one another and Phase I completes. Phase II negotiation can now occur. A good way to remember the separate IPsec policy elements, which are negotiated during Phase I, to remember the acronym HAGLE. Of course, this is a (misspelled) play on words because “haggle” is slang for negotiate and that’s what happens during Phase I.

Table 7.4 explains the separate elements of the HAGLE acronym.

TABLE 7.4 HAGLE During IKE Negotiation

Exam Alert

This is an excellent memory aid. Make sure you memorize it and the choices inferred by each of the letters in HAGLE.

The IPsec policy elements in the table should look familiar by now. Let’s break down what happens during IKE Phase I a bit further by looking at a list of the negotiation and authentication tasks that IPsec uses IKE to accomplish:

    Automating the encryption key exchange process by:

    Negotiating SA parameters.

    Automating key generation.

    Automating key refreshing.

    Providing for manual configuration.

    IKE specifies three modes (in order) for negotiating parameters and establishing security associations:

    Main mode (MM): Negotiating IKE Phase I SA (see the following note).

    Aggressive mode (AM): Negotiating IKE Phase I (see the following note).

    Quick mode (QM): Negotiating IKE Phase II.

Figure 7.5 diagrams a main mode exchange between two VPN peers, Peer A and B, which in this example are both IOS VPN routers.

FIGURE 7.5 IKE Phase I main mode exchange.

As can be seen, main mode uses three two-way exchanges:

    Exchange One. VPN peers propose and agree upon encryption algorithms, authentication method, and HMACs that will be used to secure subsequent IKE communications. This is where HAGLE occurs. The elements of HAGLE are called policy sets.

    Exchange Two. VPN peers employ Diffie-Hellman (DH) to create share-secret encryption keys. This share-secret encryption key is the base for generation of all other encryption and authentication keys. A secure channel (the SA) is now established.

    Exchange Three. Authentication occurs. If successful, the SA remains up; otherwise, it is torn down by the initiator.

After these three exchanges complete successfully, a secure and authenticated communication path (that is, the Secure Association) is established that is used for all subsequent exchanges between the peers. It’s useful to note that exchange three is secure because the initiator will not send its own authenticators (PSK, RSA digital signature, or RSA encrypted nonce) until it has verified the responder’s.

Breaking it down a bit more, here is additional information you need to know about what happens inside main mode exchanges one and two.

At a high level, IKE Phase II performs these functions:

    Negotiates IPsec Transform sets.

    Establishes IPsec SAs (at least two; see Figure 7.6).

FIGURE 7.6 IKE Phase II SAs

    Periodically renegotiates IPsec SAs.

    (Optional) Performs an additional DH key exchange.

Remember that all negotiating and authentication occurs within IKE Phase I. So, where do you think IKE Phase II negotiations occur? They are conducted in the secure channel established during IKE Phase I negotiations (AM or MM) and use Quick Mode (QM). For example, during QM, policies such as the following are negotiated:

    Which networks will be protected by the VPN (for example, Net A’ <—> Net B’).

    Encryption algorithm for the Phase II SA.

    HMACs.

    Transport mode versus tunnel mode (discussed in the “Transport Mode Versus Tunnel Mode” section later).

    ESP versus AH.

Figure 7.6 depicts IKE Phase II SAs. Using the FTP analogy again, this is the data plane of the IPsec VPN and is protected by the encryption algorithms contained in the transform sets.

Interestingly, an IKE Phase II SA is unidirectional, meaning that you need two SAs for bidirectional data flow between VPN peers. This is indicated in Figure 7.6. The SAs are identified by their Security Parameter Index (SPI) numbers. For example, once the VPN was established, Peer B would have SPI AB as an inbound SPI and SPI BA as an outbound SPI in its Security Association Database (SAD).

We now examine some of IPsec’s data transport features, protocols, and algorithms.

Encapsulating Security Payload (ESP)

If your VPN solution requires confidentiality, you must choose Encapsulating Security Payload (ESP) for transport of IPsec data. As indicated previously, AH can be used with ESP to provide for data integrity and data authentication; thus covering all the letters in C-I-A. ESP is encapsulated in an IP packet as protocol 50.

ESP features are as follows:

    Data confidentiality through encryption.

    Assures data integrity.

    Origin authentication.

    Anti-replay protection.

Referring to Figure 7.7, an IP packet with source address A’ and destination address B’ arrives at peer A. Peer A applies C-I-A services to the packet as required Depending on the transform sets negotiated between the peers, not all the facets of C-I-A will be applied to the packet that will travel in the IPsec VPN between the peers. Assuming that confidentiality will be applied as a minimum, then we must use ESP for encapsulation. This also enables us to optionally apply integrity and authentication services to the packet. If you were to look at the IPsec packet on a protocol analyzer, you will see that the order of the extra fields added while encapsulating the original IP packet are C (ESP Header), I (ESP Trailer), and A (ESP Authentication Trailer) = C-I-A.

FIGURE 7.7 Syntax of tunnel mode IPsec packet.

    C. Peer A encrypts the packet and places it into a new IP packet, prepending the encrypted payload with an ESP header. This provides for confidentiality.

    C and I. If integrity assurance is required, Peer A will add an integrity checksum (a hash) in the form of an ESP trailer before encrypting the original packet and placing it in the payload of the new IP packet.

    C and I and A. If origin authentication is required, an authentication checksum (similar to a frame check sequence in a data link layer frame) will be added to the payload of the new IP packet but will not be encrypted.

Exam Alert

Have you noticed that the order of the fields in the IPsec payload of the IP packet is C-I-A, making it simple to remember?

We will set up an IPsec site-to-site VPN using first the CLI and then second (next section) with the Cisco SDM. Using the CLI is a very good way to demonstrate how IPsec VPNs work because manual configuration of the protocols, policies, and rules reinforces much of the theory.

The basic tasks for implementing IPsec on a site-to-site VPN using the CLI can be broken into five steps, as follows:

Step 1. Ensure that existing ACLs are compatible with the IPsec VPN.

Step 2. Create ISAKMP (IKE Phase I) policy set(s).

Step 3. Configure IPsec transform set(s).

Step 4. Create crypto ACL that defines traffic that will be in the IPsec VPN (for example, Net A’ <—-> Net B’).

Step 5. Create and apply the crypto map (IPsec tunnel interface).

Figure 7.8 illustrates the reference design for the following worked example of the steps for implementing IPsec on a site-to-site IPsec VPN using the CLI.

FIGURE 7.8 Reference diagram for site-to-site IPsec VPN.

Step 2: Create ISAKMP (IKE Phase I) Policy Set(s)

Recall that IKE policies group all the separate elements of HAGLE into a policy set. If you need more than one IKE policy, you can create a policy suite. The crypto isakmp policy command creates the policy set. In this example, we leverage on the HAGLE acronym and create policy set 99 with the following:

H = SHA-1

A = PSK

G = DH5

L = 86,400 seconds

E = 128-bit AES

CiscoISR-A(config)#crypto isakmp policy 99
CiscoISR-A(config-isakmp)#hash sha
CiscoISR-A(config-isakmp)#authentication pre-share
CiscoISR-A(config-isakmp)#group 5

CiscoISR-A(config-isakmp)#lifetime 86400
CiscoISR-A(config-isakmp)#encryption aes
CiscoISR-A(config-isakmp)#

If we don’t need to create any more policy sets for our policy suite, we are finished with this step. You may create other policy sets, but remember that the lower the number, the higher the priority. It is good practice to put the cryptographically strongest policies near the top of the policy suite by assigning numerically lower numbers.

Also, you must ensure that the Peer B has a policy set that matches Peer A’s.

Table 7.5 shows a list of possible ISAKMP parameters when you construct a policy set. If you don’t specify a parameter, the Cisco IOS will choose the default.

TABLE 7.5 ISAKMP Policy Set Parameters

In our example, we specified that we would use a PSK for authentication. Because it is possible that we may have several tunnels to the same peer, the PSK is not tied to a specific policy set. To configure a PSK, use the crypto isakmp key global configuration command. Note that the PSK is case-sensitive:

CiscoISR-A(config)#crypto isakmp key Cisc0R0ck5! Address 172.16.32.1

Alternatively, if you know the fully-qualified domain name (FQDN) of Peer B, you could type:

CiscoISR-A(config)#crypto isakmp key Cisc0R0ck5! Hostname peerB.abc.com

Note

With the crypto isakmp key command, if you use hostname or IP address to identify a VPN peer, then that peer’s configuration must identify your device using the same method.

Verify your configuration of both the ISAKMP policy set you created and the default policy set with the show crypto isakmp policy command. Effectively, you now have a policy suite with two policy sets in it: policy set 99, and the default Cisco IOS policy set.

CiscoISR-A#show crypto isakmp policy

Global IKE policy
Protection suite of priority 99
encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
hash algorithm:         Secure Hash Standard
authentication method:  Pre-Shared Key
Diffie-Hellman group:   #5 (1536 bit)
lifetime:               86400 seconds, no volume limit
Default protection suite
encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
hash algorithm:         Secure Hash Standard
authentication method:  Rivest-Shamir-Adleman Signature
Diffie-Hellman group:   #1 (768 bit)
lifetime:               86400 seconds, no volume limit

Note

The terminology in the output of the CLI command is inconsistent. What we know to be policy sets the CLI is labeling policy suites. This is incorrect, but short of asking Cisco to reengineer the CLI, we can’t change it.

Assuming we have configured a similar policy set on Peer B, the peers have all the information they need to successfully negotiate an IKE Phase I SA.

Verifying and Troubleshooting the IPsec VPN Using the CLI

The commands in Table 7.6 can be used to verify and troubleshoot the IPsec VPN. We have already looked at the first two while configuring the site-to-site IPsec VPN during Step 2 and Step 5, respectively.

TABLE 7.6 IPsec VPN Troubleshooting Commands

The following sections look at the output of the commands in Table 7.6 not yet examined. Look at the output and verify that it matches the reference network diagram in Figure 7.8.

Verify the IPsec Transform Set(s)

This command verifies the configured IPsec transform sets. Recall that previously we created an IPsec transform set called CantHackMe with an AES 128-bit for the encryption algorithm and SHA for the HMAC:

CiscoISR-A#show crypto ipsec transform-set
Transform set CantHackMe: { esp-aes esp-sha-hmac  }
will negotiate = { Tunnel,  },

Verify/Display the Established IKE Phase II SAs (IPsec Tunnels)

The show crypto ipsec sa command is used to verify the operation of the IKE Phase II data tunnels. The following command output is from Peer A’s perspective. Among other things, it can verify the following:

    The inbound and outbound Security Parameter Indices (SPIs) in Peer A’s Security Association Database (SAD).

    The type of IKE Phase II SAs created (ESP, AH, or other).

Note

The following output was captured from a Cisco ISR that was behind a NAT router and connecting to a Cisco ASA 5505 security appliance with a public IP address and that was not behind a NAT router. The two VPN devices negotiated RFC-compliant NAT Traversal (NAT-T), which wraps IKE Phase II’s ESP inside a UDP port 4500 wrapper so that it will traverse what might be a Port Address Translation (PAT) router. This is because PAT cannot tolerate stateless, portless ESP without a bit of help! This will not be on the exam, but it helps explain some of the parameters you see in the output. For example, the inbound SA’s in use settings include this pearl:

in use settings ={Tunnel UDP-Encaps, }

This indicates that the peers have negotiated tunnel mode (versus transport mode) for IKE Phase II but inside a UDP wrapper.

Refer to the following command output. The shaded output indicates the following things that we can observe:

    The IKE Phase II SAs are formed between local peer, Peer A (192.168.99.218), and remote peer, Peer B (172.16.32.1).

    The transform set applied to both the outbound and inbound IKE Phase II IPsec VPN SAs is the contains esp-aes and esp-sha-hmac as the encryption algorithm and HMAC, respectively.

    The IKE Phase II SAs are being encrypted and decrypted using onboard hardware acceleration (Motorola processor on this Cisco 871 ISR).

    Both inbound and outbound IKE Phase II IPsec VPN SAs are active.

    All traffic between 192.168.0.0/24 and 10.0.20.0/24 is being protected in the VPN.

CiscoISR-A#show crypto ipsec sa

interface: FastEthernet4
    Crypto map tag: multipurpose, local addr 192.168.99.218

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.0.20.0/255.255.255.0/0/0)  
   current_peer 172.16.32.1 port 4500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
    #pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 13, #recv errors 0

     local crypto endpt.: 192.168.99.218, remote crypto endpt.:
172.16.32.1
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet4
     current outbound spi: 0xBB1E0DBD(3139308989)

     inbound esp sas:
      spi: 0x9D5D2EC7(2640129735)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 1, flow_id: Motorola SEC 1.0:1, crypto map: multipurpose
        sa timing: remaining key lifetime (k/sec): (3843604/27899)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xBB1E0DBD(3139308989)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2, flow_id: Motorola SEC 1.0:2, crypto map: multipurpose
        sa timing: remaining key lifetime (k/sec): (3843604/27896)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

Verify/Display Established IKE Phase I SAs (ISAKMP) Tunnels

Look at the output of the show crypto isakmpsa command. Note that the tunnel is in a state QM_IDLE indicating that quick mode (QM) completed successfully and is currently in an idle state.

CiscoISR-A#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
172.16.32.1  192.168.99.218  QM_IDLE           2005    0 ACTIVE

IPv6 Crypto ISAKMP SA

Verify/Display the Crypto ACL

ACL 102 defines the traffic that is supposed to be in the IPsec VPN. Note that there are 19 matches, indicating that traffic is flowing into the VPN subject to the policy defined in the ACL.

CiscoISR-A#show access-list 102
Extended IP access list 102
    10 permit ip 192.168.0.0 0.0.0.255 10.0.20.0 0.0.0.255 (19 matches)

Configuring a site-to-site VPN with the SDM should be fairly straightforward, now that we have examined the fundamentals of how IPsec VPNs work and grounded the theory by configuring a site-to-site IPsec VPN with the CLI.

When using the SDM to configure a site-to-site IPsec VPN, you can either manually configure the VPN or employ the Cisco SDM VPN Wizard. We will choose the wizard and see that the wizard will give us a choice of the following:

    Quick setup. Uses pre-built settings (useful for a brand-new VPN configuration with another Cisco IOS router that is being configured with the quick setup versus the step-by-step wizard).

    Step-by-step wizard. For more granular, detailed configuration control.

Let’s look at these two wizards, one at a time.

Site-to-Site VPN Wizard Using Quick Setup

To launch the Site-to-Site VPN Wizard and enter Quick Setup, complete the following steps:

1. Navigate to Configure->VPN in the SDM.

2. Select Site-to-Site VPN from the left navigation pane.

3. Make sure that the Create Site to Site VPN tab is selected in the main navigation window.

4. Check the Create a Site to Site VPN radio button, as indicated in Figure 7.9.

   FIGURE 7.9 Launching the Site-to-Site VPN Wizard.

   

5. Press the Launch the selected task button. The Site-to-Site VPN Wizard window appears.

6. Note the choices indicated in Figure 7.10. You can choose either Quick setup or Step by step wizard. Press the Quick setup radio button; then click Next. A window appears in which you can enter some basic information about the VPN. Note that it doesn’t ask you what encryption algorithms, hashes, or DH groups you want to use.

   FIGURE 7.10 Launching Quick Setup.

   

7. The VPN Connection Information window pops up, as indicated in Figure 7.11. Look at this window while referring to the reference network diagram in Figure 7.8. We know exactly what to fill in. From top to bottom:

   VPN Connection Information:

    Select the interface for this VPN connection: FastEthernet4.

    Select the type of peer(s) used for this VPN connection: Peer with static IP address.

    Enter the IP address of the remote peer: 172.16.32.1.

Authentication:

    Pre-Shared Keys or Digital Certificates radio button: Press the Pre-shared keys radio button. Fill in the pre-shared key in the pre-shared key and Re-enter key fields.

Traffic to Encrypt:

    Source: Choose Vlan1 as the source interface in the drop-down list. This is the interface that the net A’ to net B’ traffic will arrive on.

    Destination: Enter 10.0.20.0 in the IP Address field and 255.255.255.0 in the Subnet Mask field. (Alternatively, you can put the number of bits (24) in the “or” field.)

FIGURE 7.11 Quick Setup dialog of the SDM Site-to-Site VPN Wizard.

8.    Click Finish. The Summary of the Configuration window appears. It will look something like Figure 7.12.

FIGURE 7.12 Summary of the Configuration window in the SDM Site-to-Site VPN Wizard.

If you don’t like the IKE policies and IPsec transform sets that are created for you, then Quick Setup is not a good choice. Chances are good that 3DES for a cipher for both Phase I and Phase II will not match the organization’s comprehensive network security policy. Here are the parameters selected by the SDM when using Quick Setup:

IKE Policy Set (HAGLE):

IPsecTransform Set:

9.    If you like what you see, click on Finish to deliver the commands to the router. You might have noticed the Test VPN connectivity after configuring check box. We examine this feature when we (next) configure the VPN with the SDM Site-to-Site VPN Wizard, but choosing step-by-step this time.

The five tasks of the wizard using Step-by-Step setup are as follows:

Task 1: Define Connection Settings:

    Outside interface

    Peer address

    Authentication credentials

Task 2: Define IKE Proposals:

    Priority

    Encryption algorithm

    HMAC

    Mode of operation (AM, MM)

Task 3: Define IPsec Transform Sets:

    Encryption algorithm

    HMAC

    Mode of operation (tunnel, transport)

    Compression

Task 4: Define Traffic to Protect (Crypto ACL):

    Single source and destination subnets

or

    Create ACL (can use existing if already created)

Task 5: Review and Complete the Configuration

To begin the step-by-step setup of the Cisco SDM Site-to-Site VPN Wizard:

1. Navigate to Configure->VPN and select Site-to-Site VPN in the list box on the left side.

2. Ensure the Create Site to Site VPN tab is selected and push the Create a Site to Site VPN radio button.

3. Click the Launch the selected task button. The Site-to-Site VPN Wizard window appears, as indicated in Figure 7.13.

   FIGURE 7.13 Step-by-Step VPN Wizard: Define connection settings.

   

4. Push the Step by step wizard radio button and click the Next button. A window appears, prompting you to define the connection settings.

Follow these steps to define basic connection settings:

The next step is to define the IKE proposals to be used. You can use either the built-in, default proposal or create your own. Follow these steps to define the IKE proposal:

1. The list of IKE proposals will have at least the SDM default (look under the Type column). Click Add and the Add IKE Policy window appears.

2. Fill in the information for the IKE proposal using the HAGLE values that you have already determined. In this example, we are creating an IKE proposal with these parameters:

    Priority: 99

    Authentication: PRE_SHARE

    Encryption: AES_128

    D-H Group: group5

    Hash: SHA_1

    Lifetime: 24:00:00 (HH:MM:SS)

3.    Click OK when finished. The IKE proposal appears highlighted in the list of IKE proposals. Leave it selected and click Next. A window appears, as indicated in Figure 7.15, prompting you to define an IPsec transform set for the site-to-site VPN.

FIGURE 7.15 Step-by-Step VPN Wizard: Define IPsec transform sets.

Follow these steps to review and complete the configuration:

FIGURE 7.19 Step-by-Step VPN Wizard: VPN troubleshooting traffic generation.

If the VPN fails and you have generated traffic to bring up the VPN as a troubleshooting step (see the previous note), then the VPN should come up as indicated in Figure 7.20.

FIGURE 7.20 Step-by-Step VPN Wizard: VPN troubleshooting tunnel status up.

For more advanced troubleshooting, Cisco recommends using the CLI commands covered in the section, “Table 7.6.