S2S IPSEC VPN

Contents
◦ Introduction
◦ Feature overview
◦ Configuration
◦ Demo
◦ Verification and troubleshooting
◦ Additional info
Introduction
◦ Encapsulating a packet for secure transportation on the network can be done using either GRE or IPsec
protocols.
◦ A GRE tunnel is used when packets need to be sent from one network to another over the Internet or an
insecure network. With GRE, a virtual tunnel is created between the two endpoints (Cisco routers) and
packets are sent through the GRE tunnel. It is important to note that packets travelling inside a GRE
tunnel are not encrypted as GRE does not encrypt the tunnel but encapsulates it with a GRE header. If
data protection is required, IPSec must be configured to provide data confidentiality – this is when a
GRE tunnel is transformed into a secure VPN GRE tunnel.
◦ Site-to-Site IPSec VPN Tunnels are used to allow the secure transmission of data, voice and video
between two sites (e.g offices or branches). The VPN tunnel is created over the Internet public network
and encrypted using a number of advanced encryption algorithms to provide confidentiality of the data
transmitted between the two sites.
◦ Use GRE where IP tunneling without privacy is required -- it's simpler and thus faster. But, use IPsec
ESP where IP tunneling and data privacy are required -- it provides security features that are not even
attempted by GRE.
Basic Site-to-Site IPsec VPNs
Peer Authentication

ISAKMP SA Cisco ASDM

Pre-Shared Pre-Shared
Inside Host Key Key

Cisco Cisco
ASA ASA

IPsec SA
IPsec SA
Transmission
Protection for Site-to-Site Traffic
◦ Site-to-Site IPSec VPN Tunnels are used to allow the secure transmission of data, voice and video
between two sites (e.g offices or branches). The VPN tunnel is created over the Internet public
network and encrypted using a number of advanced encryption algorithms to provide confidentiality
of the data transmitted between the two sites.
◦ ISAKMP (Internet Security Association and Key Management Protocol) and IPSec are essential to
building and encrypting the VPN tunnel. ISAKMP, also called IKE (Internet Key Exchange), is the
negotiation protocol that allows two hosts to agree on how to build an IPsec security association.
ISAKMP negotiation consists of two phases: Phase 1 and Phase 2.  
◦ Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates
the tunnel that protects data where IPSec comes into play to encrypt the data using encryption
algorithms and provides authentication, encryption and anti-replay services.
Prerequisites
◦ 1. configure Ip address on both inside and outside of both the devices
◦ 2. configure routing protocol and have connectivity established between the outsides of both the devices
◦ Configure non overlaping ip addresses on the insides of the device
Deployment Tasks
◦ To help make this an easy-to-follow exercise, we have split it into three steps that are required to get the
Site-to-Site IPSec VPN Tunnel to work.

◦ Configure basic peer authentication.(IKE PHASE 1)

◦ Configure transmission protection.(IPSEC- IKE PHASE 2, ACL, Crypto map)
◦ Verify communication over encrypted tunnel.
Phase 1
◦ The basic purpose of IKE phase 1 is to authenticate the IPSec peers and to set up a secure channel
between the peers to enable IKE exchanges. IKE phase 1 performs the following functions:
◦ Authenticates and protects the identities of the IPSec peers
◦ Negotiates a matching IKE SA policy between peers to protect the IKE exchange
◦ Performs an authenticated Diffie-Hellman exchange with the end result of having matching shared secret
keys
◦ Sets up a secure tunnel to negotiate IKE phase 2 parameters
◦ There are 2 versions of IKE in phase 1 – IKEv1 and IKEv2
Difference between IKEv1 and IKEv2
IKEv1 IKEv2
Exchange modes:  Only one exchange procedure is defined. 
Main mode Exchange modes were obsoleted.
Aggressive mode

Exchanged messages to establish VPN.  Only 4 messages.

Main mode: 9 messages
Aggressive mode: 6 messages

Authentication methods ( 4 methods ):  Only 2 methods: 

Pre-Shared Key (PSK) Pre-Shared Key (PSK)
Digital Signature (RSA-Sig) Digital Signature (RSA-Sig)
Public Key Encryption
Revised Mode of Public key Encryption
IKEv1 IKEv2
Both peers must use the same authentication Each peer can use a different authentication method
method. (Asymmetrical authentication). 
(e.g. Initiator: PSK and Responder: RSA-Sig) 

Traffic selector:  Multiple combinations of a source IP range, a

Only a combination of a source IP range, a destination IP range, a source port range and a
destination IP range, a source port and a destination destination port range are allowed per Child SA. Of
port is allowed per IPsec SA. course, IPv4 and IPv6 addresses can be configured
Exact agreement of the traffic selector between for the same Child SA.
peers is required. Narrowing traffic selectors between peers is
allowed.

