Using Ip Domain Name And Generate Rsa Key

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.

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

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

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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