In the first article in this series, we described the different parts that we use to configure VPN tunnels on the ASA, including configuration options for IKE phase 1 and 2, tunnel groups, and group policies. We also discovered that, starting with software version 8.4, the ASA now supports IKE version 2, which is an “upgrade” to IKEv1, although they are not interoperable.

Equipped with knowledge of these various aspects of VPN on the ASA that we learned in the previous article, we will go straight into configuring and debugging VPN tunnels on the ASA. We will begin with site-to-site VPN tunnels and, in this article, we will be configuring a tunnel between the Cisco ASA and a Cisco IOS router, using the network diagram shown below:

The objective is to protect traffic between the LANs. The IOS router is connected to the ASA on the outside interface. The 192.168.10.0/24 LAN network is on the inside interface of the ASA. Basic configuration has been done on both devices and the ASA can ping the router and vice versa and they can both ping hosts on their individual LANs, as shown below:

Before we begin configuring, I will like to show you a great command on the ASA that helps you with configuring VPNs. This is the “vpnsetup” command, as shown below:

Using this command, you can view the configuration steps for the different types of VPNs supported on the ASA. An example of site-to-site VPN configuration is shown below:

Take note that some of these steps still reference the old commands, such as “crypto isakmp policy,” but it gives you a nice overview of what needs to be done. It’s actually a good reference, especially for trickier VPN setups like WebVPN.

That being said (or shown), we will begin our VPN configuration. Although the focus is on the Cisco ASA, I will show some of the configurations on the Cisco IOS router, which we will mirror on the ASA.

IKE Phase 1 Policies

The ISAKMP policies configured on the router are shown below:

Let’s now configure these on the ASA. We will begin by using IKEv1 before moving on to version 2.

IKE Phase 2 Configuration

This is where we configure our transform set. The transform set configured on the router uses 3DES and SHA-HMAC, as shown below.

The configuration on the ASA will then be:

Define Interesting traffic

“Interesting traffic” is the traffic to be protected. On the router, the source of the traffic will be the LAN it is connected to (192.168.20.0/24) and the destination will be the LAN connected to the ASA (192.168.10.0/24). On the ASA side, it will be the reverse.

Tunnel Group

The pre-shared key configured on the router is shown below:

To achieve the same thing on the ASA, we need to use tunnel groups. This is where things start getting a bit different between the ASA and the IOS. The tunnel group name will be the IP address of the VPN peer. Keep in mind that, for site-to-site VPN tunnels, the only time you can use a non-IP address tunnel group name is if you are using digital certificates for authentication and the VPN peer is configured to use aggressive mode. You will get a warning when you try to use a name instead of an IP address for site-to-site tunnel groups as shown:

We will see why this is so when we look at the debugs. For now, we will go ahead and use the router’s IP address for the tunnel group name.

After defining the tunnel group type, we then have the option of configuring either its “general-attributes” or “ipsec-attributes.” These options are not available before defining the tunnel group. We configure the pre-shared key under the ipsec-attributes.

We will use other options like trust-point as we go along in this series.

Crypto Map

Now let’s tie our configuration together by using the crypto maps. One thing to note on the ASA is that the crypto map command doesn’t have a sub-configuration mode like it does on the IOS; so all the configuration options under that crypto map will begin on a new line with the “crypto map <name>” phrase.

The last line of the configuration above attaches the crypto map to an interface (“outside” in this case). This also differs from the IOS, where you attach a crypto map under the interface configuration mode.

Enable ISAKMP

The final piece of the puzzle is to enable ISAKMP on the interface that will terminate the VPN tunnel. This is usually the outside interface but it can be any interface.

Test VPN Tunnel

That’s it! Our VPN configuration is done and we can go ahead and test the tunnel. To test, I’ll initiate a ping packet from one of the hosts on the ASA LAN (192.168.10.100) to a host on the router LAN (192.168.20.200).

The first ping packet timed out because the tunnel was still being set up.

Let’s look at some show commands on the ASA. The first useful command is the show crypto isakmp sa command, which gives you details about the ISAKMP security association (SA) which is bidirectional, i.e., there’s only one SA between the two peers. You can add the “detail” option at the end to view more settings.

Notice that it is using the ISAKMP policy with 3DES for encryption and SHA for hashing, i.e., ISAKMP policy 1. Why did it choose this? The simple answer is this: Policies are prioritized, with 1 being the highest and 65535 being the lowest. We will consider this in detail when we look through the debug output.

Hint: One of the cool things about the ASA is that you can do show commands from “anywhere.”

Another helpful command is the show crypto ipsec sa command, which gives you information about the IPsec SAs. These SAs are unidirectional and so, for every IPsec protocol (ESP or AH), there will be two unidirectional SAs—inbound and outbound—as highlighted below.

We can end this article on this note, knowing that our tunnel has come up and there’s protected communication between the two LANs. In the next article, we will focus on the debug output for this configuration.

Summary

In this article, we saw a very helpful command, vpnsetup, which details the configuration steps of different VPN types. We then went on to configure a site-to-site VPN tunnel between the Cisco ASA and a Cisco IOS router. Finally, we tested our configuration and saw that our tunnel came up and the protected networks could communicate with themselves.

In the next article, we will go behind the scenes to see what really takes place to bring up a VPN tunnel by looking at the debug output. This will prove helpful, not only for a deeper level of understanding, but also for troubleshooting purposes.

I hope you have found this article insightful and I look forward to communicating with you soon.

Reference and Helpful Resource