IPSec VPN on Cisco ASA using CLI

Cisco is, in my opinion, the most flexible and scalable VPN solution on the market today.  I have used Cisco ASA for site-to-site VPNs for years and have had over 1200 VPN tunnels on a single set of firewalls.  The beauty comes in the ability to define Phase I and II (explained later) specifically for each tunnel.  Some firewalls (e.g. Checkpoint) have a global ‘Encryption Domain’ which is used in Phase II.  This creates issues when you have a single VPN you want to exchange only two hosts with and a second tunnel allowing your entire network (e.g. backup link).

There are a few pieces to a Cisco site-to-site VPN.  In this blog post, I will focus on IKEv1 and will follow up with an IKEv2 blog post in the near future.  Lets start with the basics.

CIA Triad

In information security, we have a model known as CIA Triad.  CIA stands for Confidentiality, Integrity and Availability.  This is the model by which Information Security has been tested and compared to for many years.  In most cases, it is sufficient.

Confidentiality – Protects data from getting in the hands of the wrong people

Integrity – Maintains the consistency & accuracy of the data over its life cycle.

Availability – Safeguards against data loss or interruptions in connections

A VPN allows you to conform to the CIA Triad by providing all three of the components of the CIA Triad.

—————————————————————————

What makes up a VPN

The ASA will require a few pieces which are access control list to match traffic as ‘interesting’, a NAT or non-NAT, IKEv1 Policy, IPSec Transform set, a crypto-map and lastly a tunnel group. I will discuss each of these pieces later in this post.

—————————————————————————

PHASES

The IPSec Site-to-Site VPN is divided into two phases, surprisingly named Phase I and Phase II (very original).

Phase I – defines defines the the peer information (the IP address of the remote VPN device) and sets up a secure channel to pass the encrypted traffic.  Phase I uses a symmetric key as it is the most efficient, but less secure as the keys need to be exchanged via other means prior to the VPN establishing.

Phase II – Defines what IP addresses will be exchanged.

—————————————————————————

PHASE I

Cisco’s ASA uses the following two components to define Phase I specifics; Tunnel Groups and IKEv1 Policy.  Here is an example.

Tunnel Group

tunnel-group <REMOTE-PEER-IP> type ipsec-l2l
tunnel-group <REMOTE-PEER-IP> general-attributes
default-group-policy <GP-NAME>
tunnel-group <REMOTE-PEER-IP> ipsec-attributes
ikev1 pre-shared-key <PRE-SHARED-KEY> / trust-point <TRUST-POINT> 

IKEv1 Policy

crypto ikev1 policy <sequence#>
authentication pre-share / rsa-sig
encryption aes-256 / 3DES #I recommend only using AES-256
hash sha/md5
group 1/2/5 #7 has been deprecated 
lifetime 86400

In the tunnel-group section, you define either the pre-shared key or trust-point containing the certificate for authentication.  Although I have used certificates for site-to-site VPNs, 99% of the time, it is via pre-shared key.  If using ‘pre-shared key’ ensure you are using a good password that meets security standards. I use ‘pwgen’ to generate passwords

Mannys-MacBook-Pro:~ mannyfernandez$ pwgen 23 1 -Bync
hi4ee9iiM4ji@gohR%ohshi

NOTE: Do not use ‘?’ in your password as it will cause the ASA to show the context help.

I try to use a minimum of 23 characters.    I also do not recommend using 3DES and certainly not DES for VPNs.  I try to use AES-256 if at all possible.  Some countries are restricted in the encryption scheme they are allowed to use.  Make sure you research that if you are doing VPNs outside the US.  If you use the ASDM and use the wizard, it will automatically add a bunch of insecure ikev1 policies including DES and MD5 for hashing.  The sequence number defines the order the remote peer will see.  If you have all the encryptions enabled, the remote peer will cycle through their configuration and it will match the first available.  I have seen where both firewalls inadvertently have DES on their configuration and they use DES instead of the higher secure schemes.

—————————————————————————

PHASE II

Phase II is defined using the following components: ipsec transform-set, access-list and crypto-map

Access-List 

In the access-list, you define it using ‘permit ip’.  Do not try to use the access-list to permit/deny traffic.  This access-list is used to match interesting traffic only.  One thing I recommend is to create object/object-groups using the following format:

