*Big credit to Chris Bryant and his CCNP Study Guide for the majority of the below content.
Configuring Site-to-Site IPSec VPNs
Configuring a site-to-site VPN is basically a five-step process.
- Process Initialization via “interesting traffic”
- IKE Phase 1 (IKE SA negotiation)
- IKE Phase 2 (IPSec SA negotiation)
- Data Transfer
- Tunnel Termination
IPSec doesn’t just start working by itself – it requires interesting traffic to be sent by a host. This interesting traffic initializes the IPSec process. A crypto access-list will define interesting traffic for our VPN.
IKE Phase I. Assuming we’re running Main mode, there will be six messages overall. The initiator will first transmit proposals for the encryption and authentication schemes to be used. At this point, IKE’s looking for an ISAKMP policy that’s a match at both endpoints.
In the second exchange of IKE Phase I, the devices will exchange Diffie- Hellman public keys; from this point on, the rest of the negotiation is encrypted.
The initiator and recipient authenticate each other in the third exchange of Phase I, using an encrypted form of their IP addresses. The IKE SA is then established and Phase II can begin.
(If we had chosen to run IKE in Aggressive Mode, this would have been a three-message process. )
The initiator packets everything needed for the SA negotiation in the first message, including its Diffie-Hellman public key.
The recipient responds with the acceptable parameters and authentication information, and its Diffie-Hellman public key.
The initiator then sends a confirmation that it received that information, and we’re done.
IKE Phase 2 has one mode, Quick mode. This is also a three-message process. The initiator proposes parameters for the IPSec SA, the recipient responds with a list of acceptable parameters, and the initiator then transmits a message that lets the responder know that message 2 was received and processed. This message is called proof of liveness.
With the IPSec SA in place, the hosts can now exchange data.
Once the data exchange is complete, the tunnel can be torn down. This tunnel termination can be configured to occur after a certain number of bytes have passed through the tunnel, or perhaps after the tunnel have been up for a certain number of seconds.
But what if traffic is flowing through the tunnel at the same time the tunnel’s supposed to be torn down? No fear – a new Security Association can be agreed upon while the existing one is still in place.
Creating An IKE Policy
Before configuring the IKE policy, make sure ISAKMP is enabled with the crypto isakmp enable command. It’s supposed to be on by default, but we all know how that is.
R1(config)#crypto isakmp enable
To display the current IKE policies, run show crypto isakmp policy.
R1#show crypto isakmp policy
Global IKE policy
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
We’re not going to use the default, however. We’ll create a custom policy with the crypto isakmp policy command. Policies can be assigned priorities, as shown below by IOS Help. The lower the number, the higher the priority, with 1 being the highest priority. There is no default.
R1(config)#crypto isakmp policy ?
<1-10000> Priority of protection suite
R1(config)#crypto isakmp policy 100
IOS Help shows the options for the IKE policy.
The options for authentication are preshared keys, RSA Signature, and RSA Encryption. The default is RSA Signature. We’ll configure the policy to use preshared keys.
pre-share Pre-Shared Key
rsa-encr Rivest-Shamir-Adleman Encryption
rsa-sig Rivest-Shamir-Adleman Signature
The options for encryption are DES, AES, and 3DES (TDES). The default is DES. We'll use 3DES.
3des Three key triple DES
aes AES - Advanced Encryption Standard.
des DES - Data Encryption Standard (56 bit keys).
We do have options for the Diffie-Hellman group, so we’ll use group 5.
The default is group 1.
1 Diffie-Hellman group 1
2 Diffie-Hellman group 2
5 Diffie-Hellman group 5
The hash algorithm will be either MD5 or SHA. The default is SHA, so we’ll set the policy to MD5.
md5 Message Digest 5
sha Secure Hash Standard
Finally, we need to set the SA lifetime. The default is the maximum number of seconds, 86,400, which equals 24 hours. We’ll set that to 42,400 seconds.
<60-86400> lifetime in seconds
show crypto isakmp policy displays both policies on the router – the default and the one we just wrote.
Here’s a list of the parameters and what has to happen for successful negotiation.
- Hash: exact match
- Encryption: exact match
- Authentication: exact match
- DH Group number: exact match
- Lifetime: Remote peer policy must have lifetime equal to or less than initiator. If less, the lower value is used.
To create a pre shared key:
The crypto isakmp key command does this. Along with the key itself, the IP address of the remote peer must be configured:
‘crypto isakmp key CCNP address 172.16.16.1’
‘show crypto isakmp sa’
Configuring The IPSec Transform Sets
An IPSec Transform Set is simply a group of individual parameters that will enforce a security policy. The endpoints must agree exactly on which encryption and algorithms will be used to create the IPSec SA. If there’s an exact match, the IPSec process continues; if there’s no match, the process is terminated and the session torn down.
As with ISAKMP policies, multiple transform sets can be configured and sent to a remote peer. The remote peer will compare each set received against its own transform sets, and when a match is found, the IPSec SA will be built.
crypto ipsec transform-set NAMEOFTRANSFORMSET AH or ESP
mode TUNNEL or TRANSPORT
IPSec SA Lifetimes
The default SA lifetime is 1 hour. This is another value that must match to form a VPN.
‘crypto ipsec security-association lifetime seconds 1800’
Interesting Traffic/Crypto Maps
We use an extended access list to highlight interesting traffic. Interesting traffic is what is matched to then trigger the IPSec VPN to life. The logic with these is to match traffic that is destined OUTBOUND, however you can match INBOUND traffic. The reason to match INBOUND is so that you can determine what traffic HASNT been encrypted.
Extended ACL Config Example:
access-list 123 permit ip 184.108.40.206 0.0.0.255 220.127.116.11 0.0.0.255
Crypto Map Configuration Example:
crypto map CCNP 100 ipsec-isakmp
TBC on next video…