Configuring IKEv1 IPSec site-to-site VPN with preshared-keys on Cisco ASA

Rate this post

252 views

cisco

Overview

Many companies have multiple remote offices which need secure network connectivity with the headquarters or between them. This can be achieved by using a site-to-site VPN setup which allows offices in multiple fixed locations to establish secure connections and share resources with each other over a public network such as the Internet. Cisco ASA supports the IPsec protocol for configuring an site-to-site VPN tunnel. IPsec works by authenticating and encrypting each IP packet of a communication session and uses the Internet Key Exchange (IKE) protocol to negotiate and establish a secure VPN tunnel. The original IKE version 1 is defined in RFC 2409 and the IKE version 2 (IKEv2) is defined in RFC 5996. Cisco introduced support for IKEv2 beginning with ASA version 8.4 but in this article we will focus only on the legacy IKEv1 implementation.

IPSec concepts

The main goal of IPSec is to provide confidentiality, integrity, authentication and antireplay protection. Let’s explain each of these goals:

  • Confidentiality – is referring to data encryption. This means that the data should be available only to the intended recipient.
  • Integrity – ensures that transmitted data must not be altered during its transit from sender to the destination. IPSec provides data integrity by using hashing mechanisms.
  • Authentication – both VPN peers must prove their identity with each other. This ensures that information is originating from a valid source. IPSec provides data authentication through the use of pre-shared keys or digital signatures.
  • Antireplay protection – provides protection against an attacker duplicating encrypted packets by assigning a unique sequence number to each encrypted packet. By using this sequence numbers, IPSec can identify the packets which it has already seen.

IPSec implements these goals using two mechanisms ESP (Encapsulating Security Payload) or AH (Authentication Header). These mechanisms can be used individually or together. The main difference between AH and ESP is that AH does not provide data encryption only authentication and data integrity. ESP is defined in RFC 4303 and uses a symmetric key encryption meaning that the same key is used for both the encryption as well as decryption.

IPSec can use two different modes to establish a secure communication channel between peers – Tunnel mode and Transport mode. Use of each mode depends on the requirements and implementation of IPSec.

  • Tunnel mode – protects the entire original IP packet. The packet is then encapsulated by the IPsec headers and trailers. In tunnel mode a new IP header is added to the existing IP packet containing the source and destination IP addresses of the IPSec endpoints. Tunnel mode is most commonly used between gateways (routers or firewalls).
  • Transport mode – protects only the payload or data of the original IP packet. The protected payload is then encapsulated by the IPsec headers and trailers. The original IP header remains intact meaning that the source and destination IP addresses are the actual endpoints. Transport mode is used for communication between end devices like a client and a server.

Topology overview

For the purpose or our configuration I’ll use the following topology listed below. Let’s assume we have a small company with two branches called are SITE-A and SITE-B. Each of the sites will use a private subnet for their internal network 192.168.10.0/24 for SITE-A and 192.168.20.0/24 for SITE-B. The VPN tunnel will be established between the outside interfaces (Gi0/0) of SITE-A (99.99.99.2/24) and (Gi0/0) of SITE-B (123.123.123.2/24) firewalls. Our final goal will be to allow secure communication between host PC-1 on SITE-A and host PC-2 on SITE-B. For the INTERNET cloud I’ll use a router which will simulate the ISP to allow reachability between the outside interface of the two ASA firewalls.

IPSec

Below I have listed the IP configuration of both ASA firewalls:

SITE-A# sh ip address 
Current IP Addresses:
Interface                Name                   IP address      Subnet mask     Method 
GigabitEthernet0/0       outside                99.99.99.2      255.255.255.252 manual
GigabitEthernet0/1       inside                 192.168.10.1    255.255.255.0   manual
SITE-B# sh ip address 
Current IP Addresses:
Interface                Name                   IP address      Subnet mask     Method 
GigabitEthernet0/0       outside                123.123.123.2   255.255.255.252 manual
GigabitEthernet0/1       inside                 192.168.20.1    255.255.255.0   manual

Each of the ASA VPN gateways will have a default route pointing to the neigbor IP address on the INTERNET router listed below.

SITE-A(config)# route outside 0.0.0.0 0.0.0.0 99.99.99.1
SITE-B(config)# route outside 0.0.0.0 0.0.0.0 123.123.123.1

