Site-to-site IPSec VPN using Digital Certificates

Site-to-site IPSec VPN using Digital Certificates

IPSec with digital certificate provides the most secure and scalable way to implement a VPN. Authentication in IPSec can be provided through pre-shared keys (easy to implement) or digital certificate (requires a CA Server trusted by both parties).

The following scenario demonstrates IPSec VPN between two Branch routers who obtain a Digital Certificate from a CA Server (Windows Server 2003) based in their Central Office.

Obtaining Digital Certificates for the Branch routers

First step is to obtain a digital certificate from the trusted CA Server. This requires a hostname and domain-name on both Branch routers. It also requires time synchronization between routers and CA Server.

hostname Branch1
ip domain-name amit.com
!
ntp server 192.168.1.9

Then we generate general-purpose RSA keys. This process generates a Public Key and a Private Key.

Branch1(config)# crypto key generate rsa general-keys modulus 1024 label BRANCH_KEY exportable         ! generating a general-purpose key pair of 1024 bits labelled as BRANCH_KEY.

Then we create a trustpoint on the routers to define the trusted CA Server.

crypto pki trustpoint WIN2003 ! Windows Server 2003 (192.168.1.9). This trustpoint name is user-defined and has local significance.

 enrollment url http://192.168.1.9/certsrv/mscep/mscep.dll
 enrollment mode ra              ! Required as Server 2003 provides Registration Authority (RA) when SCEP is installed
 rsakeypair BRANCH_KEY
 revocation-check none
!

After creating the trustpoint, we request the CA Certificate for this trustpoint. This is to validate the CA Server.

Branch1(config)# crypto pki authenticate WIN2003
Certificate has the following attributes:
       Fingerprint MD5: 7D39EB83 CE48ECF4 91E5E5F7 A0022760
      Fingerprint SHA1: D27CD5D2 865FC153 26CA66A2 197AABF6 922510BF
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
Branch1(config)#

And the last step in the process of obtaining certificate is to actually request a digital certificate from the CA Server for the router itself using crypto pki enroll WIN2003 command. The CA Server will generate a unique digital certificate for each routers.

The following output shows the digital certificates available on the routers.

Branch1# show crypto pki certificates
Certificate
  Status: Available
  Certificate Serial Number: 0x614C662A000000000009
  Certificate Usage: General Purpose
  Issuer:
    cn=WIN2003
    dc=amit
    dc=com
  Subject:
    Name: Branch1.amit.com
    hostname=Branch1.amit.com
  CRL Distribution Points:
    ldap:///CN=WIN2003,CN=amit-ed0d48583a,CN=CDP,CN=Public%20Key%20Services,CN=S  
ervices,CN=Configuration,DC=amit,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
    http://amit-ed0d48583a.amit.com/CertEnroll/WIN2003.crl
  Validity Date:
    start date: 04:00:18 AEST Jun 5 2010
    end   date: 04:10:18 AEST Jun 5 2011
  Associated Trustpoints: WIN2003
CA Certificate
  Status: Available
  Certificate Serial Number: 0x6462CFFA77B593A74DB4E13D530CBC02
  Certificate Usage: Signature
  Issuer:
    cn=WIN2003
    dc=amit
    dc=com
  Subject:
    cn=WIN2003
    dc=amit
    dc=com
  CRL Distribution Points:
    ldap:///CN=WIN2003,CN=amit-ed0d48583a,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=amit,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
    http://amit-ed0d48583a.amit.com/CertEnroll/WIN2003.crl
  Validity Date:
    start date: 03:31:18 AEST May 21 2010
    end   date: 03:40:13 AEST May 21 2020
  Associated Trustpoints: WIN2003
Branch2# show crypto pki certificates
Certificate
  Status: Available
  Certificate Serial Number: 0x614AE084000000000008
  Certificate Usage: General Purpose
  Issuer:
    cn=WIN2003
    dc=amit
    dc=com
  Subject:
    Name: Branch2.amit.com
    hostname=Branch2.amit.com
  CRL Distribution Points:
   
ldap:///CN=WIN2003,CN=amit-ed0d48583a,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=amit,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
    http://amit-ed0d48583a.amit.com/CertEnroll/WIN2003.crl
  Validity Date:
    start date: 03:58:38 AEST Jun 5 2010
    end   date: 04:08:38 AEST Jun 5 2011
  Associated Trustpoints: WIN2003
