Implementing IPsec on a Site-to-Site VPN Using the CLI

Implementing IPsec on a Site-to-Site VPN Using the CLI

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).

The missing step is Step 6: Test! That small fact aside, memorize the five steps for the exam.

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.

Conceptualizing a Site-to-Site IPsec VPNFIG7.8

Step 1: Ensure That Existing ACLs Are Compatible with the IPsec VPN

Use the commands that you learned in Chapter 5 to ensure that ISAKMP, ESP, or AH traffic will not be blocked by an existing interface ACL.

ISAKMP is the Internet Security Association Key Management Protocol and uses UDP for transport. It uses both source and destination UDP port 500. IKE
messages use ISAKMP for transport. The Cisco IOS software denotes ISAKMP with keyword isakmp.

ESP is defined as IP protocol number 50. The Cisco IOS software denotes ESP with the keyword esp.

AH is defined as IP protocol number 51. The Cisco IOS software denotes ESP with the keyword ahp.

Assuming that you have an ACL 101 applied on interface FastEthernet4 on Peer A, you would need to add these lines to it in the correct place:

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:

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.

Conceptualizing a Site-to-Site IPsec VPNtb7.5

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 Alternatively, if you know the fully-qualified domain name (FQDN) of Peer B, you could type:

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.

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.

Step 3: Configure IPsec Transform Set(s)

Now we configure the transform sets that will be used to protect (transform) the data in the IKE Phase II SA. Recall that transform sets are made up of an encryption algorithm and an HMAC. We create a transform set, giving it a casesensitive name in this step. We will apply it to the policy defining the Phase II SA to Peer B in Step 5. Here are two things to remember about transform sets:

  • A transform set is a combination of IPsec transforms that enact a security policy (transformation) for traffic.
  • A transform set can have one AH transform and up to two ESP transforms Use the crypto ipsec transform-set CLI command to create the transform:
Recall that transforms are negotiated during QM in IKE Phase I.

Step 4: Create Crypto ACL Defining Traffic in the IPsec VPN

Create an ACL that will define the traffic that will be transmitted inside the IPsec VPN. Of course, the ACL doesn’t do anything by itself. It will be applied to the configuration in Step 5. From Peer A’s perspective, this is any packet from the A’ network to the B’ network:

  • Permit = Encrypt.
  • Deny = Do not encrypt.
    access-list 102 permit ip
Watch those wildcard masks in the ACL. Remember that a 0 is a match bit and a 1 is an ignore bit.

Try to be as specific as possible with the crypto ACL. In our example, all IP traffic will be sent to Peer B if it is source address for the A’ network and destination address for the B’ network. If you only want VoIP traffic, for instance, to

travel between the sites, say it in the ACL. Any packets that don’t match a permit statement in the ACL will be sent out of the router in cleartext. Ensure that the crypto ACL on the other peer is symmetric with this one. Peer A’s ACL says that all IP traffic from A’ to B’ shall be in the VPN; thus, Peer B’s ACL must say the symmetric opposite. If this is not the case, VPN tunnel establishment will fail during quick mode, as this is where the policies as to what traffic is to be in the VPN are negotiated.

Step 5: Create and Apply the Crypto Map (IPsec Tunnel Interface)

Conceptually, the crypto map is a virtual IPsec tunnel interface. The crypto ACL that was created in Step 4 defines the traffic that will flow into this interface toward Peer B. Here are all the elements that go into a crypto map:

  • Crypto ACL to be used
  • Address or hostname of remote VPN peer(s)
  • Transform set
  • Key management method (remember, this is optional in IKE Phase II)
  • SA lifetime

Heads up! There can be only one crypto map on a router interface. This one crypto map must support as many VPN peers, both remote-access and site-tosite as you may have to that interface. Priority numbers (just like with IKE Phase I policy sets) will group the elements together and dictate their relative priority.
The lower the number, the higher the priority. Use the crypto map global configuration command to create and modify the crypto map. First, you must create the crypto map. In the following example, a crypto map called “multipurpose” is created and sequence number 999 is attached to it. Note the output from the following command, indicating that the crypto map is disabled until a peer and ACL are assigned to it: CiscoISR-A(config)#crypto map multipurpose 999 ipsec-isakmp % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured.

Let’s add some parameters to sequence 999. Certainly we will want to add the transform set that we created in Step 3 and the crypto ACL that we created in

Step 4. We will also want to identify the IP address or hostname of Peer B. We’ll look at an example, and then talk about some of the other parameters we can add:

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

Conceptualizing a Site-to-Site IPsec VPNtb7.6

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:

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).
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 (, and remote peer, Peer B (
  • 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 and is being protected in the VPN.

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.

About the author


Leave a Comment