The video walks you through configuration of Cisco AnyConnect Secure Mobility VPN with IPSec IKEv2. IKEv2 is an alternative protocol to SSL for those that have unique security requirement such as regulation compliancy. CCIE Brandon Carroll looks at the licensing issues for both Cisco AnyConnect and IPsec and offers advice on which one might be the better choice for your environment.

How IPSec Works

IPSec involves many component technologies and encryption methods. Yet IPSec's operation can be broken down into five main steps. The five steps are summarized as follows:

This five-step process is shown in Figure 1-15.

Figure 1-15 The Five Steps of IPSec

Step 1: Defining Interesting Traffic

Anyconnect Ipsec Ports

Determining what type of traffic is deemed interesting is part of formulating a security policy for use of a VPN. The policy is then implemented in the configuration interface for each particular IPSec peer. For example, in Cisco routers and PIX Firewalls, access lists are used to determine the traffic to encrypt. The access lists are assigned to a crypto policy such that permit statements indicate that the selected traffic must be encrypted, and deny statements can be used to indicate that the selected traffic must be sent unencrypted. With the Cisco Secure VPN Client, you use menu windows to select connections to be secured by IPSec. When interesting traffic is generated or transits the IPSec client, the client initiates the next step in the process, negotiating an IKE phase one exchange.

Step 1 is shown in Figure 1-16.

Figure 1-16 Defining Interesting Traffic

Step 2: IKE Phase One

The basic purpose of IKE phase one is to authenticate the IPSec peers and to set up a secure channel between the peers to enable IKE exchanges. IKE phase one performs the following functions:

• Authenticates and protects the identities of the IPSec peers

• Negotiates a matching IKE SA policy between peers to protect the IKE exchange

• Performs an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys

• Sets up a secure tunnel to negotiate IKE phase two parameters

IKE phase one occurs in two modes:

• Main mode

• Aggressive mode

Main Mode

Main mode has three two-way exchanges between the initiator and receiver.

• First exchange—The algorithms and hashes used to secure the IKE communications are agreed upon in matching IKE SAs in each peer.

• Second exchange—This exchange uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret keys and to pass nonces, which are random numbers sent to the other party, signed, and returned to prove their identity.

• Third exchange—This exchange verifies the other side's identity. The identity value is the IPSec peer's IP address in encrypted form. The main outcome of main mode is matching IKE SAs between peers to provide a protected pipe for subsequent protected ISAKMP exchanges between the IKE peers. The IKE SA specifies values for the IKE exchange: the authentication method used, the encryption and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA in seconds or kilobytes, and the shared secret key values for the encryption algorithms. The IKE SA in each peer is bidirectional.

Aggressive Mode

In the aggressive mode, fewer exchanges are done and with fewer packets. In the first exchange, almost everything is squeezed into the proposed IKE SA values, the Diffie-Hellman public key, a nonce that the other party signs, and an identity packet, which can be used to verify the initiator's identity through a third party. The receiver sends everything back that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange. The weakness of using the aggressive mode is that both sides have exchanged information before there is a secure channel. Therefore, it is possible to sniff the wire and discover who formed the new SA. However, aggressive mode is faster than main mode.

Step 2 is shown in Figure 1-17.

Figure 1-17 IKE Phase One

Step 3: IKE Phase Two

The purpose of IKE phase two is to negotiate IPSec SAs to set up the IPSec tunnel. IKE phase two performs the following functions:

• Negotiates IPSec SA parameters protected by an existing IKE SA

• Establishes IPSec security associations

• Periodically renegotiates IPSec SAs to ensure security

• Optionally performs an additional Diffie-Hellman exchange

IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in phase one. It negotiates a shared IPSec policy, derives shared secret keying material used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces that provide replay protection. The nonces are used to generate new shared secret key material and prevent replay attacks from generating bogus SAs.

Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires. Base quick mode is used to refresh the keying material used to create the shared secret key based on the keying material derived from the Diffie-Hellman exchange in phase one.

Perfect Forward Secrecy

If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman exchange is performed with each quick mode, providing keying material that has greater entropy (key material life) and thereby greater resistance to cryptographic attacks. Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use and exacting a performance cost.

Step 4: IPSec Encrypted Tunnel

After IKE phase two is complete and quick mode has established IPSec SAs, information is exchanged by an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA. This IPSec encrypted tunnel can be seen in Figure 1-18.

Figure 1-18 IPSec Encrypted Tunnel

Step 5: Tunnel Termination

IPSec SAs terminate through deletion or by timing out. An SA can time out when a specified number of seconds have elapsed or when a specified number of bytes have passed through the tunnel. When the SAs terminate, the keys are also discarded. When subsequent IPSec SAs are needed for a flow, IKE performs a new phase two and, if necessary, a new phase one negotiation. A successful negotiation results in new SAs and new keys. New SAs can be established before the existing SAs expire so that a given flow can continue uninterrupted. This can be seen in Figure 1-19.

