How to: IPsec VPN configuration

A Virtual Private Network (VPN) is an essential technology for securing data that is going over the Internet. By creating a secure tunnel, it ensures data is not exposed to bad actors (hackers, surveillance) over the public network.

Internet Protocol security (IPsec) is a VPN standard that provides Layer 3 security. It’s a suite of protocols that provides confidentiality, integrity and authentication to data.

In this how-to tutorial, we will implement a site-to-site IPsec VPN using Cisco CSR1000V routers. You can follow along using the IPsec Virtual Lab in the APNIC Academy.

This tutorial is divided into two parts, showing the difference in implementation between the two versions of Internet Key Exchange (IKE) — IKEv1 (defined in RFC 2409) and IKEv2 (defined in RFC 4306). IKE is used to establish the IPsec tunnel.

As shown in the topology below (Figure 1), we will setup a VPN between the Internet Service Provider (ISP) and customer networks. This is a simplified topology, but a similar setup can be done between customer networks, for example.

Part 1 – IKEv1

Setting up an IPsec tunnel is a two-phase process.

Phase 1 creates a secure channel and sets up the Internet Security Association and Key Management Protocol (ISAKMP). This is the protocol that provides a consistent framework for transferring key and authentication data. The channel created is used for management purposes — exchange of keys and certifications, and negotiation of parameters, among others.

Phase 2 creates a tunnel over the secure channel and creates IPsec Security Associations (SA). This tunnel is used to transmit data.

1. Create an ISAKMP policy

In Phase 1, both routers must negotiate and agree on a set of parameters, such as the encryption key, hashing algorithm, Diffie-Hellman group, and authentication type.

So, starting with the ISP1 router, create an ISAKMP policy based on the security policy you wish to support. For example, we can have AES encryption, SHA512 hash, DH group 24, and PSK authentication.

 config t
 crypto isakmp policy 1 
 encryption aes
 hash sha512
 group 24
 authentication pre-share 
 exit 

2. Access list

An access list (ACL) contains the interesting traffic that will go through the IPsec tunnel. Create an ACL that allows traffic from Network A (172.16.0.0/20) to Network B (10.0.0.0/24).

 access-list 101 permit ip 172.16.0.0 0.7.255.255 
 10.0.0.0 0.255.255.255 

3. Pre-shared key

Define a pre-shared key that will be used for peer authentication (in step 1). There are two other methods possible here: RSA signature or RSA encrypted nonces.

Here we defined a key ‘Training123’ that will be used to authenticate the remote peer, 172.20.0.2.

 config t 
 crypto isakmp key Training123 address 172.20.0.2 
 Note: The remote peer must be configured to use the same key. 

4. Transform set

IPSec transform sets are exchanged between peers during quick mode in phase 2. A transform set is a combination of algorithms and protocols that endorse a security policy for traffic.

In this config, we have a transform set named ‘ESP-AES-SHA, which supports esp-aes encryption and the esp-sha-hmac hashing algorithm.

 config t 
 crypto ipsec transform-set 'ESP-AES-SHA esp-aes esp-sha-hmac 
 exit  

5. Crypto map

Now, create a crypto map that glues all the policies together. Also, specify the IP address of the remote peer.

 crypto map LAB-VPN 10 ipsec-isakmp
 match address 101
 set transform-set ESP-AES-SHA
 set peer 172.20.0.2
 exit 

6. Apply to the interface

The crypto map created in the previous step will be applied to the interface that our traffic will use. Check the topology diagram to confirm that it’s the link gi6 that connects to R1.

 config t
 int gi6
 crypto map LAB-VPN 
 exit
 exit
 wr 

7. Apply similar steps for the customer router R1

Make sure to use the correct IP address. Here is a complete config for R1.

 ! ISAKMP Policy
 config t
 crypto isakmp policy 1 
 encryption aes
 hash sha512
 group 24
 authentication pre-share 
 exit
 ! ACL
 access-list 101 permit ip 10.0.0.0 0.255.255.255 172.16.0.0 0.7.255.255
 ! PSK
 crypto isakmp key Training123 address 172.20.0.1
 ! Transform Set
 crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac
 ! CRYPTO MAP
 crypto map LAB-VPN 10 ipsec-isakmp
 match address 101
 set transform-set ESP-AES-SHA
 set peer 172.20.0.1
 exit
 ! Apply
 int gi6
 crypto map LAB-VPN 
 exit
 exit
 wr 

8. Verify

Use the following command to verify the configuration:

 show crypto map 
 show crypto ipsec transform-set 

To establish the IPsec tunnel, we must send some interesting traffic over the VPN. From S1, you can send an ICMP packet to H1 (and vice versa).

 ping 10.0.0.1 

