Using Ip Domain Name And Generate Rsa Key

Posted on
Using Ip Domain Name And Generate Rsa Key Average ratng: 5,5/10 1706 votes

You need to set up ip domain-name because in order to creat encrpted password, you need to define username, ip domain-name and password. Hash alghorism reders those. BUT you can configure as following. I just did and made sure it worked just now. ^^ config step 1. Ip ssh rsa keypair-name cisco. Username cisco password 0 ccie. Generate the CSR code and Private key for your certificate by running this command: openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out servercsr.txt. Note: server.key and servercsr.txt are the Private key and the CSR code files. Feel free to use any file names, as long as you keep the.key and.txt extensions. Ssh-keygen -m PEM -t rsa -b 4096 If you use the Azure CLI to create your VM with the az vm create command, you can optionally generate SSH public and private key files using the -generate-ssh-keys option. The key files are stored in the /.ssh directory unless specified otherwise with the -ssh-dest-key-path option. – The RSA key is configured as exportable so you can copy and save it to a secure location for future use. – The ‘key-string’ used under the username ‘admin’ is the public key of the users PC. Generating public keys on a Windows host machine: Note: I have used SecureCRT to generate the key pair. You can also use puttygen to achieve. Mar 07, 2016  I haven't known the command in question to be interactive - though it might refuse to run if there's no ip domain-name configured. Personally, I'm a big believer in using named RSA keys for various purposes. Why not generate a new key using the label keyword. Sep 18, 2013  I am using meta call back since i am not using ip.src to store the sender ip address instead i am using device.ip as the meta. So another question on feeds If a new entry is added to csv file then we need to create the feed again and then upload it? R1(config)#hostname RTR1 RTR1(config)#ip domain-name mydomain.local RTR1(config)#crypto key generate rsa The name for the keys will be: RTR1.mydomain.local Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.

Quickbooks desktop pro 2019 key generator. Dec 29, 2019  Quickbooks Desktop Pro Premier 2019 product is arguably the best and worldwide affiliated bookkeeping programming which cannot resistible to utilize. It has powered by a new set of features to utilize and currently, the bookkeeping system is.

Using Ip Domain Name And Generate Rsa Key Generator

Home‎ > ‎VPN‎ > ‎

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-Keyvalues. Diffie-Hellman is a public-key algorithm that allows peers toexchange Public Key values over an insecure network. Combined togetherwith 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. Thisis used to secure IKE Phase 2 negotiations which are used to negotiateIPSec 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.