Figure 1-19 Tunnel Termination

See the previous blog post which documents the steps to setup AnyConnect SSL-VPN and ISE integration. This blog post expands on the AnyConnect SSL-VPN configuration, adding support for IKEv2/IPSec and using double authentication (Username/Password and Certificate).

ASA Configuration

Create a Crypto Keypair

Create a CA Trustpoint

Authenticate the Trustpoint

In this example the ASA will enrol with a Windows Certificate Authority.

• Open the CA’s Trusted Root certificate in notepad
  
• Copy the contents on the certificate
  
• On the ASA run the command crypto ca authenticate LAB_PKI
  
• When prompted paste the contents of the CA Trusted Root certificate
  
• Type quit at the end
  
• Enter yes to import the certificate
  

EnrolL ASA for Identity Certificate

The ASA will create a CSR, which will need to be signed by the Windows CA and the signed certificate imported.

• On the ASA run the command crypto ca enroll LAB_PKI
  
• When prompted copy the contents of the CSR
  

• Complete the Certificate Signing Request
  
• On the Window CA open the Web page to sign certificates, click Request a certificate
  

• Click advanced certificate request
  

• Paste the CSR generated on the ASA in the previous step above
  
• Select the Certificate Template Web Server
  
• Click Submit
  

• Select Base 64 encoded
  
• Click Download certificate, save the file to a file for use in the next step
  

• On the ASA, run the command crypto ca import LAB_PKI certificate. LAB_PKI equals the name of the trustpoint previously defined.
  
• When prompted paste the contents of the saved file (generated in the previous step)
  

• Type quit at the end
  
• Verify the Identity and Trusted Root Certificates imported successfully by running the command show crypto ca certificates
  
• In the screenshot below the first certificate is the Identity Certificate (note the Subject name of the ASA). The second certificate is the Trusted Root certificate (note the subject name = lab=PKI-CA).
  

Enable the Certificate Trustpoint on the OUTSIDE interface

Enable the Certificate Trustpoint for Remote Access

Define IKEv2 Policy

Define IPSec Transform Sets

Define Crypto Map

Reference the previously created IPSec Transform Sets. Enable Crypto Map on OUTSIDE interface

Modify Group Policy to enable IKEv2

Enable AAA and Certificate authentication

For additional security double authentication will be configured to require certificate and username/password. The certificate will be authenticated against the ASA, the UN/PW will be authenticated against the RADIUS server (defined in the previous post).

Enable AAA accounting (if not already enabled)

AAA accounting should be enabled to keep track of the connections.

ISE Configuration

The ISE Authorization Policy as defined in the previous post needs modifying to add a new rule for clients connecting with IPSec. Using this attribute is optional, but can be used to distinguish between different connections types if required.

• Create a new Authorization rule called AnyConnect IPSec VPN
• Define Conditions: Cisco-VPN3000:CVPN3000/ASA/PIX7x-Tunnel-Group-Name CONTAINS TG-1 AND Cisco-VPN3000:CVPN3000/ASA/PIX7x-Client-Type EQUALS AnyConnect-Client-IPSec-VPN
• Permissions: VPN_Permit_DACL

Testing & Verification

You will need to create a AnyConnect Profile, download the AnyConnect Profile Editor

• Open the VPN Profile Editor
  
• Navigate to the Server List and click Add
  
• Define a display name for the connection e.g ASA IKEv2/IPSec VPN
  
• Define the FQDN
  
• Define the User Group, this represents the Tunnel-Group on the ASA, in this instance the name is TG-1 (as defined in the previous post)
  
• Set the Primary Protocol to IPSec
  

• Click Save and ensure the file is saved to the folder location:
  
  • C:ProgramDataCiscoCisco AnyConnect Secure Mobility ClientProfile
    

• Restart the Cisco AnyConnect services or reboot
• Open the Cisco AnyConnect Secure Mobility Client, this should display the new connection
  

• 
  

The Windows computer has a User and Computer certificate issued by the same Windows CA that signed the certificate in use on the ASA, and therefore they should mutually trust each other and successfully authenticate.

• On the ASA run the command debug aaa authentication
  
• On the PC connect to the VPN and enter and username/password when prompted. Certificate authentication, if successful should be transparent
  

Ipsec Anyconnect Software

From the ASA debugs you can see the certificate authentication was successful

Authentication using Username/Password was also successful. You can see from the debug output aaa authentication was successful, a DACL was downloaded, aaa accounting was successful and the client was successfully assigned an IP address from the local pool.

• On the ASA run the command show vpn-session detail anyconnect
  

You will be able to confirm the Username, Assigned IP address, IKEv2 encryption algorithm used, authentication method, group-policy and tunnel-group etc.