Lifetime for SAs:  NOT negotiated. Each peer can delete SAs anytime
  Agreement between peers is required. by exchanging DELETE payloads. 
IKEv1
◦ There are basically 2 modes in this version
◦ Main mode (default mode) :- it has three two-way exchanges between the initiator and the receiver
◦ First exchange: The algorithms and hashes used to secure the IKE communications are agreed upon in matching IKE SAs in
each peer.
◦ Second exchange: Uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret
keys and to pass nonces—random numbers sent to the other party and then signed and returned to prove their identity.
◦ Third exchange: Verifies the other side's identity. The identity value is the IPSec peer's IP address in encrypted form. The main
outcome of main mode is matching IKE SAs between peers to provide a protected pipe for subsequent protected ISAKMP
exchanges between the IKE peers. The IKE SA specifies values for the IKE exchange: the authentication method used, the
encryption and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA in seconds or kilobytes, and the
shared secret key values for the encryption algorithms. The IKE SA in each peer is bi-directional.
IKEv1 Phase 1 Main Mode
Initiator Responder

Active Proposals: Proposal A B C Active Proposals:

Proposal A Proposal B
Proposal B Accept B Proposal C
Proposal C

gXi mod p

DH Exchange, Nonces
Session Key Session Key
gXr mod p

Peer Authentication
PSK PSK

ISAKMP SA
IKEv1
◦ The 2nd mode is the aggressive mode
◦ In this mode, fewer exchanges are made, and with fewer packets. On the first exchange, almost
everything is squeezed into the proposed IKE SA values: the Diffie-Hellman public key; a nonce that the
other party signs; and an identity packet, which can be used to verify identity via a third party. The
receiver sends everything back that is needed to complete the exchange. The only thing left is for the
initiator to confirm the exchange.
◦ The weakness of using the aggressive mode is that both sides have exchanged information before there's
a secure channel. Therefore, it's possible to "sniff" the wire and discover who formed the new SA.
However, it is faster than main mode.
IKEv1 Phase 1 Aggressive Mode
Initiator Responder

Active Proposals: Proposal A B C + gXi mod p Active Proposals:

Proposal A Proposal B
Proposal B DH Exchange, Nonces Accept B Proposal C
Proposal C Session Key
gXr mod p +
Session Key HASH_R HASH_R

ACK of HASH_R

ISAKMP SA
IKEv2
◦ Compared with IKEv1, IKEv2 simplifies the SA negotiation process. IKEv2 uses two exchanges (a total
of 4 messages) to create an IKE SA and a pair of IPSec SAs. To create multiple pairs of IPSec SAs, only
one additional exchange is needed for each additional pair of SAs.
Different authentication methods
◦ IKEv2 supports EAP authentication.
◦ IKEv2 can use an AAA server to remotely authenticate mobile and PC users and assign private addresses
to these users. IKEv1 does not provide this function and must use L2TP to assign private addresses.
◦ Different supports for IKE SA integrity algorithms
◦ IKE SA integrity algorithms are supported only in IKEv2.Different implementations of DPD packet
retransmission
IKEv2- Parent SA’s
Initiator Responder
Request
Response

IKE_SA_INIT (2 messages)
Negotiates IKE SA Security Parameters
Exchanges DH Keys and Nonces
Not Crypto Protected
Optional - Cookie challenge allows responder to challenge the initiator if it is flooded
with SA initiation packets to mitigate a potential DOS attack.
Upon receipt of an IKE_SA_init, the responder can either proceed with setting up the SA or
can tell the initiator to send another IKE_SA_init, this time providing a supplied cookie.

IKE_AUTH (2 messages)
Mutual Authentications
Establishes the IKEv2 parent SA, and the first (child) IPsec SA is created.
Crypto Protected

PARENT SA
Configuration tasks
◦ Enabling IKEv1,IKEv2 or both in the group policy
◦ Configure authentication in tunnel groups
◦ Configure IKEv1/IKEv2 policy
◦ Enabling IKEv1,IKEv2 or both on the interface
1. Configure group policy

2. Configure tunnel group

IF you do not mention the group name or the tunnel group name, the default group policy and tunnel group is chosen.
3. configure IKE policy
IKev1 Policy IKEv2 Policy

4. Enable IKE on the interface

Note: the mode for ikev1 can be configured as follows:

