Showing results for 
Search instead for 
Did you mean: 
Marcin Latosiewicz
Cisco Employee
Cisco Employee


This document will outline basic negotiation and configuration for crypto-map-based IPsec VPN configuration.


This document is intended as an introduction to certain aspects of IKE and IPsec, it WILL contain certain simplifications and colloquialisms.


What is IPsec

IPsec is a standard based security architecture for IP hence IP-sec.

IKE (Internet Key Exchange) is one of the ways to negotiate IPsec Security Associations (SAs), in particular case ISAKMP (implementation of IKE) is what Cisco uses.

Currently two versions of IKE exist:

  1. IKE version 1 (IKEv1) - the more common and older, widely deployed. This is what typically is used to around the world when IPsec is implemented.
  2. IKE version 2 (IKEv2) - as the name suggests it a newer, more robust protocol. It's less widely deployed, however offers more and is quickly gaining traction.


This document focuses mostly on IKEv1 and crypto map configuration, however most aspects are true for other types of frameworks.


IKE negotiation at a glance


To establish IKE Security Association (IKE SA or Phase 1) in a secure way peers will need to exchange certain information, those include:

  • How to protect negotiation - hashing algorithm to use, encryption algorithm to use, Diffie-Hellman group (key length), desired IKE SA lifetime.
  • Diffie-Hellman exchange will need to be performed - establish a shared secret over insecure medium.
  • Authentication - Peers exchange identities and authentication material (pre shared key or certificates, in a typical environment).


It is important to note that pre shared key is not actually exchanged, it is intended factored into the key protecting identity. Thus if the peer doesn't have the correct pre-shared key it will not be able to authenticate and finish phase 1 negotiation.


IKE SA can be established via aggressive mode or main mode negotiation, this document covers Main Mode exchange which is the one typically deployed.

Aggressive mode is the less secure of modes and is typically used in EZVPN with pre-shared key, where additional layer of security is provided by performing user authentication.


Once IKE SA is established, the peers are ready to establish information about what traffic to protect and how to protect it. This will form an IPsec Security Association (SA) or phase 2, in an exchange called Quick Mode.


Once quick mode is performed and IPsec SA exists and traffic is able to flow in a secured way.


A visual aide to remember this by:

Screen Shot 2013-11-12 at 10.52.38 AM.png


At this stage it is important to remember, during normal operation, one IKE SA exists between peers.

During rekey or re-negotiation multiple IKE SA can exist.

However between two peers multiple IPsec SAs can exist.

This concept is visualized here.

Screen Shot 2013-11-12 at 10.55.28 AM.png


As the above diagram shows there are two IPsec SAs, identified by Security Parameter Index (SPI), present on a device for each direction, one for inbound traffic one for outbound traffic.

It is also crucial to remember that inbound IPsec SA on left hand side device, if the outbound IPsec SA on right hand side device, and vice versa.


At this stage it is also worth to mention that "local" and "remote" networks are reversed on each end. This concept will come up again when performing configuration of "interesting traffic" later on.


Tunnel mode and transport mode.

When IPsec protects traffic, it has a couple of services and modes to choose from.

  • Authentication Service - protect and verify integrity of data - make sure data is not changed during transport. Using AH (Authentication Header) and IP protocol 51.
  • Encryption Services - data encryption - make sure nobody can eavesdrop on the data in transport. Using ESP (Encapsulating Security Payload) and IP protocol of 50.


Second service is much more widely deployed.

While it is possible to mix the two services, it is an very rare scenario, with limitated-or-no support on certain platforms.


More is another concept which come up quite often with IPsec. Two modes exist:

  • Transport mode - preserving original IP header. Typically used in combination with GRE or other encapsulating protocols.
  • Tunnel mode - encapsulating entire IP datagram within a new header, essentially tunneling the packet.


A mode which is the most common for most crypto map deployments is Encryption Services and  tunnel mode. However let's have a look at an overview how each of those will work.


First let's have a look at AH and ESP and how they tread original IP datagram, in this case some TCP data will be sent over.

Screen Shot 2013-11-12 at 11.52.30 AM.png


And now about how those IP protocols fit in the two modes.

Screen Shot 2013-11-12 at 11.52.17 AM.png


As pointed out the last mode is what is typically used with crypto map based IPsec VPNs.

In this mode, RFC1918 addresses (or in fact any other IP address) can be sent over the Internet encapsulated in new IP header which will use addresses routable on the Internet.



Now that basic theoretical concepts are introduced, this document will show how to map those into the actual crypto map based configuration.



  • IKE negotiation protection:

crypto isakmp policy 10

encr aes 256

authentication pre-share

group 2

lifetime 28800