vpnname-local – In this object or object-group, you define the IP addresses or networks you want to present to the remote VPN.  This is useful because if you use a 10.1.1.0/24 as a ‘local-lans’ lets say in all of your VPNs and you want to add an additional subnet to this one VPN tunnel, it will affect all VPN tunnels.  However if you use a ‘local’ object per VPN tunnel, you can be surgical on the IP address you want to use for Phase II.

vpnname-remote – In this object or object-group, you define the IP addresses or networks you are expecting to see from the remote side.

I also name my access-list ‘crypto-to-<remote-vpn-name>’ this is much more descriptive than what is created by the ASDM wizard.

access-list crypto-to-infosecmonkey permit ip object secprimate-local object secprimate-remote 

object network secprimate-local
subnet 10.100.1.0 255.255.255.0

object network secprimate-remote
subnet 192.168.1.0 255.255.255.0

In the example above, my local IP address is 10.100.1.0/24 and the remote side is 192.168.1.0/24

IPSec Transform-set

crypto ipsec ikev1 transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac

The transform-set defines the phase II encryption scheme to use as well as the hashing algorithm.

Authentication Header (AH): This authenticates the sender and it discovers any changes in data during transmission; incompatible with NAT.Encapsulating

Security Payload (ESP): This not only performs authentication for the sender but also encrypts the data being sent (confidentiality).

NOTE: AH is not recommended as it does not provide encryption.

In the example above, the section in caps is the name.  It can be anything you want although I like to use what defines the transform-set in the name to ensure I can easy spot issues:  crypto ipsec ikev1 transform-set <NAME> esp-aes-256 esp-sha-hmac

Now is the crypto-map section.  This is what ties all of the phase II pieces together.

crypto map <crypto-map name> <seq num> match address <ACCESS-LIST NAME>
crypto map <crypto-map name> <seq num> set pfs <GROUP> #If used
crypto map <crypto-map name> <seq num> set peer <IP-ADDRESS of PEER>
crypto map <crypto-map name> <seq num> set ikev1 transform-set <TRANSFORM-SET NAME>

PFS

If you enable Perfect Forward Secrecy (PFS) mode, new session keys are not derived from previously used session keys. Therefore, if a key is compromised, that compromised key will not affect any previous session keys.  I recommend using PFS.  It adds a bit of overhead but the security benefits with worth the tradeoff.

—————————————————————————

DH Groups

group1 : 768-bit Diffie Hellman prime modulus group.
group2: 1024-bit Diffie Hellman prime modulus group.
group5: 1536-bit Diffie Hellman prime modulus group.
group14: 2048-bit Diffie Hellman prime modulus group.
group19: 256-bit random Diffie Hellman ECP modulus group. (For IKEv2 only)
group20: 384-bit random Diffie Hellman ECP modulus group. (For IKEv2 only)

—————————————————————————

To NAT or NOT to NAT…. That is the question

In VPNs, a majority of the time it involved not performing NAT inside the VPN.  This is not always the case.  For instance in our managed services, we use the public IP in the VPN to ensure we do not have IP overlap.

nat (inside,outside) source static secprimate-local secprimate-local destination static secprimate-remote secprimate-remote

Make sure you are mindful of the order of the NAT statement.  If it is too high and after a PAT or NAT overload, it will never match this rule.  If you need to add it above a PAT, use the line number option right after the ().  It is just a single number (no ‘line’ statement) see below.

nat (inside,outside) 1 source static secprimate-local secprimate-local destination static secprimate-remote secprimate-remote

Message IDs

During the process of the VPN establishing, you sometimes get error messages and it is important to understand what they mean.  I got this information from another blog

MM_WAIT_MSG2 Initiator Initial DH public key sent to responder. Awaiting initial contact reply from other side. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. If stuck here it usually means the other end is not responding. This could be due to no route to the far end or the far end does not have ISAKMP enabled on the outside or the far end is down

MM_WAIT_MSG3 Receiver Receiver is sending back its IKE policy to the initiator. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. Hang ups here may also be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.

MM_WAIT_MSG4 Initiator Initiator is sending the Pre-Shared-Key hash to its peer. Initiator sends a hash of its PSK. Initiator will stay at MSG4 until it gets a PSK back from its peer. If the receiver is missing a tunnel group or PSK the initiator will stay at MM_WAIT_MSG4