The INTERNET router has the following IP configuration:

Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         99.99.99.1      YES manual up                    up      
GigabitEthernet0/1         123.123.123.1   YES manual up                    up

Now the basic configuration is complete so let’s proceed with setting up the phase 1 configuration.

IKEv1 phase 1 configuration

The main purpose of IKEv1 phase 1 is to set up a secure communication channel between the peers and to negotiate the parameters and key material required to establish an IKEv1 Security Association (SA). IKEv1 Phase 1 negotiation can operate either in main mode or aggressive mode with the main mode being the default. First we must configure the IKEv1 policy which must match the policy configured on the other peer. When we define the IKEv1 policy we need to specify the following attributes:

  • Encryption – specifies the symmetric encryption algorithm that protects data transmitted between two IPsec peers.
  • DH group – specifies the Diffie-Hellman group identifier, which the two IPsec peers use to derive a shared secret without transmitting it to each other.
  • Integrity hash – specifies the hash algorithm used to ensure data integrity.
  • Authentication – specifies the authentication method the ASA uses to establish the identity of each IPsec peer.
  • Lifetime – specifies the SA lifetime. The default is 86,400 seconds or 24 hours.

Let’s pick some values for these policy attributes. If a value for a given policy parameter is not specified, the default value is applied. Below is the policy configuration for SITE-A. The same configuration needs to be applied on SITE-B also.

SITE-A(config)# crypto ikev1 policy 10
SITE-A(config-ikev1-policy)# authentication pre-share
SITE-A(config-ikev1-policy)# encryption aes
SITE-A(config-ikev1-policy)# hash sha
SITE-A(config-ikev1-policy)# group 5
SITE-A(config-ikev1-policy)# lifetime 86400

Next let’s enable ISAKMP IKEv1 negotiation on the interface on which the IPsec peer communicates with the ASA, typically the outside interface. If ISAKMP is not enabled on the outside interface, the security appliance will not respond to a tunnel initialization request.

SITE-A(config)# crypto ikev1 enable outside

Then we need to configure a tunnel-group which is used to define the type of VPN connection and the IPSec attributes in our case the peer IP address and the tunnel pre-shared key.

SITE-A(config)# tunnel-group 123.123.123.2 type ipsec-l2l
SITE-A(config)# tunnel-group 123.123.123.2 ipsec-attributes
SITE-A(config-tunnel-ipsec)# ikev1 pre-shared-key C!sc0S3cret
SITE-B(config)# tunnel-group 99.99.99.2 type ipsec-l2l
SITE-B(config)# tunnel-group 99.99.99.2 ipsec-attributes
SITE-B(config-tunnel-ipsec)# ikev1 pre-shared-key C!sc0S3cret

The same preshared key needs to be used on both ASAs for this LAN-to-LAN connection. IKEv1 phase 1 is complete now so let’s proceed with the phase 2 configuration.

IPSec phase 2 configuration

The main purpose of IKE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel. IKE phase 2 has one mode, called quick mode which occurs after IKE has established the secure tunnel in phase 1. It negotiates a shared IPSec policy, derives shared secret keying material used for the IPSec security algorithms, and establishes IPSec SAs. First let’s create the access list (ACL) that defines the traffic that needs to be encrypted and passed through the tunnel. The ACL will use objects so we need to define two objects, one for the local subnet on SITE-A and one for remote subnet on SITE-B.

SITE-A(config)# object network LOCAL-LAN
SITE-A(config-network-object)# subnet 192.168.10.0 255.255.255.0
SITE-A(config)# object network REMOTE-LAN
SITE-A(config-network-object)# subnet 192.168.20.0 255.255.255.0

In our setup the ACL will allow traffic between inside subnets of SITE-A and SITE-B.

SITE-A(config)# access-list 101 extended permit ip object LOCAL-LAN object REMOTE-LAN

The objects and the ACL need to be mirrored also on SITE-B but reversing the source and destination subnet for the LOCAL-LAN and REMOTE-LAN.

