Site-to-Site VPN
CCNA Security 210-260 IINS Exam
IPsec Negotiation
IPsec VPN negotiation can be broken down into five steps, as shown in Figure 19-1, including
Phase 1 and Phase 2 of Internet Key Exchange (IKE):
Step 1. An ISAKMP tunnel is initiated when Host A sends “interesting” traffic to Host B.
Traffic is considered interesting when it travels between the peers and meets the criteria
that is defined in the crypto access control list (ACL).
Step 2. IKE Phase 1 begins. The peers negotiate the ISAKMP SA policy. When the peers agree
on the policy and are authenticated, a secure tunnel is created.
Step 3. IKE Phase 2 begins. The IPsec peers use the authenticated secure tunnel to negotiate
the IPsec SA policy. The negotiation of the shared policy determines how the IPsec
tunnel is established.
Step 4. The IPsec tunnel is created and data is transferred between the IPsec peers based on the
IPsec SAs.
Step 5. The IPsec tunnel terminates when the IPsec SAs are deleted or when their lifetime
expires.
The basic steps to follow when configuring Cisco IOS CLI-based site-to-site IPsec VPNs are as
follows:
Step 1. Ensure that all ACLs in the IPsec VPN network path are compatible with IPsec.
Step 2. Configure an ISAKMP policy to determine the ISAKMP parameters that will be used
to establish the IKE Phase 1 tunnel.
Step 3. Define the IPsec transform set. The definition of the transform set defines the parameters
that the IPsec tunnel uses and can include the encryption and integrity algorithms.
Step 4. Create a crypto ACL. The crypto ACL defines which traffic should be sent through the
IPsec tunnel and be protected by the IPsec process.
Step 5. Create and apply a crypto map. The crypto map groups the previously configured
parameters together and defines the IPsec peer devices. The crypto map is applied to
the outgoing interface of the VPN device.
Configuration
There are five major steps to follow when configuring a Cisco IOS CLI-based site-to-site
IPsec VPN.
Step 1: ACL Compatibility
The first step in configuring Cisco IOS ISAKMP is to ensure that existing ACLs on perimeter
routers, firewalls, or other devices do not block IPsec traffic. Example 19-1 shows the commands
that would be added to the inbound ACL on router HQ Gi0/3. These lines would permit protocol
50 (ESP), protocol 51 (AH), and UDP port 500 (ISAKMP) traffic. They also would permit UDP
port 4500 (non500-isakmp). This is used by NAT-T, which is a commonly implemented extension
to IKE and has been incorporated into IKEv2. NAT-T facilitates VPN through intermediate
devices that perform Port Address Translation (PAT).
Site-to-Site IPsec VPN ACL
access-list 101 permit ahp host 209.165.200.2 host 209.165.200.1
access-list 101 permit esp host 209.165.200.2 host 209.165.200.1
access-list 101 permit udp host 209.165.200.2 host 209.165.200.1 eq isakmp
access-list 101 permit udp host 209.165.200.2 host 209.165.200.1 eq non500-isakmp
Step 2: IKE Phase 1—ISAKMP Policy
The second major step in configuring Cisco IOS ISAKMP support is to define a suite of ISAKMP
policies. The goal of defining a suite of policies is to define the IKE Phase 1 characteristics.
To configure a new ISAKMP policy, use the crypto isakmp policy command. The only argument
for the command is to set a priority for the policy (from 1 to 10000). Peers will attempt to
negotiate using the policy with the lowest number (highest priority). Peers do not require matching
priority numbers.
For our scenario, let’s use some of the stronger options in configuring our ISAKMP policy.
Both routers would be configured identically at this point. ISAKMP peers
negotiate the acceptable ISAKMP policies before they agree upon the SA to use for IPsec. When
the ISAKMP negotiation begins in IKE Phase 1 main mode, ISAKMP looks for an ISAKMP policy
that is the same on both peers.
Configuring ISAKMP Policy
HQ(config)# crypto isakmp policy 10
HQ(config–isakmp)# authentication pre-share
HQ(config–isakmp)# encryption aes 256
HQ(config–isakmp)# group 15
HQ(config–isakmp)# hash sha256
HQ(config–isakmp)# lifetime 3600
At this point a pre-shared key (PSK) also needs to be configured, which will allow the VPN peers
to authenticate each other. To configure this, use the crypto isakmp key command in global
configuration mode. You must configure this key whenever you specify authentication preshare
in an ISAKMP policy.
Configuring PSK
HQ(config)# crypto isakmp key VPNpass address 209.165.200.2
Branch(config)# crypto isakmp key VPNpass address 209.165.200.1
Step 3: IKE Phase 2—IPsec Transform Set
The next step is to configure the set of encryption and hashing algorithms that will be used
to transform the data sent through the IPsec tunnel. This is called the transform set. During
IKE Phase 2 negotiations, the peers agree on the IPsec transform set to be used for protecting
interesting traffic.
Transform sets combine these IPsec factors:
■ A mechanism for payload authentication: AH HMAC or ESP HMAC transform
■ A mechanism for payload encryption: ESP encryption transform
■ IPsec mode (transport versus tunnel)
Define a transform set with the crypto ipsec transform-set global configuration command.
The encryption and hashing algorithm that will be transforming the data
can then be configured in either order.
Configuring Transform Sets
HQ(config)# crypto ipsec transform-set HQBRANCH esp-aes esp-sha256-hmac
Branch(config)# crypto ipsec transform-set HQBRANCH esp-aes esp-sha256-hmac
We are configuring the same transform set on both VPN peers to ensure successful negotiation of
IKE Phase 2.
Step 4: Crypto ACLs
To trigger IKE Phase 1, interesting traffic must be detected. In our case, interesting traffic will be
defined as any IPv4 communication between the HQ LAN and the Branch LAN.
Interesting traffic is defined by crypto ACLs in site-to-site IPsec VPN configurations. Crypto ACLs
perform two functions:
■ Outbound: For outbound traffic, the ACL defines the flows that IPsec should protect.
■ Inbound: The same ACL is processed for inbound traffic. The ACL defines traffic that should
have been protected with IPsec by the peer. Packets are discarded if they match but arrive
unprotected.
Configuring ACLs
HQ(config)# access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
Branch(config)# access-list 120 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
Step 5: IPsec Crypto Map
IPsec policies are defined in crypto maps. Each crypto map must define the following criteria:
■ The crypto ACL, which specifies which traffic should be protected by IPsec
■ The transform set, which specifies the IPsec protocols and cipher policies that are used to
protect the traffic
■ The IPsec peer, which specifies where the IPsec-protected traffic is sent
■ Optionally specify a lifetime for the IPsec security association
Configuring Crypto Map
HQ(config)# crypto map HQMAP 10 ipsec-isakmp
HQ(config-crypto-map)# match address 120
HQ(config-crypto-map)# set peer 209.165.200.2
HQ(config-crypto-map)# set transform-set HQBRANCH
HQ(config-crypto-map)# set security-association lifetime seconds 3600
HQ(config-crypto-map)# exit
HQ(config)# interface Gi1/3
HQ(config-if)# crypto map HQMAP
Verification (Important)
Show crypto isakmp policy
Show crypto ipsec transform-set
Show crypto map
Show crypto ipsec sa
debug crypto isakmp
debug crypto ipsec