CA Certificate
  Status: Available
  Certificate Serial Number: 0x6462CFFA77B593A74DB4E13D530CBC02
  Certificate Usage: Signature
  Issuer:
    cn=WIN2003
    dc=amit
    dc=com
  Subject:
    cn=WIN2003
    dc=amit
    dc=com
  CRL Distribution Points:
   
ldap:///CN=WIN2003,CN=amit-ed0d48583a,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=amit,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
    http://amit-ed0d48583a.amit.com/CertEnroll/WIN2003.crl
  Validity Date:
    start date: 03:31:18 AEST May 21 2010
    end   date: 03:40:13 AEST May 21 2020
  Associated Trustpoints: WIN2003

Configuring IKE Policies

The crypto isakmp policy <number> command creates IKE Phase 1 policy. The range of "number" parameters is 1-10000. The authentication command specifies the type of authentication to use when validating the identity of the remote IPSec peer.

1. rsa-sig : This method specifies that digital certificates are used for authentication.

2. rsa-encr: This method specifies that RSA encrypted nonces (random numbers) are used.

3. pre-share: This method specifies that a single pre-shared key is used.

crypto isakmp policy 10
 encryption 3des
 authentication rsa-sig
 hash md5
 group 1
!

IKE Phase 1 policies can be verified using show crypto isakmp policy command.

Configuring Transform-set and Defining Interesting Traffic

A transform-set defines how data traffic is protected in IKE Phase 2. The transform set protection parameters implemented here are-

esp-3des: ESP encryption with 3DES

esp-md5-hmac: ESP packet integrity check with MD5

All traffic from 192.168.11.0/24 to 192.168.22.0/24, and vice versa, should go through IPSec tunnel.

crypto ipsec transform-set TS esp-3des esp-md5-hmac
!
ip access-list extended ACL
 permit ip 192.168.11.0 0.0.0.255 192.168.22.0 0.0.0.255

The transform-set can be verified using show crypto ipsec transform-set command.

Configuring Static Crypto Map

A crypto map ties together all the IKE Phase 2 components to build protected data connections to remote IPSec peer.

crypto map CRYPTO 10 ipsec-isakmp
 match address ACL
 set peer 10.2.2.1
 set transform-set TS
!
interface serial 1/0
 ip address 10.1.1.1 255.255.255.0
 crypto map CRYPTO

Verification

When Branch1 router initiates a Ping to remote LAN using the source-interface as its LAN interface, the traffic matches the ACL and is considered interesting traffic. IKE Phase 1 begins at this stage. No traffic is sent successfully until IKE Phase 1 and 2 are successfully completed.

The purpose of IKE Phase 1 is to establish a secure communication channel (sometimes called management connection) and generate keys for IPSec.

Branch1 router initiates IKE negotiation by sending a Policy Proposal message to its peer. This message contains one or more IKE policies containing parameters such as encryption algorithm, authentication method, hash algorithm, Diffie-Hellman group and SA lifetime. The peer router examines the IKE policy information and attempts to find a match within its own locally configured IKE policies. It responds with a Policy Acceptance message of acceptance of one of the sender's policies. The IKE policy is now negotiated.

IKE Policy Negotiated

Jun  6 10:21:50.071: ISAKMP:(0): SA request profile is (NULL)
Jun  6 10:21:50.071: ISAKMP: Created a peer struct for 10.2.2.1, peer port 500
Jun  6 10:21:50.071: ISAKMP: New peer created peer = 0x6735D84C peer_handle = 0x80000002
Jun  6 10:21:50.071: ISAKMP: Locking peer struct 0x6735D84C, refcount 1 for isakmp_initiator
Jun  6 10:21:50.075: ISAKMP: local port 500, remote port 500
Jun  6 10:21:50.075: ISAKMP: set new node 0 to QM_IDLE
Jun  6 10:21:50.087: insert sa successfully sa = 66BF8998
Jun  6 10:21:50.087: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
Jun  6 10:21:50.091: ISAKMP:(0):No pre-shared key with 10.2.2.1!
Jun  6 10:21:50.091: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
Jun  6 10:21:50.095: ISAKMP:(0): constructed NAT-T vendor-07 ID
Jun  6 10:21:50.095: ISAKMP:(0): constructed NAT-T vendor-03 ID
Jun  6 10:21:50.095: ISAKMP:(0): constructed NAT-T vendor-02 ID
Jun  6 10:21:50.095: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM

Jun 6 10:21:50.095: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1 ! Indicates IKE negotiation has begun and first ISAKMP message in Main Mode is about to be sent

