Networking-Blog

My WordPress Blog

Configuring and Applying Crypto Maps

Last Updated on Mon, 22 Aug 2022 | IPSEC

After configuring crypto access lists and transform sets, you can add them to a crypto map.

Consider the network in Figure 7-12 with two routers that peer over an untrustcd network. Assume that IKJi, crypto access lists, and transform sets are configured and a crypto map is now needed.

Figure 7-12 A Network with a Basic Crypto Map Configuration

San Francisco

San Francisco

Figure 7-12 A Network with a Basic Crypto Map Configuration

Crypto Maap

New York s1:192.168.1.1

MAP-TO-NY (crypto map)

MAP-TO-SF (crypto map)

New York s1:192.168.1.1

MAP-TO-NY (crypto map)

MAP-TO-SF (crypto map)

In the preceding diagram, Router A’s serial interface to the untrusted network is 192.168.1.1.

A crypto map named MAP-TO-NY is applied to this interface (the configuration commands follow). Likewise, Router B’s serial interface is 192.168.1.2 and has a crypto map called MAP-TO-SF.

The following commands create a crypto map on Router A (for clarity, the context of the IOS prompt is included):

RTA#conf t

Enter configuration commands, one per line. End with CNTL/Z. RTA(config)#crypto map MAP-TO-NY 20 ipsec-isakmp RTA(config-crypto-map)#match address 101

RTA(config-crypto-map)#set transform-set TRANS-ESP TRANS-AH-ESP

RTA(config-crypto-map)#set peer 192.168.1.2

RTA(config crypto-map)#exit

RTA(config)#int si

RTA(config-if)#crypto map MAP-TO-NY

The command crypto map MAP-TO-NY 20 ipsec-isakmp creates a crypto map entry with a sequence of 20 for a crypto map called MAP-TO-NY (the crypto map is created when its first entry is created ). Although this example contains just one entry, crypto maps may contain multiple entries to designate multiple peers, transform sets, and access lists. The sequence number prioritizes the crypto map entries. As the router compares packets to the crypto map, it examines entries in the order of their sequence number (lower sequence numbers are examined first). For this example, a sequence of 20 was chosen so that future entries may be placed before or after this entry. The keyword ipsec-isakmp indicates that IKE is used to manage the SAs for this entry.

IOTE In addition to IKE, which is specified by the ipsec-isakmp keyword, ciypto maps support two other options: ipsec-manual (IPsec without IKE) and cisco (Cisco’s pre-IPsec encryption feature called Cisco Encryption Technology, or CET). Consult the IOS documentation for configuring ipsec-manual or cisco.

The command match address 101 assigns crypto access lisl 101 to this entry. Outbound packets that match this list are protected with IPsec. Inbound packets that match the reverse logic of the list are expected to be protected.

The command set transform-set TRANS-ESP TRANS-AH-ESP defines the transform sets that are acceptable for protecting the traffic covered by the crypto access list. When negotiating IPsec SAs with the remote peer (Router B), the router proposes transform sets in the order listed by this command (this router’s first choice is the transform set TRANS-ESP). Router A and Router B must agree to use a common transform set (a common set of protocols and algorithms) before an SA can be established. TRANS-ESP and TRANS-AH-ESP are the names of transform sets previously created by the crypto ipsec transform-set command. The transform set names (TRANS-ESP, TRANS-AH-ESP) are locally significant and do not have to be the same on both routers.

The command set peer 192.168.1.2 defines the remote peer, Router B, with which this router builds the IPsec S A and to which it subsequently sends the protected traffic. Multiple peers can be configured by repeating the set peer command. This provides a level of redundancy for when SAs are established: If the first peer is not reachable, the router attempts to establish the SA with the next peer in the entry.

The interface configuration command crypto map MAP-TO-NY applies the crypto map to the router’s Serial 1 interface (selected by the command int si). Like access lists, crypto maps do not do anything until you apply them to an interface. The proper place to apply the crypto map is the interface where the protected traffic exits the router: the interface that points in the direction of the remote peer. In this example. Router A’s Serial 1 interface is the exit point (refer to Figure 7-12).

The following is the corresponding configuration on Router B (only the relevant crypto map lines are shown):

RTB#sh run

Current configuration: hostname RTB

<lines deleted for brevity> I

crypto map MAP-TO-SF 20 ipsec-isakmp match address 102

set transform-set B-TRANS1 B-TRANS2 set peer 192.168.1.1

interface Seriall ip address 192.168.1.2 255.255.255.0 crypto map MAP-TO-SF

The crypto access list 102 must be a mirror image of list 101 on Router A, and at least one of the transform sets (B-TRANS1 or B-TRANS2) must match one of Router A’s transform sets (TRANS-ESP and TRANS-AH-ESP). A match means the transform sets share the same protocols (AH, ESP) and algorithms (DES or MD5, for example).

NOTE Crypto access lists arc crypto map elements and interoperate with regular packet-filtering access lists that might exist on an interface. Packets blocked by regular access lists are not processed by IPsec.

Continue reading here: Configuring IPsec SA Lifetimes

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.