Using Ip Domain Name And Generate Rsa Key

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

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.

With a secure shell (SSH) key pair, you can create virtual machines (VMs) in Azure that use SSH keys for authentication, eliminating the need for passwords to sign in. This article shows you how to quickly generate and use an SSH public-private key file pair for Linux VMs. You can complete these steps with the Azure Cloud Shell, a macOS or Linux host, the Windows Subsystem for Linux, and other tools that support OpenSSH.

Rsa

Note

VMs created using SSH keys are by default configured with passwords disabled, which greatly increases the difficulty of brute-force guessing attacks.

I did a little research and found out that if I removed the rsa key by using this command ' crypto key zeroize rsa' and then added the 'crypto key generate rsa generate-keys modulus 1024, then that would work. Any thoughts? No service pad. No service password-encryption. Hostname Sales-SW-ACC2. Ip domain name my.company.come. Feb 17, 2018  ip domain-name. Defines a default domain name to complete unqualified hostnames (names without a dotted-decimal domain name). Show crypto key mypubkey rsa. Displays the RSA public keys of your router. Show crypto pki certificates. Displays information about your PKI certificate, certification authority, and any registration authority certificates.

For more background and examples, see Detailed steps to create SSH key pairs.

For additional ways to generate and use SSH keys on a Windows computer, see How to use SSH keys with Windows on Azure.

Supported SSH key formats

Azure currently supports SSH protocol 2 (SSH-2) RSA public-private key pairs with a minimum length of 2048 bits. Other key formats such as ED25519 and ECDSA are not supported.

Create an SSH key pair

Use the ssh-keygen command to generate SSH public and private key files. By default, these files are created in the ~/.ssh directory. You can specify a different location, and an optional password (passphrase) to access the private key file. If an SSH key pair with the same name exists in the given location, those files are overwritten.

The following command creates an SSH key pair using RSA encryption and a bit length of 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 --generate-ssh-keys option will not overwrite existing key files, instead returning an error. In the following command, replace VMname and RGname with your own values:

Provide an SSH public key when deploying a VM

To create a Linux VM that uses SSH keys for authentication, specify your SSH public key when creating the VM using the Azure portal, Azure CLI, Azure Resource Manager templates, or other methods:

If you're not familiar with the format of an SSH public key, you can display your public key with the following cat command, replacing ~/.ssh/id_rsa.pub with the path and filename of your own public key file if needed:

Name

A typical public key value looks like this example:

Using Ip Domain Name And Generate Rsa Key Mac

If you copy and paste the contents of the public key file to use in the Azure portal or a Resource Manager template, make sure you don't copy any trailing whitespace. To copy a public key in macOS, you can pipe the public key file to pbcopy. Similarly in Linux, you can pipe the public key file to programs such as xclip.

Generate

The public key that you place on your Linux VM in Azure is by default stored in ~/.ssh/id_rsa.pub, unless you specified a different location when you created the key pair. To use the Azure CLI 2.0 to create your VM with an existing public key, specify the value and optionally the location of this public key using the az vm create command with the --ssh-key-values option. In the following command, replace VMname, RGname, and keyFile with your own values:

If you want to use multiple SSH keys with your VM, you can enter them in a space-separated list, like this --ssh-key-values sshkey-desktop.pub sshkey-laptop.pub.

SSH into your VM

With the public key deployed on your Azure VM, and the private key on your local system, SSH into your VM using the IP address or DNS name of your VM. In the following command, replace azureuser and myvm.westus.cloudapp.azure.com with the administrator user name and the fully qualified domain name (or IP address):

If you specified a passphrase when you created your key pair, enter that passphrase when prompted during the login process. The VM is added to your ~/.ssh/known_hosts file, and you won't be asked to connect again until either the public key on your Azure VM changes or the server name is removed from ~/.ssh/known_hosts.

Using Ip Domain Name And Generate Rsa Keys

If the VM is using the just-in-time access policy, you need to request access before you can connect to the VM. For more information about the just-in-time policy, see Manage virtual machine access using the just in time policy.

Using Ip Domain Name And Generate Rsa Key In Packet Tracer

Next steps

Using Ip Domain Name And Generate Rsa Key Generator

  • For more information on working with SSH key pairs, see Detailed steps to create and manage SSH key pairs.

  • If you have difficulties with SSH connections to Azure VMs, see Troubleshoot SSH connections to an Azure Linux VM.