Jun  6 10:21:50.099: ISAKMP:(0): beginning Main Mode exchange

Jun 6 10:21:50.099: ISAKMP:(0): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I) MM_NO_STATE ! Indicates Branch1 router is sending IKE Policy Proposal message

Jun  6 10:21:50.099: ISAKMP:(0):Sending an IKE IPv4 Packet.

Jun 6 10:21:50.307: ISAKMP (0:0): received packet from 10.2.2.1 dport 500 sport 500 Global (I) MM_NO_STATE ! Indicates Branch1 router received IKE Policy Acceptance message from remote peer

Jun  6 10:21:50.319: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

Jun 6 10:21:50.319: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM2 ! Indicates that first two messages were exchanged successfully

Jun  6 10:21:50.323: ISAKMP:(0): processing SA payload. message ID = 0
Jun  6 10:21:.!50.327: ISAKMP:(0): processing vendor id payload
Jun  6 10:21:50.327: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
Jun  6 10:21:50.327: ISAKMP (0:0): vendor ID is NAT-T RFC 3947
Jun  6 10:21:50.327: ISAKMP : Scanning profiles for xauth ...
Jun  6 10:21:50.331: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
Jun  6 10:21:50.331: ISAKMP:      encryption 3DES-CBC
Jun  6 10:21:50.331: ISAKMP:      hash MD5
Jun  6 10:21:50.331: ISAKMP:      default group 1
Jun  6 10:21:50.331: ISAKMP:      auth RSA sig
Jun  6 10:21:50.331: ISAKMP:      life type in seconds
Jun  6 10:21:50.335: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80

Jun 6 10:21:50.335: ISAKMP:(0):atts are acceptable. Next payload is 0 ! Indicates that the attributes received are acceptable

Jun  6 10:21:50.335: ISAKMP:(0):Acceptable atts:actual life: 0
Jun  6 10:21:50.339: ISAKMP:(0):Acceptable atts:life: 0
Jun  6 10:21:50.339: ISAKMP:(0):Fill atts in sa vpi_length:4
Jun  6 10:21:50.339: ISAKMP:(0):Fill atts in sa life_in_seconds:86400
Jun  6 10:21:50.339: ISAKMP:(0):Returning Actual lifetime: 86400
Jun  6 10:21:50.343: ISAKMP:(0)::Started lifetime timer: 86400
Jun  6 10:21:50.395: ISAKMP:(0): processing vendor id payload
Jun  6 10:21:50.395: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
Jun  6 10:21:50.395: ISAKMP (0:0): vendor ID is NAT-T RFC 3947
Jun  6 10:21:50.395: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Jun  6 10:21:50.395: ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM2

The next two message serve to exchange Diffie-Hellman Public-Key values. Diffie-Hellman is a public-key algorithm that allows peers to exchange Public Key values over an insecure network. Combined together with their own Private Keys, both routers derive a same shared secret key (also called session key).

Diffie-Hellman Key Exchange

Jun  6 10:21:50.395: ISAKMP (0:0): constructing CERT_REQ for issuer cn=WIN2003,dc=amit,dc=com

Jun 6 10:21:50.399: ISAKMP:(0): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I) MM_SA_SETUP ! Indicates Branch1 router is sending its Diffie-Hellman Public Key and Nonce value to remote peer

Jun  6 10:21:50.399: ISAKMP:(0):Sending an IKE IPv4 Packet.
Jun  6 10:21:50.399: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

Jun 6 10:21:50.403: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM3 ! Indicates third message in IKE Phase 1 is sent

Jun 6 10:21:50.587: ISAKMP (0:0): received packet from 10.2.2.1 dport 500 sport 500 Global (I) MM_SA_SETUP ! Indicates Branch1 router receives Diffie-Hellman Public Key and Nonce value from remote peer- Branch2 router

Jun  6 10:21:50.587: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Jun  6 10:21:50.591: ISAKMP:(0):Old State = IKE_I_MM3  New State = IKE_I_MM4    ! Indicates that four messages have been exchanged successfully in IKE Phase 1

Jun 6 10:21:50.595: ISAKMP:(0): processing KE payload. message ID = 0 ! This payload contains Diffie-Hellman Public Key of Branch2 router

Jun 6 10:21:50.659: ISAKMP:(0): processing NONCE payload. message ID = 0 ! This payload contains the Nonce (random value) of Branch2 router