SITE-B(config)# object network LOCAL-LAN
SITE-B(config-network-object)# subnet 192.168.20.0 255.255.255.0
SITE-B(config)# object network REMOTE-LAN
SITE-B(config-network-object)# subnet 192.168.10.0 255.255.255.0
SITE-B(config)# access-list 101 extended permit ip object LOCAL-LAN object REMOTE-LAN

Next we need to configure a transform-set which is combination of security protocols and algorithms that define how the ASA protects data. During IPsec SA negotiations, the peers must identify a transform set or proposal that is the same at both peers. In our case we will configure a transform-set called TFS which will use AES 256-bit for encryption and SHA for authentication.

SITE-A(config)# crypto ipsec ikev1 transform-set TFS esp-aes-256 esp-sha-hmac

SITE-B(config)# crypto ipsec ikev1 transform-set TFS esp-aes-256 esp-sha-hmac

The next step is to configure the crypto map, which defines the IPsec policy to be negotiated in the IPsec SA. A valid crypto map should include the following components: the peer IP address, the transform-set and the ACL used to define interesting traffic. Optionally we can enable Perfect Forward Secrecy (PFS) setting, which creates a new pair of Diffie-Hellman keys that are used in order to protect the data. Below is the crypto map configuration for SITE-A.

SITE-A(config)# crypto map CMAP 10 match address 101
SITE-A(config)# crypto map CMAP 10 set peer 123.123.123.2
SITE-A(config)# crypto map CMAP 10 set ikev1 transform-set TFS
SITE-A(config)# crypto map CMAP 10 set pfs

A similar crypto map configuration needs to be applied also on SITE-B.

SITE-A(config)# crypto map CMAP 10 match address 101
SITE-B(config)# crypto map CMAP 10 set peer 99.99.99.2 
SITE-B(config)# crypto map CMAP 10 set ikev1 transform-set TFS
SITE-B(config)# crypto map CMAP 10 set pfs

Now that the crypto map have been configured we need to apply it on the outside interface on both ends of the IPsec tunnel.

SITE-A(config)# crypto map CMAP interface outside

SITE-B(config)# crypto map CMAP interface outside

Since we have configured NAT for the internal subnets on both sites we need to perform NAT exemption in order to bypass address translation for traffic destined over the VPN tunnels. This can be done using one identity NAT rule on each side which tells us that traffic from LOCAL-LAN should be passed untranslated to the REMOTE-LAN. Below is the identity NAT configuration on both peers.

SITE-A(config)# nat (inside,outside) 1 source static LOCAL-LAN LOCAL-LAN destination static REMOTE-LAN REMOTE-LAN no-proxy-arp route-lookup

SITE-B(config)# nat (inside,outside) 1 source static LOCAL-LAN LOCAL-LAN destination static REMOTE-LAN REMOTE-LAN no-proxy-arp route-lookup

Finally IPsec phase 2 configuration is completed and we can proceed to verify if our configuration works properly.

Verifying and troubleshooting

By default the tunnel connection is established on-demand the so we need to send some traffic through the IPsec tunnel in order to bring it up. Let’s try to ping from host PC-1 on SITE-A to host PC-2 on SITE-B.

root@PC-1:~# ping -c 3 192.168.20.50
PING 192.168.20.50 (192.168.20.50) 56(84) bytes of data.
64 bytes from 192.168.20.50: icmp_seq=1 ttl=62 time=6.93 ms
64 bytes from 192.168.20.50: icmp_seq=2 ttl=62 time=5.90 ms
64 bytes from 192.168.20.50: icmp_seq=3 ttl=62 time=6.08 ms

--- 192.168.20.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 5.904/6.307/6.931/0.451 ms

As we can see we have received a reply from PC-2 which means that the IPsec tunnel has been successfully established. Let check the operational status of ISAKMP phase 1.

SITE-A# show crypto isakmp sa 

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 123.123.123.2
    Type    : L2L             Role    : initiator 
    Rekey   : no              State   : MM_ACTIVE

By looking at the output of the show crypto isakmp sa command we can observe that state is MM_ACTIVE which means that phase 1 has completed successfully. Also we can see that the ASA device located on SITE-A has the role of the initiator for the tunnel while the other end on SITE-B has the responder role. Next let’s check the status of IPsec phase 2.

