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.

Page updated

Google Sites

Report abuse