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.
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:
access-list 101 permit ahp host 172.16.32.1 host 206.248.168.15 access-list 101 permit esp host 172.16.32.1 host 206.248.168.15 access-list 101 permit udp host 172.16.32.1 host 206.248.168.15 eq isakmp CiscoISR-A#show access-list 101 Extended IP access list 101 10 permit ahp host 172.16.32.1 host 206.248.168.15 20 permit esp host 172.16.32.1 host 206.248.168.15 30 permit udp host 172.16.32.1 host 206.248.168.15 eq isakmp 40 permit tcp any any eq 22 50 permit tcp any any eq www 60 permit tcp any any eq 443 CiscoISR#
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.
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
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
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:
CiscoISR-A(config)#crypto ipsec transform-set CantHackMe ? ah-md5-hmac AH-HMAC-MD5 transform ah-sha-hmac AH-HMAC-SHA transform comp-lzs IP Compression using the LZS compression algorithm esp-3des ESP transform using 3DES(EDE) cipher (168 bits) esp-aes ESP transform using AES cipher esp-des ESP transform using DES cipher (56 bits) esp-md5-hmac ESP transform using HMAC-MD5 auth esp-null ESP transform w/o cipher esp-seal ESP transform using SEAL cipher (160 bits) esp-sha-hmac ESP transform using HMAC-SHA auth CiscoISR-A(config)#crypto ipsec transform-set CantHackMe esp-sha-hmac esp-aes 128
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 192.168.0.0 0.0.0.255 10.0.40.0 0.0.0.255
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.
CiscoISR-A(config-crypto-map)#
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:
CiscoISR-A(config-crypto-map)#set peer 172.16.32.1 CiscoISR-A(config-crypto-map)#set transform-set CantHackMe CiscoISR-A(config-crypto-map)#match address 102 CiscoISR-A(config-crypto-map)#set security-association lifetime seconds 86400 CiscoISR-A(config-crypto-map)#set security-association lifetime kilobyte 4000000 CiscoISR-A(config-crypto-map)#set pfs group2 At this point, we have created the crypto map, but we must also apply it to a router interface—FastEthernet 4, in this example. Use the crypto map interface configuration mode command to do this: CiscoISR-A(config)#interface fa4 CiscoISR-A(config-if)#crypto map multipurpose You can verify the completeness of the crypto map and that it has been applied to the correct interface with the show crypto map CLI command: CiscoISR-A#show crypto map Crypto Map “multipurpose” 999 ipsec-isakmp Peer = 172.16.32.1 Extended IP access list 102 access-list 102 permit ip 192.168.0.0 0.0.0.255 10.0.40.0 0.0.0.255 Current peer: 172.16.32.1 Security association lifetime: 4000000 kilobytes/86400 seconds PFS (Y/N): Y DH group: group2 Transform sets={ CantHackMe, } Interfaces using crypto map multipurpose: FastEthernet4
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
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).
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 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) 172.16.32.1 192.168.99.218 QM_IDLE 2005 0 ACTIVE IPv6 Crypto ISAKMP SA