After this, ISP1 (initiator) will send a message to R1 (responder) and they will exchange messages to negotiate the parameters to set up the tunnel. To verify that the VPN tunnel has been created, there must be an ISAKMP SA (for phase 1) and an IPSEC SA (for phase 2).

Check that the ISAKMP tunnel (phase 1) has been created:

 show crypto isakmp sa
 The output from R1 should be as follows:
 IPv4 Crypto ISAKMP SA
 dst             src             state       conn-id status
 172.20.0.1      172.20.0.2      QM_IDLE     1001    ACTIVE

Check the IPsec tunnel (phase 2) has been created. Confirm that it has created an inbound and an outbound esp SA:

 show crypto ipsec sa 

At this stage, we now have an IPsec VPN tunnel using IKEv1. If you have a packet sniffer, such as Wireshark, you can run it to verify that traffic is indeed encrypted.

If you have issues and the tunnel is not created, use the following debug commands:

 debug crypto isakmp
 debug crypto ipsec 

You should see ‘atts are not acceptable’ message if the two routers have not agreed on the parameters.

Part 2 – IKEv2

IKEv2 is a massive improvement to IKEv1. It aimed to simplify the exchanges to establish the tunnel. These two exchanges are IKE_SA_INIT and IKE_AUTH with a minimum of four messages.

1. Keyring

Let’s first configure the ISP1 router. Create a keyring that defines the pre-shared key used for connections with the remote peer:

 config t 
 crypto ikev2 keyring KEYRING-1 
 peer REMOTE-NW 
 address 172.20.0.2 
 pre-shared-key Tr@ining 
 exit 

2. IKEv2 proposal

The IKEv2 proposal defines parameters that will be used for negotiating the IKE SAs in the IKE_SA_INIT exchange. There’s also a default proposal already defined:

 crypto ikev2 proposal PROPOSAL-1
 encryption aes-cbc-256
 integrity sha512
 prf sha512
 group 24 

3. IKEv2 policy

Next we define the IKEv2 policy by attaching the proposal created in the previous step. There’s also a default policy that allows the matching of the address to any:

 crypto ikev2 policy POLICY-1
 proposal PROPOSAL-1 

4. Transform set

This step is similar to Part 1:

 crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha512-hmac 

5. Access list

Define an ACL that will use the tunnel, similar to Part 1:

 access-list 101 permit ip 172.16.0.0 0.7.255.255 10.0.0.0 0.255.255.255 

6. Define an IKEv2 profile

 crypto ikev2 profile PROFILE-1
 match identity remote address 172.20.0.2
 identity local address 172.20.0.1
 authentication local pre-share
 authentication remote pre-share
 keyring local KEYRING-1 

7. Define the crypto map and attach the profile

 crypto map LAB-VPN-2 10 ipsec-isakmp
 set peer 172.20.0.2
 set pfs group24
 set security-association lifetime seconds 3600
 set transform-set ESP-AES-SHA
 set ikev2-profile PROFILE-1
 match address 101

Another option is to create an IPsec profile, then create a tunnel interface that will use this profile This is not done here for simplicity in implementing with the virtual lab topology.

8. Apply the crypto map

 config t
 int gi6
 no crypto map LAB-VPN
 crypto map LAB-VPN-2
 exit
 exit
 wr 

9. Configure the customer router R1

Apply steps 1 to 8 to the customer router (R1). Make sure to use the correct local and remote IP as well as the ACL.

 access-list 101 permit ip 10.0.0.0 0.255.255.255 172.16.0.0 0.7.255.255 

Verification

Check that the policies we defined have been applied:

 show crypto ikev2 proposal
 show crypto ikev2 profile
 show crypto ikev2 policy
 Enable debugging:
 debug crypto ikev2 packet
 debug crypto ikev2 internal

Check that the tunnel has been created:

 show crypto ikev2 sa detailed 
 show crypto ipsec sa 

And check that the tunnel session status is ‘UP-ACTIVE’:

 sh crypto session

The output for R1 should be like this:

 Interface: GigabitEthernet6
 Profile: PROFILE-1
 Session status: UP-ACTIVE
 Peer: 172.20.0.1 port 500
             Session ID: 3
             IKEv2 SA: local 172.20.0.2/500 remote 172.20.0.1/500 Active
             IPSEC FLOW: permit ip 10.0.0.0/255.0.0.0 172.16.0.0/255.248.0.0 
                         Active SAs: 2, origin: crypto map 

That’s it! You have now successfully configured an IPsec VPN Tunnel. To learn more about IPsec, please watch our latest webinar.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.