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.
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 22.214.171.124
At this point, you've completed the basic configuration needed for Phase 1. Let's move onto the 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:
- Encryption algorithm
- Hash algorithm
- Define what the "interesting" traffic is which should be encrypted (Proxy ID)
- Define who the peer is
- 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 126.96.36.199 set transform-set TSET crypto map CMAP 20 ipsec-isakmp match address 102 set peer 188.8.131.52 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
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.