CCIE Security: Site-to-Site IOS VPN with Crypto Maps

In this post, I'm going to go through configuring site-to-site VPN on IOS. We're going to take what we learned in the last blog post and apply it here. I think the best way this was explained to me was by Khawar Butt where he stated that you should break down your VPN configuration by phases to help you remember and know what you need to add. For the folks who don't know who Khawar Butt is, I'll be writing a review of his class shortly but you can see a sample of his work here.  

 

When you are building the site-to-site VPN configuration, remember what is fundamentally needed for each phase.

 

Phase 1

This is where the bidirectional ISAKMP channel is created for negotiation. The first thing you should create is the policy. A policy should contain the following at the very least:

  • Authentication method
  • Encryption algorithm
  • Hash algorithm 
  • Diffie-Hellman group

 

We define these in a crypto ISAKMP policy like below:

crypto isakmp policy 10 
authentication pre-share
enryption aes
hash sha256
group 2

 

Next, we will want to specify the ISAKMP peer and the key to use to establish that ISAKMP tunnel:

crypto isakmp key cisco123 address 2.2.2.1

 

At this point, you've completed the basic configuration needed for Phase 1. Let's move onto the Phase 2.

 

Phase 2

The purpose of this phase is to establish the two unidirectional channels between the peers (IPSec SAs) so data can be sent securely. In order for these channels to be established, the following is required:

  1. Encryption algorithm
  2. Hash algorithm
  3. Define what the "interesting" traffic is which should be encrypted (Proxy ID)
  4. Define who the peer is 
  5. Apply the crypto to an interface

 

To define the first two requirements, you would create an IPSec transform set where you would define your encryption and hash algorithms:

cyrpto ipsec transform-set <tset-name> esp-aes 256 esp-sha512-hmac


Note: You can also configure the IPSec mode using mode transport or mode tunnel. By default, it's set to mode tunnel in IOS and I'm going to leave it that way to keep this post simple but if you need a review of what tunnel vs transport mode is, please review my last blog post. 

 

For the next requirement, we will define the interesting traffic in an access-list. This is basically what traffic should be encrypted and passed through the VPN. You would specify the local subnet and the remote subnet.

access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

 

We will then tie together all of the requirements 1 through 4 in something called a crypto map which will then be applied to an interface.

crypto map <map-name> <number> ipsec-isakmp 
match address VPN-TRAFFIC 
set peer <peer-public-ip>
set transform-set <tset-name>

Note: You can have multiple crypto maps defined in the configuration of a router but you can only have one applied to an interface at once time. If you have a router that needs to connect to multiple peers from the same interface, the peers will need to be defined in the single crypto map. 

You would can another numbered entry to the crypto map with different transform-sets and match ACLs. This configuration would look like this:

crypto map CMAP 10 ipsec-isakmp
match address 101
set peer 2.2.2.1
set transform-set TSET

crypto map CMAP 20 ipsec-isakmp
match address 102
set peer 3.3.3.1
set transform-set TSET2

Finally, we will the crypto map which ties together all the elements in our IPSec configuration and apply that to an interface. 

interface g1
crypto map CMAP

You should see a console message indicating the ISAKMP is on after applying the crypto map to the interface:

%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

 

Verification

At this point, we'll want to verify that the VPN is working. If there isn't traffic going over the tunnel, you're not going to initially see anything. A good way to see that nothing is being sent or encrypted is to issue the show crypto ipsec sa command:

As you can see from the output, nothing has been sent yet. Even though I don't have a routing protocol set up or static routes in place for the subnets on the other side, my edge router knows where to send traffic to get to the 192.168.2.0/24 subnet due to my match ACL in the crypto map as you can see from the above. 

The next thing I'm going to do is trigger traffic to be sent from one peer to the other by pinging from one subnet to the other. If you want to issue a show crypto isakmp sa, you can see the ISAKMP channel that is formed and that it's currently active:

Then looking back on our show crypto ipsec sa output, we can see the packets being encrypted and decrypted.