How to configure Site to Site VPN on a Cisco ASA.
(version: 1.1 - updated August 6, 2009)
2. [The situation]
3. [Getting started]
4. [Interesting traffic]
7. [Crypto map]
8. [Isakmp policy]
"]Looking through the questions asked here at Experts-Exchange, I noticed that even though the ASA has improved a lot in terms of accessibility for new users, there are still a lot of questions asked about setting up VPN's. There is a lot to be said about VPN's and the different types of VPN: site to site, remote access IPSec, client-less, SSL, DMVPN... It would be difficult to add all the specifics at once. But to accommodate those who are new to ASA's I figured it might be helpful to have a point to get started.
So I decided to write a how to, on how to get started on the most basic of VPN's; configuring a site to site VPN from the CLI, with descriptions for each step. Hopefully I will be able to provide new ASA users with a place to get started or maybe the ability of some basic troubleshooting.
I would also like to add that setting up a VPN through the ASDM using the VPN wizard is extremely easy. That's why I've focused on the CLI part. I find that although setting up VPN through the wizard is easy, you can easily get in trouble if it does NOT work and you are forced to troubleshoot through the CLI. I hope this article will provide both help with setting up, troubleshooting and understanding site to site VPN configurations.
For a step by step guide on configuring through the wizard you can look at the Cisco site:
Cisco ASA 5500 Getting Started Guide
So let's get started.
1. [Introduction] --------------------
Before starting to configure a site to site VPN let's first have a quick look at what VPN is.
VPN stands for Virtual Private Network and it is basically a connection from one location to another to provide a LAN like connection experience to the user over an unmanaged WAN link. This means that if you have a corporate LAN with services like e-mail or Intranet that can only be accessed from you local office you can use VPN to connect remote users or sites to the network as though they were locally connected using their Internet connection.
The above is accomplished by creating a secure tunnel over an unsecured web link, defining which traffic should be routed over this tunnel and the remote users can access local services seamlessly. Of course the bandwidth is still limited by the Internet connections available at both sites, but a VPN tunnel is still a secure and often used way to connect branch offices and home users the like.
In general there are two types of VPN:
- Remote access
- Site to site
Remote access VPN, or easy VPN as it is often named, is the home user version of VPN. You typically install a client on a pc or laptop (or you use a client-less portal on the ASA), the user sets up a connection to the office, logs on with a username and password and is granted access to the LAN. Once the tunnel is in place he can work and access servers as though he was at the office. The tunnel can be built over IPSec or SSL. When done he can disconnect the VPN connection.
Site-to-site VPN is often used for branch offices, when a manageable amount of branch offices is available. You place a VPN device like Cisco ASA or a Cisco router on both sites. You configure both devices to setup a tunnel with each other. The whole remote office can now use this tunnel at the same time (whereas with remote access VPN only the pc on which the tunnel is setup can use the tunnel) to access resources on the main office. Since the devices keep the tunnel up, the tunnel usually stays up always. This is the VPN I want to discuss in this article.
The tunnel setup occurs in 2 phases. In the first phase a secure ´management connection´ called a security association is created. This connection is then used to pass the keys over to the other device. Those keys are then used to setup phase 2 of the tunnel, the IPSec. IPSec is the secure connection over which all data traffic is sent.
2. [The situation] --------------------
In order to give some explanations it would be helpful to create some examples. In order to do this I will create a situation which I will use for future reference.
Consider a company with a 100 user main office. It's got a couple of servers on its LAN for things like mail and Intranet and uses a Cisco ASA 5520 as an Internet gateway.
The corporate LAN network is 10.0.0.0/24 and the gateway (ASA) has an inside address of 10.0.0.254 and an outside address of 188.8.131.52.
This company recently expanded and a branch office with 10 users is opened in another city. This office has 10 pc's and no servers. They have an Internet connection available and for security purposes an ASA 5510 has been installed as a firewall. The branch office LAN is 192.168.0.0/24 and the gateway (ASA) has an inside address of 192.168.0.254 and an outside address of 184.108.40.206.
Here's a visual display of a small network setup:
192.168.0.0/24 |ASA|---------------------------|ASA| 10.0.0.0/24
NOTE: I have used the 220.127.116.11 network on the WAN side for purposes of easy typing. Please note that these are real addresses and actually belong to real people. Please don't use them outside of a lab environment.
The company wants the branch office connected to the main office using site to site VPN.
3. [Getting started] --------------------
Now it's time to do some configuring. Since this is a how to on VPN and not ASA's in general I will assume that you are accustomed with ASA's, accessing the command line and setting up a working Internet connection. If not, you can post to the forums and the experts will gladly help you get to that point. :-)
To get your VPN going you will need the following parts in your configuration:
- an access-list defining interesting traffic
- an access-list exempting your VPN traffic from NAT (NAT0)
- a crypto IPSec transform-set defining your IPSec encryption
- a crypto map defining the actual IPSec tunnel
- a crypto isakmp policy to define your 'negotiation settings' for phase 1.
- a tunnel-group defining attributes to the tunnel
When troubleshooting you should make sure that the above parts are present in your config. If they are you are usually well underway.
Next, make sure that your NAT exempt access-list is actually referenced (see under the NAT0 chapter), that your crypto map is correctly applied to an interface (see the crypto map chapter) and that isakmp is globally enabled (see the isakmp policy chapter).
I will now cover all the separate steps one by one and try to give an explanation of what each part does and what it should look like .They order in which I reference the different commands is not necessarily the best order to configure a VPN tunnel. I've chosen this order because this is the order in which it will appear in a config, hopefully making it easier when troubleshooting to step by step go through your config and see if all is setup correctly.
4. [Interesting traffic] --------------------
When creating a VPN tunnel you have to tell the ASA which traffic must be sent through the tunnel. The traffic which goes through is called "interesting traffic". You create this selection using an access-list.
On a site to site VPN you configure both sides of the tunnel. Be aware that you create an access-list on each side and that they actually mirror each other. On the first site you tell the ASA you want to tunnel traffic from the main site to the branch office. On the other you are on the branch site so you tell the ASA to tunnel traffic from the branch site to the main site.
It might seem obvious, but it's quite often overlooked.
Let's create the commands to see how it looks:
access-list VPN_cryptomap extended permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0
As you can see this is an access-list created on the Main office as it tells the ASA that traffic from the 10.0.0.0 network to the 192.168.0.0 network should be put into the tunnel. All other traffic will not be treated as interesting for the tunnel and will proceed the normal way through the ASA.
Now let's look at the access-list that you would use on the branch site:
access-list VPN_cryptomap extended permit ip 192.168.0.0 255.255.255.0 10.0.0.0 255.255.255.0
Note again how the traffic selection is reversed to select traffic specifically going from the branch office to the main office.
Of course this is just the actual defining of interesting traffic. It is not yet related to an action at this point. The ASA will select the traffic as you specify and then shrug and just let it pass as usual. We will define an action to the selection later on when configuring the crypto map.
5. [NAT0] --------------------
Since you directly connect the main and branch sites you generally do not need to NAT the traffic between the locations. As you have most likely setup some kind of NAT for your Internet connection and the like you will need to exempt the traffic which needs to go through the tunnel from being NATted.
To do this we will again use an access-list:
access-list Inside_nat0_outbound extended permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0
Just like with the interesting traffic we have just selected the traffic at this point. We now need to tell the ASA what to do with the traffic it sees. In this case we create a statement to do "NAT0". Which means... "
nat (Inside) 0 access-list Inside_nat0_outbound
Notice that we use the 'nat' statement as you would normally, connecting it to an interface. We come from the inside interface, so that's where the statement should be. Then you provide a number where you would normally put the pool number of the global that you define on the other side. In this case we use 0 to tell the ASA there is no pool and just don't use NAT at all. We reference the access-list we created earlier.
Now the traffic we selected with this access-list will not be NATted through the ASA.
Let's do the same for the branch site:
access-list Inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 10.0.0.0 255.255.255.0
nat (Inside) 0 access-list Inside_nat0_outbound
Note that we again changed the traffic selection to be mirrored to the main site, as we are now going the other way.
6. [Transform-sets] --------------------
This is where the order of things might get a bit confusing to some, as the transform-sets actually define the encryption of phase 2. And at this point we haven't even configured phase 1 yet! I still like to adhere to this order as it won't matter when configuring and it will hopefully make troubleshooting easier.
Like I said the transform-sets define which encryption we use in phase 2, or at the IPSec level. Both sides will negotiate the encryption levels and therefore the NEED to be the same on both locations. If you encrypt with key A, you will also need to decrypt with key A. Otherwise you won't be able to read the message.
You can define your own sets, but the ASA comes with the most common ones predefined. Those have always sufficed to me so I would advise to use those unless you have a specific reason not to.
Again, as before, you just create the transform-sets here (or at least make sure they are present in the configuration) but they don't do anything yet. We reference these transform-sets later when configuring the crypto map.
crypto IPSec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto IPSec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto IPSec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto IPSec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
When first looking at the commands they seemed a bit redundant to me, but note that after the part 'crypto IPSec transform-set' you define a name (here in caps). The defaults reference the encryption that is used. This could be anything you like, though. After that the encryption type and authentication type are specified.
7. [Crypto map] --------------------
Now it's time to define the parts that actually get the tunnel going and put some of the building blocks we created together. We do this with a crypto map.
I will first create the configuration items that we would use at the main site and then explain the individual items:
crypto map VPN_map 10 match address VPN_cryptomap
crypto map VPN_map 10 set peer 18.104.22.168
crypto map VPN_map 10 set transform-set ESP-AES-256-SHA
We use the command "crypto map" and then create a name. After the name comes a reference number. The reason for this number is that you can only apply one crypto map to each interface. This would be a problem if you had 2 branch offices and only one outside interface!
Cisco solved this by using these reference numbers. You use the same crypto map every time on an interface, but you can use different reference numbers per tunnel. This way you are able to setup multiple tunnels on this single interface.
Then on the first line you see the access-list we created referred to. This is where we say, if you see THAT traffic, put it into the tunnel.
Second, we define the peer. This is the other side of the tunnel, so in this case the WAN IP address of the branch office.
Third you tell the ASA which type of encryption you are going to use at IPSec level. We reference the NAME of the transform-set defined in the previous step.
When you have your crypto map defined it still won't do anything until it is applied to an interface. Make sure you apply it to the interface closest to the other side of the tunnel, in our case the outside interface:
crypto map VPN_map interface outside
You would then do the same on the branch office, but obviously with the WAN IP address of the main office as it's peer:
crypto map VPN_map 10 match address VPN_cryptomap
crypto map VPN_map 10 set peer 22.214.171.124
crypto map VPN_map 10 set transform-set ESP-AES-256-SHA
crypto map VPN_map1 interface
8. [isakmp policy] --------------------
Now that we have the phase 2 part covered, where the actual IPSec tunnel is built, we first need to provide for a secure layer to get management traffic through. This is Isakmp or phase 1.
To get a management layer (security association) going the ASA's need policies defined. They go top down through these policies until they find one that they agree on. If they don't phase 1 and therefore the complete tunnel, won't come up. Since both sides need to agree we need to create at least one policy and it needs to be the same on both sides. Let's look at the configuration as it should be on both sides and go through it:
crypto isakmp policy 10 authentication pre-share
crypto isakmp policy 10 encryption aes-256
crypto isakmp policy 10 hash sha
crypto isakmp policy 10 group 5
crypto isakmp policy 10 lifetime 86400
You begin each line with the "crypto isakmp policy" command and create a reference number. The lower the number, the higher it will be in the config, the sooner it will be tried for setting up a tunnel. Usually you would put the most secure at the top, as it has preference.
If it can't agree on that level of security it will go one less secure and so on.
The first line configures the means of authentication of the tunnel. You can use either a pre-shared key or a certificate. Pre-shared keys are the easiest to implement, certificate are easiest to manage in large environments. I won't go into details of both; I chose pre-shared keys for our tunnel here for ease of explanation.
Next we define the encryption and authentication mechanisms. This looks a lot like the transform-set, however that is used for encrypting at IPSec level. We are now defining encryption at the security association level, which is created BEFORE IPSec will be setup. Once the SA's are in place they will be used to be able to securely setup an IPSec connection.
Then we find the command 'group 5', which references to Diffie-Hellmann group 5. The working of Diffie-Hellmann is beyond the scope of this document, but in short it's a secure way to get secure information (keys) over an insecure connection.
Finally the lifetime of the SA's in seconds. After the lifetime has expired, the keys will be recalculated. The tunnel is not affected.
When you are done with configuring enable isakmp on the interface on which the ASA should be able to build a tunnel:
crypto isakmp enable Outside
This, too, needs to be set on both ASA's.
9. [Tunnel-group] --------------------
Now that we have our phase 1 and 2 configured we can use 'tunnel-groups' to configure specific options for the tunnel. In site to site tunnels I would advise using the IP address of the peer as the group-name. I have seen problems in the past where a different name had been used.
tunnel-group 126.96.36.199 type ipsec-l2l
tunnel-group 188.8.131.52 IPSec-attributes
In the first command we tell the ASA we are creating an IPSec tunnel.
In the second, we create something that we referenced earlier: the pre-shared key. You define it here and reference it in the crypto isakmp policy. Make sure that the key is the same on both ASA's!
I would also advise to use a stronger key then the one I use here, as it is basically a password into your network.
10. [Wrap-up] --------------------
And there you have it! You have created your site-to-site tunnel!
Now go to a client on either one of the locations and start a ping, remote desktop session or open a web site. The first try might fail, but don't get discouraged. When the first packet arrives at the ASA it will start setting up the tunnel, which can take a few seconds. Then try again and you should now be able to reach all pc's, printers and servers on both sides of the tunnel.
For general troubleshooting you can use the following commands:
show crypto isakmp sa
show crypto IPSec sa
They will show you if a tunnel is setup at either phase 1 (SA) or phase 2 (IPSec) respectively.
I know this guide isn't as extensive as it could be and there are hundreds of different ways to setup and use VPN connections. However, I hope this document has helped you either get started or get a basic understanding of VPN's, what they do and how to configure them.
Good luck in all your endeavors.