Guide to Cisco ASA VPN
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.
1. [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.
2. [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… “don’t NAT”.
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.
3. [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.
4. [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 1.1.1.2 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 1.1.1.1 crypto map VPN_map 10 set transform-set ESP-AES-256-SHA crypto map VPN_map1 interface
5. [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.
6. [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 1.1.1.2 type ipsec-l2l tunnel-group 1.1.1.2 IPSec-attributes pre-shared-key testkey
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.
7. [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.