Phase 2 - IPSEC
◦ The purpose of IKE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel. IKE phase 2 performs
the following functions:
◦ Negotiates IPSec SA parameters protected by an existing IKE SA
◦ Establishes IPSec security associations
◦ Periodically renegotiates IPSec SAs to ensure security
◦ Optionally performs an additional Diffie-Hellman exchange
◦ IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure
tunnel in phase 1. It negotiates a shared IPSec policy, derives shared secret keying material used for the
IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces that provide replay
protection. The nonces are used to generate new shared secret key material and prevent replay attacks
from generating bogus SAs.
◦ Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires. Base quick
mode is used to refresh the keying material used to create the shared secret key based on the keying
material derived from the Diffie-Hellman exchange in phase 1.
◦ Perfect Forward Secrecy
◦ If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman exchange is
performed with each quick mode, providing keying material that has greater entropy (key material life)
and thereby greater resistance to cryptographic attacks. Each Diffie-Hellman exchange requires large
exponentiations, thereby increasing CPU use and exacting a performance cost.
IKEv1 Phase 2 Quick Mode
Initiator Responder

Proposal A Proposal A B C Proposal B

Proposal B Proposal C
Proposal C Accept B

(Proposal = transform set, traffic to be protected, parameters like tunnel mode, and PFS)

IPsec SA

IPsec SA
IKEv2 Child SAs
Initiator Responder
Request
Response

CREATE_CHILD_SA (2 messages)
optional - Create additional child SAs under the protection of the existing IKEv2 parent SA
used to rekey an existing IKEv2 parent SA or IPsec (child) SA
Crypto Protected

INFORMATIONAL
Status and Control Messages/SA Housekeeping Functions
At various points during an IKE-SA, peers may want to convey control messages
to each other regarding errors or notifications of certain events.
Crypto Protected

CHILD SA
Configuration Tasks
◦ 1. Define the interesting traffic
◦ 2. create the Ipsec proposal
◦ 3. Create the crypto map
◦ 4. Enable the crypto map on the interface
1. Defining the interesting traffic
Interesting traffic is the traffic you need to encrypt and send through the tunnel. We can configure it using an
extended Acl by defining the source and destination Ip address and whether to permit it or deny it.

NOTE: the access list should be a mirror image of the above config on the other end
2. Create the Ipsec proposal
Ikev1 and Ikev2 are configured different in this stage. Ikev1 uses transform set while the ikev2 uses ipsec-proposal

IKEv1 IKEv2
3. Create crypto map
There are 2 types of crypto map which we can create.
◦ Static crypto map - identifies peer and traffic to be encrypted explicitly. Typically used to accommodate a few
tunnels with different profiles and characteristics (different partners, sites, location)

◦ Dynamic crypto map - is one of the ways to accomodate peers sharing same characteristics (for example multiple
branches offices sharing same configuration) or peers having dynamic IP addressing (DHCP, etc.)
After configuring the dynamic crypto map we need to add the dynamic crypto map to the static crypto
map.

4. Enable the crypto map on the interface

Verification
There are some basic show commands you can use to check if the tunnel is established and the traffic are the following:
show vpn-session, show vpn-session detail l2l,
show crypto ikev2 sa , show crypto ikev2 sa detail , show crypto ikev2 stats
show crypto ikev1 sa , show crypto ikev1 sa detail , show crypto ikev1 stats
show crypto ipsec sa, show crypto ipsec sa detail, show crypto ipsec stats
show crypto protocol statistics ikev2, show crypto protocol statistics ikev1, show crypto protocol statistics ipsec

There are some other system resource show commands that can be uses as we well.
show cpu, show cpu detail
show memory, show memory detail
show blocks
show process cpu-hog
Debugging
◦ Important basic debugging commands are :
Debug crypto ikev2 plat <1-255>
Debug crypto ikev2 pro <1-255>
Debug crypto ipsec <1-255>
Debug crypto ikev1 <1-255>
Debug crypto ike-common <1-255>

◦ Advanced debugging commands are :

debug menu ikev2 2 0, debug menu ikev2 2 1, debug menu ikev2 2 3, debug menu ikev2 2 4
debug menu ikev2 8 0, debug menu ikev2 8 1
debug menu ikev2 9 0, debug menu ikev2 9 1
debug menu ikev2 11 0, debug menu ikev2 11 1
debug menu ikev2 13 0, debug menu ikev2 13 1
debug menu ikev2 103 0, debug menu ikev2 103 1, debug menu ikev2 103 2
 Triggers
◦ The following are the triggers you can issue based on the mode/topo of the setup
◦ Failover active, no failover active, failover active group 1/ 2
◦ Reload , reload standby, reload slave
◦ Shut interface
◦ clear crypto ikev1/ 2 sa , clear crypto ipsec sa
◦ Vpn-sessiondb logoff all
◦ Cluster master, no cluster master
◦ Tunnel rekey