ISAKMP policy defines, what will be the means to authenticate, and how to protect negotiation , as well as how long and IKE SA will be alive before re-negotiation (by default it's one day).

Those parametrs need to agree on both ends of the tunnel.


  • IKE authentication

In previous section the means to authenticate was specified, here the configuration creates notion of the actual pre-shared key to be used to authenticate the peer. In this case it has value of "test".


crypto keyring MY_KEYRING

  local-address Loopback2

  pre-shared-key address key test

  • ISAKMP profile

This profile binds together features used by IKE and IPSec, it will be later on referenced in IPsec section, in crypto map configuration.

crypto isakmp profile MY_PROFILE

   [vrf MY_IVRF]

   keyring MY_KEYRING

   match identity address

   self-identity address

   local-address Loopback2

In this case the profile sprecifies that any (wildcard identity of type "address" should fall under this profile.

It is important to mention that we're discussing about peer IDENTITY, in this case peer of type address with value of "any" is matched.

Self-identity statement tells this router to use it's own identity of type address when performing authentication.

Optionally, in case of VRF-ware IPsec, this is where IVRF (in this case MY_IVRF) is referenced.


It is also important to note that our identity (self-identity) is what the remote peer will have to match in their ISAKMP profile.

In a classic exampe if we send our identity as address, the remote peer will have to match identity of type "address".


We've covered:

  1. How to protect IKE negotiation
  2. How to authenticate ourselves and peer.

The Diffie-Hellman keys (and other parameters, or VIDs) are exchanged automatically and rarely require much configuration.



As in case of IKE certain parameters need to be exchanged for IPsec SAs to be established. Also as in case of ISAKMP profile we will introduce a central component of crypto map.

  • IPsec transform set.

As discussed previously a device needs to know how to protect traffic, this is where transform set comes into play. It defines what hashing and encryption algorithm is to be used to protect traffic.

crypto ipsec transform-set MY_SET esp-3des esp-sha-hmac 

In this case 3DES and SHA were chosen.

For guidance and recommendations on current best practices about chosing the right algorithms refer to:



  • Traffic selection

Crypto maps use traffic selection mechanism in form of access-list.

The access-list is always defined from local perspective, i.e. Cisco devices will use an access-list which will select (using permit statement) traffic from X to Y and on it's peer the access-list will be mirrored selecting traffic from Y to X.

It is important to note that this is one of the things checked/enforced during negotiation.

access-list 100 permit ip any

In this case router will be interested to encrypt all traffic from subnet. The remote end will used access-list specifying the reverse "any to" (or use dynamic crypto map!).


  • Crypto map

Crypto map is a feature binding all the information we discussed before in this section and previous together.

A few facts about crypto map.

    1. One crypto map can be applied to an interface
    2. Same crypto map can be applied to multiple interfaces
    3. To accommodate multiple tunnels crypto map entries are used. One crypto map can have multiple entries, identified by a number.
    4. Static crypto map can reference a dynamic crypto map.




The two crypto map types discussed and their usage:

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


crypto map MY_CRYPTO_MAP 100 ipsec-isakmp

set peer

set transform-set MY_SET

set isakmp-profile MY_PROFILE

match address 100

Looking at this example,

Crypto map names MY_CRYPTO_MAP has entry 100 using ISAKMP to negotiate IPsec.

This crypto map entry should match traffic specified by access-list 100 and perform parameters defined in ISAKMP profile called MY_PROFILE.

The way to protect traffic is defined in transform set MY_SET.

When performing IKE negotiation, packets should be sent to peer


A crypto map (by name) is then applied to an interface.

r2#sh run int e1/0

Building configuration...



Current configuration : 80 bytes


interface Ethernet1/0

ip address

crypto map MY_CRYPTO_MAP







When troubleshooting both show and debug commands should be used.


Show commands

  • show crypto isakmp sa - shows status of IKE session on this device.

r2#sh crypto isa sa


dst             src             state          conn-id status        QM_IDLE           1004 ACTIVE

In this case there's only one session and it's in state "ACTIVE".


  • show crypto ipsec sa - shows status of IPsec SAs. Crucial information to look for, what traffic is being protected, from what IVRF (protected VRF) and if IPsec SAs (or SPIs) are in active state.

r2#sh crypto ipsec sa



interface: Ethernet1/0

    Crypto map tag: MAP, local addr



   protected vrf: (none)

   local  ident (addr/mask/prot/port): (

   remote ident (addr/mask/prot/port): (

   current_peer port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5

    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0



     local crypto endpt.:, remote crypto endpt.:

     path mtu 1500, ip mtu 1500, ip mtu idb Ethernet1/0

     current outbound spi: 0xDFDE17CA(3755874250)

     PFS (Y/N): N, DH group: none



     inbound esp sas:

      spi: 0x205F6BE9(543124457)

        transform: esp-aes esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 13, flow_id: SW:13, sibling_flags 80000040, crypto map: MY_CRYPTO_MAP

        sa timing: remaining key lifetime (k/sec): (4335214/3551)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE(ACTIVE)



     inbound ah sas:



     inbound pcp sas:



     outbound esp sas:

      spi: 0xDFDE17CA(3755874250)

        transform: esp-aes esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 14, flow_id: SW:14, sibling_flags 80000040, crypto map: MY_CRYPTO_MAP

        sa timing: remaining key lifetime (k/sec): (4335214/3551)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE(ACTIVE)



     outbound ah sas:



     outbound pcp sas:


In the above case traffic between local (in global VRF) to remote is protected and remote peer is

There are two IPsec SAs active (one in each direction) and we processed total of 5 packets in each direction.


  • show crypto session  - shows a at a glance view of different tunnels on this device.

r2#sh crypto session

Crypto session current status



Interface: Ethernet1/0

Session status: UP-ACTIVE

Peer: port 500

  IKEv1 SA: local remote Active

  IPSEC FLOW: permit ip

        Active SAs: 2, origin: crypto map


Show crypto session offers at-a-glance view of information gathered already with previous commands.

Peer IP address, what is the protected traffic and how many active SAs are present.

This situation is from a working tunnel.




To narrow down debugging to one peer conditional debugging should be used.

On IOS this is done by performing:

debug crypto condition peer ipv4 ....


Two major component can be debugged

  • debug crypto isakmp - information specific to ISAKMP exchange. This will contain information about main mode and quick mode negotiation.
  • debug crypto ipsec - some phase 2 specific information can be found here.



  • VRF-aware IPsec cheatsheet


  • Understanding main mode debugs:


Correction  of IP protocol

  • Authentication Service -  AH (Authentication Header) and IP protocol 51.
  • Encryption Services -  ESP (Encapsulating Security Payload) and IP protocol of 50.
Marcin Latosiewicz
Cisco Employee
Cisco Employee

Of course you're correct. Reference:

Unfortunately I can't rate your answer, the rating button is not available :{

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links