SITE-A# show crypto ipsec sa
interface: outside
    Crypto map tag: CMAP, seq num: 10, local addr: 99.99.99.2

      access-list 101 extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0 
      local ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)
      current_peer: 123.123.123.2


      #pkts encaps: 113, #pkts encrypt: 113, #pkts digest: 113
      #pkts decaps: 113, #pkts decrypt: 113, #pkts verify: 113
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 113, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 99.99.99.2/0, remote crypto endpt.: 123.123.123.2/0
      path mtu 1500, ipsec overhead 74(44), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: C2216DC4
      current inbound spi : AD113868

    inbound esp sas:
      spi: 0xAD113868 (2903586920)
         transform: esp-aes-256 esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 12288, crypto-map: CMAP
         sa timing: remaining key lifetime (kB/sec): (3914990/28779)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0xC2216DC4 (3256970692)
         transform: esp-aes-256 esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 12288, crypto-map: CMAP
         sa timing: remaining key lifetime (kB/sec): (3914990/28779)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x00000001

To better understand the output of phase 2 I have highligted in red some of the important sections. We can see that the encrypted tunnel is built between 99.99.99.2 and 123.123.123.2 which are the outside interfaces on both ASAs devices. By looking at the “pkts encaps” and “pkts encaps” lines we can see that traffic is encrypted and decrypted successfully between the two peers (113 packets were send and received). Also we can see the ACL 101 which is used for NAT exemption and allows the protected traffic to go between internal networks 192.168.10.0 and 192.168.20.0.

Another useful command which displays the status of both IKEv1 phase 1 and IPsec phase 2 is show vpn-sessiondb detail l2l

SITE-A# show vpn-sessiondb detail l2l 

Session Type: LAN-to-LAN Detailed

Connection   : 123.123.123.2
Index        : 4                      IP Addr      : 123.123.123.2
Protocol     : IKEv1 IPsec
Encryption   : IKEv1: (1)AES128  IPsec: (1)AES256
Hashing      : IKEv1: (1)SHA1  IPsec: (1)SHA1
Bytes Tx     : 1680                   Bytes Rx     : 1680
Login Time   : 18:47:46 UTC Mon Feb 12 2018
Duration     : 0h:03m:54s

IKEv1 Tunnels: 1
IPsec Tunnels: 1

IKEv1:
  Tunnel ID    : 4.1
  UDP Src Port : 500                    UDP Dst Port : 500
  IKE Neg Mode : Main                   Auth Mode    : preSharedKeys
  Encryption   : AES128                 Hashing      : SHA1
  Rekey Int (T): 86400 Seconds          Rekey Left(T): 86166 Seconds
  D/H Group    : 5
  Filter Name  : 

IPsec:        
  Tunnel ID    : 4.2
  Local Addr   : 192.168.10.0/255.255.255.0/0/0
  Remote Addr  : 192.168.20.0/255.255.255.0/0/0
  Encryption   : AES256                 Hashing      : SHA1                   
  Encapsulation: Tunnel                 PFS Group    : 2                      
  Rekey Int (T): 28800 Seconds          Rekey Left(T): 28566 Seconds          
  Rekey Int (D): 4608000 K-Bytes        Rekey Left(D): 4607999 K-Bytes        
  Idle Time Out: 30 Minutes             Idle TO Left : 26 Minutes             
  Bytes Tx     : 1680                   Bytes Rx     : 1680                   
  Pkts Tx      : 20                     Pkts Rx      : 20

Here we can see the uptime of the tunnel and how much traffic was sent back and forth, the values for the IKEv1 policy which were negociated between both peers, the local and remote protected networks, the encapsulation mode and the IPsec transform-set parameters. Cisco ASA also provide some useful debug commands to troubleshoot IPSec IKEv1 tunnel negotiation like: debug crypto ikev1 and debug crypto ipsec.

Conclusion

In this article we have provided an basic introduction of how to setup and IPsec site-to-site VPN between two ASA devices. Traditional site-to-site VPN solutions are not very scalable for large enterprises because it requires a huge amount of configuration to setup static IPsec tunnels for all individual locations. To overcome this issue Cisco has developed dynamic VPN solutions like DMVPN and GETVPN which offer more scalability with less configuration.

Leave a Reply

Your email address will not be published. Required fields are marked *