The last two messages of IKE Phase 1 between IKE peers using RSA-Signature exchange Identification, Digital Certificate and Digital Signature. The ID can be the peer IP Address or fully qualified domain name (FQDN). The messages are encrypted using the encryption method negotiated in IKE Policy and the key used is the session-key derived using Diffie-Hellman key exchange.

ID and Certificate Exchange in IKE Phase 1

Jun  6 10:21:50.659: ISAKMP:(1001): processing CERT_REQ payload. message ID = 0

Jun 6 10:21:50.659: ISAKMP:(1001): peer wants a CT_X509_SIGNATURE cert ! Indicates the peer has requested a Digital Certificate as the authentication method used is RSA-SIG

Jun  6 10:21:50.659: ISAKMP:(1001): peer wants cert issued by cn=WIN2003,dc=amit,dc=com
Jun  6 10:21:50.659:  Choosing trustpoint WIN2003 as issuer
Jun  6 10:21:50.659: ISAKMP:(1001): processing vendor id payload
Jun  6 10:21:50.659: ISAKMP:(1001): vendor ID is Unity
Jun  6 10:21:50.663: ISAKMP:(1001): processing vendor id payload
Jun  6 10:21:50.663: ISAKMP:(1001): vendor ID is DPD
Jun  6 10:21:50.663: ISAKMP:(1001): processing vendor id payload
Jun  6 10:21:50.667: ISAKMP:(1001): speaking to another IOS box!
Jun  6 10:21:50.667: ISAKMP:received payload type 20
Jun  6 10:21:50.667: ISAKMP:received payload type 20
Jun  6 10:21:50.667: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Jun  6 10:21:50.671: ISAKMP:(1001):Old State = IKE_I_MM4  New State = IKE_I_MM4
Jun  6 10:21:50.675: ISAKMP:(1001):Send initial contact
Jun  6 10:21:50.691: ISAKMP:(1001):My ID configured as IPv4 Addr, but Addr not in Cert!
Jun  6 10:21:50.691: ISAKMP:(1001):Using FQDN as My ID
Jun  6 10:21:50.691: ISAKMP:(1001):SA is doing RSA signature authentication using id type ID_FQDN
Jun  6 10:21:50.691: ISAKMP (0:1001): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : Branch1.amit.com
        protocol     : 17
        port         : 500
        length       : 24
Jun  6 10:21:50.691: ISAKMP:(1001):Total payload length: 24
Jun  6 10:21:50.707: ISAKMP (0:1001): constructing CERT payload for hostname=Branch1.amit.com
Jun  6 10:21:50.707: ISKAMP: growing send buffer from 1024 to 3072

Jun 6 10:21:50.707: ISAKMP:(1001): using the WIN2003 trustpoint's keypair to sign ! Indicates the Digital Certificate is signed by the Public Key of the CA Server (Windows Server 2003)

Jun  6 10:21:50.751: ISAKMP:(1001): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
Jun  6 10:21:50.755: ISAKMP:(1001):Sending an IKE IPv4 Packet.
Jun  6 10:21:50.755: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

Jun 6 10:21:50.759: ISAKMP:(1001):Old State = IKE_I_MM4 New State = IKE_I_MM5 ! Indicates the Branch1 router has sent the fifth message of IKE Phase 1 containing the Digital Certificate

Jun 6 10:21:51.075: ISAKMP (0:1001): received packet from 10.2.2.1 dport 500 sport 500 Global (I) MM_KEY_EXCH ! This router has received the Digital Certificate from the peer

Jun  6 10:21:51.083: ISAKMP:(1001): processing ID payload. message ID = 0
Jun  6 10:21:51.083: ISAKMP (0:1001): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : Branch2.amit.com
        protocol     : 17
        port         : 500
        length       : 24
Jun  6 10:21:51.087: ISAKMP:(0):: peer matches *none* of the profiles

Jun 6 10:21:51.087: ISAKMP:(1001): processing CERT payload. message ID = 0 ! The CERT payload contains the Digital Certificate

Jun  6 10:21:51.087: ISAKMP:(1001): processing a CT_X509_SIGNATURE cert
Jun  6 10:21:51.143: ISAKMP:(1001): peer's pubkey isn't cached
Jun  6 10:21:51.187: ISAKMP:(1001): Unable to get DN from certificate!
Jun  6 10:21:51.191: ISAKMP:(1001): Cert presented by peer contains no OU field.
Jun  6 10:21:51.191: ISAKMP:(0):: peer matches *none* of the profiles

