It is my assumption that many of you are already familiar with the concept of Virtual Private Networks (VPNs) in general and even with the configuration of VPNs on several devices like the Cisco IOS devices. The aim of this series is to take that knowledge further by focusing on VPNs on the Cisco ASA. The Adaptive Security Appliance is the ‘all-in-one’ security box from Cisco that includes support for basic packet filtering, stateful packet filtering, NAT, VPNs, and so on.
Several articles have been written about the Cisco ASA on this site. You can view some of them here. Also, like I mentioned above, this series is going to take the approach that you are already familiar with, the basics of VPNs. If not, please refer to this article.
In this series, we will configure several VPN types that the ASA supports including LAN-to-LAN VPNs and Remote-access VPNs (like EasyVPN, Clientless VPN and SSL VPN). As we will see later on, the process to configure VPNs on the ASA is similar to the Cisco IOS devices including configuring IKE Phase 1 and Phase 2 parameters, crypto maps and applying these crypto maps to interfaces. However, there are some differences and add-ons on the Cisco ASA like tunnel groups and group policies’ configuration. We will look at all these in detail as we progress and also view the debug outputs when establishing (or troubleshooting) VPN sessions, as they can tell us a lot about how things are done. Now let’s begin.
The first thing you want to ensure is that your Cisco ASA has the correct licensing to support VPN. You can find general ASA licensing information including VPN licenses here. To check your license, you must issue the show version command on the ASA. A snippet of the show version command detailing license features is shown below:
Now, let’s look at the different sections we need to be familiar with to configure VPNs on the ASA.
IKE Phase 1
Think of IKE Phase 1 like “the tunnel that is used to protect the actual tunnel that will carry traffic“. This is where we define our ISAKMP policies for authentication, encryption, lifetime, Diffie-Hellman group and hash algorithm.
The crypto command is the main command used for configuring VPNs in general. If you used pre-8.4 ASA software version, the crypto command options may look strange to you as shown below:
This is because before this version, we defined ISAKMP Phase 1 policies using the crypto isakmp policy command. This command is now obsolete, as you can see below, that “policy” is not included in the isakmpoptions below:
However, if you go ahead and type the old command (crypto isakmp policy), it will still be accepted but the ASA will automatically change it and place you in the IKEv1 configuration mode.
The reason for this change is because starting from software version 8.4, the Cisco ASAsupports IKEv2. IKEv2 is considered to be a better alternative to IKEv1 and it replaces IKEv1. For a discussion about the benefits of IKEv2 over IKEv1, see here. In later articles, we will configure VPN tunnels using both IKEv1 and IKEv2 and see the difference. Note that IKEv2 is not interoperable with IKEv1; this means one VPN peer cannot use IKEv2 and the other use IKEv1.
Now let’s look at the options for configuring ISAKMP Phase 1 policies. IKEv1 configuration options are shown first:
The output above is similar to what we have on the Cisco IOS and pre-8.4 ASA software version. Now let’s look at options for IKEv2.
Some things to take note of from the output above: “hash” has been renamed to “integrity”; also, the “authentication” option is missing. Another thing which is not visible in this output is that you can configure multiple encryption, DH group, integrity, and PRF algorithms in one policy, unlike with IKEv1. An example is shown below:
The ASA will order those settings from the most secure to the least secure and negotiate the tunnel with the peer using that order. This is evident when you look at the running configuration.
IKE Phase 2
The IKE Phase 2 tunnel is the tunnel that actually protects the “interesting traffic”. This is where we configure our transform set. Again, this command has changed and supports both IKEv1 and IKEv2.
Note: Be careful not to confuse IKE Phase 2 with IKEv2: IKE has two phases – phase 1 and phase 2 – whetherIKEv1 or IKEv2.
Let’s look at both of them. IKEv1 first (which should be familiar):
Now let’s look at IKEv2:
Even with the sharp change in the configuration, the understanding is still the same. A sample configuration is shown below.
You will also see here that we can specify more than one algorithm for encryption and integrity and the ASA will again order it from the most secure to the least secure.
According to Cisco, crypto maps “provide two functions: (1) filtering and classifying traffic to be protected and (2) defining the policy to be applied to that traffic.” We use crypto maps to tie our configuration together and attach this crypto map to an interface. Keep in mind that only one crypto map set can be applied to an interface, so if you want multiple crypto maps, you can use sequence numbers (just like an ACL).
You can use the “match” option to specify the ACL that identifies the “interesting traffic”. The options that can be configured using the “set” command are shown below.
If using IKEv1, we set the transform set using the ikev1 option; we set the ipsec-proposal using the ikev2 option if using IKEv2.
Tunnel groups, also called connection profiles, specify the policies that will be applied to a tunnel such as the pre-shared keys to be used, and the default group policy that will apply to the tunnel. Tunnel groups are defined for the different types of VPN that the ASA supports – site-to-site and remote access VPN.
Once you have defined the tunnel type, you can then specify other settings like general settings, webvpn settings and so on.
There are some default tunnel groups on the ASA which do not show up on the normal running/startup configuration; however, you can view them by using the show run all command. A snippet of running this command is shown below:
There are 3 default tunnel groups: DefaultL2LGroup for LAN-to-LAN connections, DefaultRAgroup for remote access connections and DefaultWEBVPNGroup for SSL VPN connections.
According to Cisco, “a group policy is a set of user-oriented attribute/value pairs for IPsec connections that are stored either internally (locally) on the device or externally on a RADIUS server.” By applying group policies, different policies can be applied for different set of users. You can specify a group policy to apply to the entire connection profile or even attach a group policy to a user or set of users.
As with the connection profiles, there is also a default group policy on the ASA called “DfltGrpPolicy”, part of which is shown below.
From the output above, you can see some of the options that can be set including split-tunnel, tunnel protocols and DNS settings.
This default group policy can be modified but not deleted. The same thing applies to the default connection policies (tunnel groups).
Let us stop here for now and recap what we have learnt so far.
This article was a preparatory one on VPNs on the Cisco ASA, detailing the several parts that we will need to configure VPNs on the ASA. We have seen the IKE commands, different types of tunnel groups and also the group policy.
In the next article, we will be using these parts to configure VPN tunnels including LAN-to-LAN tunnels (also called site-to-site) and remote access VPNs.
I hope you have found this article informative and I look forward to a successful series.
Reference and helpful resource:
Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 and 8.6: http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/asa_84_cli_config.html
Swift Migration of IKEv1 to IKEv2 L2L Tunnel Configuration on ASA 8.4 Code: http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080bca116.shtml#topic1N400024
IKEv2 Packet Exchange and Protocol Level Debugging:http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a0080bf2932.shtml
IPSec Network Security Commands: http://www.cisco.com/en/US/docs/ios/12_2/security/command/reference/srfipsec.html#wp1017910