MM_WAIT_MSG5 Receiver Receiver is sending its PSK hash to its peer. Receiver does not yet check if PSK hashes match. If receiver has a tunnel-group and PSK configured for this peer it will send the PSK hash to the peer. If PSKs dont match, receiver will stay at MM_WAIT_MSG5. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off.

MM_WAIT_MSG6 Initiator Initiator checks if PSK hashes match. If PSK keys match, Initiator becomes MM_ACTIVE and lets receiver know of match. If PSK doesn t match, initiator stays at MM_WAIT_MSG6. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off. However, if the state goes to MSG6 then the ISAKMP gets reset that means phase 1 finished but phase 2 failed. Check that IPSEC settings match in phase 2 to get the tunnel to stay at MM_ACTIVE.

AM_ACTIVE / MM_ACTIVE The ISAKMP negotiations are complete. Phase 1 has successfully completed

—————————————————————————

IKEv1 ISAKMP States

When troubleshooting the VPN connections, one of the commands used to identify and validate connectivity is ‘sh cry isa sa’ this will give you the state of the VPN.  The following is a list of these states.  The one you are looking to be at is ‘QM_IDLE’.  This state tells you all is well and you can go have a beer.

AM_ACTIVE / MM_ACTIVE The ISAKMP negotiations are complete. Phase 1 has successfully completed
MM_NO_STATE – ISAKMP SA has been created but nothing else has happened yet.
MM_SA_SETUP – The peers have agreed on parameters for the ISAKMP SA.
MM_KEY_EXCH – The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The I SAKMP SA remains unauthenticated.
MM_KEY_AUTH – The ISAKMP SA has been authenticated. If the router initiated this exchange, this state trans itions immediately to QM_IDLE and a Quick mode exchange begins.
AG_NO_STATE – The ISAKMP SA has been created but nothing else has happened yet.
AG_INIT_EXCH – The peers have done the first exchange in Aggressive mode but the SA is not authenticated.
AG_AUTH – The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to QM_IDLE and a Quick mode exchange begins.
QM_IDLE – The ISAKMP negotiations are complete. Phase 1 successfully completed. It remains authenticated with its peer and may be used for subsequent Quick mode exchanges.

—————————————————————————

Example:

Local Peer IP: 1.1.1.1
Local PII IP: 10.100.1.0 255.255.255.0

Remote Peer IP: 2.2.2.2
Local PII IP: 192.168.1.0 255.255.255.0

** LOCAL FIREWALL **

crypto ikev1 policy 10
authentication pre-share
encryption aes-256
hash sha
group 5
lifetime 86400

!
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 general-attributes
tunnel-group 2.2.2.2 ipsec-attributes
ikev1 pre-shared-key hi4ee9iiM4ji@gohR%ohshi
!
object network secprimate-local
subnet 10.100.1.0 255.255.255.0
!
object network secprimate-remote
subnet 192.168.1.0 255.255.255.0
!
access-list crypto-to-infosecmonkey permit ip object secprimate-local object secprimate-remote
!
crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
!
crypto map outside-map 10 match address crypto-to-infosecmonkey
crypto map outside-map 10 set pfs 2 
crypto map outside-map 10 set peer 2.2.2.2
crypto map outside-map 10 set ikev1 transform-set ESP-AES-256-SHA

** REMOTE FIREWALL **

crypto ikev1 policy 10
authentication pre-share
encryption aes-256
hash sha
group 5
lifetime 86400
!
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 general-attributes
tunnel-group 1.1.1.1 ipsec-attributes
ikev1 pre-shared-key hi4ee9iiM4ji@gohR%ohshi
!
object network manny-local
subnet 10.100.1.0 255.255.255.0
!
object network manny-remote
subnet 192.168.1.0 255.255.255.0
!
access-list crypto-to-manny permit ip object secprimate-local object secprimate-remote
!
crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
!
crypto map outside-map 10 match address crypto-to-manny
crypto map outside-map 10 set pfs 2
crypto map outside-map 10 set peer 1.1.1.1
crypto map outside-map 10 set ikev1 transform-set ESP-AES-256-SHA