Jun 6 10:21:51.199: ISAKMP:(1001): processing SIG payload. message ID = 0 ! This router is processing the Digital Signature of the Certificate contained in SIG payload

Jun  6 10:21:51.215: ISAKMP:(1001):SA authentication status:
        authenticated

Jun 6 10:21:51.215: ISAKMP:(1001):SA has been authenticated with 10.2.2.1 ! This indicates the peers have authenticated themselves

Jun  6 10:21:51.219: ISAKMP: Trying to insert a peer 10.1.1.1/10.2.2.1/500/,  and inserted successfully 6735D84C.
Jun  6 10:21:51.219: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

Jun 6 10:21:51.219: ISAKMP:(1001):Old State = IKE_I_MM5 New State = IKE_I_MM6 ! Indicates the sixth message has been exchanged in IKE Phase 1

Jun  6 10:21:51.223: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Jun  6 10:21:51.223: ISAKMP:(1001):Old State = IKE_I_MM6  New State = IKE_I_MM6
Jun  6 10:21:51.231: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Jun  6 10:21:51.231: ISAKMP:(1001):Old State = IKE_I_MM6  New State = IKE_P1_COMPLETE
Jun  6 10:21:51.247: ISAKMP:(1001):beginning Quick Mode exchange, M-ID of -1512312688
Jun  6 10:21:51.251: ISAKMP:(1001):QM Initiator gets spi
Jun  6 10:21:51.255: ISAKMP:(1001): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I) QM_IDLE
Jun  6 10:21:51.255: ISAKMP:(1001):Sending an IKE IPv4 Packet.
Jun  6 10:21:51.259: ISAKMP:(1001):Node -1512312688, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
Jun  6 10:21:51.259: ISAKMP:(1001):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
Jun  6 10:21:51.259: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Jun  6 10:21:51.263: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

The completion of IKE Phase 1 can be verified using show crypto isakmp sa command.

show crypto isakmp sa

Branch1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
10.2.2.1        10.1.1.1        QM_IDLE           1001    0 ACTIVE
IPv6 Crypto ISAKMP SA

At this point a bidirectional SA is established between the peers. This is used to secure IKE Phase 2 negotiations which are used to negotiate IPSec SAs.

In IKE Phase 2, three messages are exchanged between IPSec peers. IKE Phase 2 occurs in only Quick Mode. The first message contains a Hash, IPSec proposals (configured using crypto ipsec transform-set command), a Nonce value and ID. The Hash authenticates the message to the remote peer. The IPSec proposals used to specify the security protocol like AH or ESP, encryption algorithm like DES/3DES/AES, and IPSec tunnel mode like Transport mode or Tunnel mode. The Nonce value is used to protect against replay attacks.

An additional Diffie-Hellman Key Exchange can also occur if Perfect Forward Secrecy (PFS) is enabled in IPSec Proposal. This is configured as below. Group 1/2/5 indicates Diffie-Hellman groups.

Enabling PFS

crypto map CRYPT0 10 ipsec-isakmp
 match address ACL
 set peer 10.2.2.1
 set transform-set TS
 set pfs {group 1 | group 2 | group 5}

The ID payload contains the identities like address, port, protocol for which this IPSec SA is being established. This is defined using crypto access-list (configured using match address <acl> command).

The remote peer then responds with a Hash, an IPSec Proposal Acceptance, a Nonce value, and identities. This is the second message of IKE Phase 2.

The last message contains a Hash, and it is used to acknowledge to the remote peer.

IKE Phase 2 messages

Jun  6 10:21:51.247: ISAKMP:(1001):beginning Quick Mode exchange, M-ID of -1512312688    ! IKE Phase 2 begins in Quick Mode
Jun  6 10:21:51.251: ISAKMP:(1001):QM Initiator gets spi
Jun  6 10:21:51.255: ISAKMP:(1001): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I) QM_IDLE
Jun  6 10:21:51.255: ISAKMP:(1001):Sending an IKE IPv4 Packet.    ! This router (initiator) sends the first message in IKE Phase 2
Jun  6 10:21:51.259: ISAKMP:(1001):Node -1512312688, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
Jun  6 10:21:51.259: ISAKMP:(1001):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
Jun  6 10:21:51.259: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Jun  6 10:21:51.263: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Jun 6 10:21:51.447: ISAKMP (0:1001): received packet from 10.2.2.1 dport 500 sport 500 Global (I) QM_IDLE ! This is the second message in IKE Phase 2

