Site to Site VPN Tunnel on Cisco Router | GNS3

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


The basic steps to follow when configuring Cisco IOS CLI-based site-to-site IPsec VPNs are as


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.



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 host

access-list 101 permit esp host host

access-list 101 permit udp host host eq isakmp

access-list 101 permit udp host host 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

Branch(config)# crypto isakmp key VPNpass address

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


Configuring ACLs

HQ(config)# access-list 120 permit ip

Branch(config)# access-list 120 permit ip



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

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


Download GNS3 File – Ready to Use

Leave a Reply

Your email address will not be published. Required fields are marked *