Jun  6 10:21:51.451: ISAKMP:(1001): processing HASH payload. message ID = -1512312688
Jun  6 10:21:51.451: ISAKMP:(1001): processing SA payload. message ID = -1512312688
Jun  6 10:21:51.455: ISAKMP:(1001):Checking IPSec proposal 1
Jun  6 10:21:51.455: ISAKMP: transform 1, ESP_3DES
Jun  6 10:21:51.455: ISAKMP:   attributes in transform:
Jun  6 10:21:51.455: ISAKMP:      encaps is 1 (Tunnel)
Jun  6 10:21:51.455: ISAKMP:      SA life type in seconds
Jun  6 10:21:51.455: ISAKMP:      SA life duration (basic) of 3600
Jun  6 10:21:51.459: ISAKMP:      SA life type in kilobytes
Jun  6 10:21:51.459: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
Jun  6 10:21:51.459: ISAKMP:      authenticator is HMAC-MD5

Jun 6 10:21:51.463: ISAKMP:(1001):atts are acceptable. ! The transform-set parameters are acceptable by this router

Jun  6 10:21:51.463: ISAKMP:(1001): processing NONCE payload. message ID = -1512312688
Jun  6 10:21:51.463: ISAKMP:(1001): processing ID payload. message ID = -1512312688
Jun  6 10:21:51.467: ISAKMP:(1001): processing ID payload. message ID = -1512312688
Jun  6 10:21:51.471: ISAKMP:(1001): Creating IPSec SAs
Jun  6 10:21:51.475:         inbound SA from 10.2.2.1 to 10.1.1.1 (f/i)  0/ 0
        (proxy 192.168.22.0 to 192.168.11.0)
Jun  6 10:21:51.475:         has spi 0xAC4D6EB3 and conn_id 0
Jun  6 10:21:51.475:         lifetime of 3600 seconds
Jun  6 10:21:51.475:         lifetime of 4608000 kilobytes
Jun  6 10:21:51.479:         outbound SA from 10.1.1.1 to 10.2.2.1 (f/i) 0/0
        (proxy 192.168.11.0 to 192.168.22.0)
Jun  6 10:21:51.479:         has spi  0x34F84D56 and conn_id 0
Jun  6 10:21:51.479:         lifetime of 3600 seconds
Jun  6 10:21:51.479:         lifetime of 4608000 kilobytes
Jun  6 10:21:51.483: ISAKMP:(1001): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I) QM_IDLE

Jun 6 10:21:51.483: ISAKMP:(1001):Sending an IKE IPv4 Packet. ! This is the last message in IKE Phase 2

Jun  6 10:21:51.487: ISAKMP:(1001):deleting node -1512312688 error FALSE reason "No Error"
Jun  6 10:21:51.487: ISAKMP:(1001):Node -1512312688, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Jun  6 10:21:51.487: ISAKMP:(1001):Old State = IKE_QM_I_QM1  New State = IKE_QM_PHASE2_COMPLETE

At this stage a uni-directional SA is established between two entities. An SA is uniquely identified by a unique 32-bit number called Security Parameter Index (SPI), destination address and security protocol.

IPSec uses Security Policy Database (SPD) and Security Association Database (SAD). The SPD defines traffic that should be dropped, traffic that should be protected by IPSec and traffic that should not be protected by IPSec. The SAD contains the SA parameters like SPI, algorithms and keys.

If during traffic processing, the outbound traffic that should be protected by IPSec has no SA in SAD, this will trigger IKE protocol to negotiate IPSec SA with remote peer.

The show crypto ipsec sa command shows parameters of IPSec SA including the number of packets that passed through IPSec tunnel successfully.

show crypto ipsec sa

Branch1# show crypto ipsec sa
interface: Serial0/0
    Crypto map tag: CRYPTO, local addr 10.1.1.1
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.11.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.22.0/255.255.255.0/0/0)
   current_peer 10.2.2.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0
     local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.2.2.1
     path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
     current outbound spi: 0x34F84D56(888687958)
     inbound esp sas:
      spi: 0xAC4D6EB3(2890755763)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, crypto map: CRYPTO
        sa timing: remaining key lifetime (k/sec): (4506395/3539)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0x34F84D56(888687958)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, crypto map: CRYPTO
        sa timing: remaining key lifetime (k/sec): (4506395/3539)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE
     outbound ah sas:
     outbound pcp sas:

All the actual data traffic is encrypted using the encryption algorithm negotiated in IPSec proposal.