Site to Site VPN between Cisco Routers

One of the most common tasks dealing with Cisco 881 and other routers is building a site to site VPN tunnel between different geographic locations. Today we will look at an example setting up a VPN tunnel between a main office and a remote branch office.

At our disposal, we have:

Cisco 2800 router in the main office (R-MAIN)
Main office user LAN 192.168.10.0 /24
External static IP address 1.1.1.2 /30
ISP gateway 1.1.1.1 /30

Cisco 881 router in the branch office (R-BRANCH)
Branch office user LAN 192.168.20.0 /24
External static IP address 2.2.2.2 /30
ISP gateway 2.2.2.1 /30

Both of our routers have access to the Internet and the minimal configuration in place, as outlined in this article. Users in both offices can access the Internet and use the resources on their local LAN, but cannot access the workstations and servers in the remote LAN.

There are two simple ways of organizing secured communications between two offices:

Method 1. Tunnel interfaces

This approach should be used when the VPN tunnel is being formed between two Cisco routers. It is simple to configure and use. It’s important to remember that the external IP addresses are static and do not change, and the configuration examples rely on that they are assigned to you by the ISP and will remain the same.

Let’s configure a virtual tunnel that will be used for traffic between the offices:

Step 1. Define the encryption parameters

Choose which encryption methods you would like to use for your tunnel. If you don’t know what these are and how they are compared, just copy the configuration lines from this example.

These configurations lines will be exactly identical for R-BRANCH router in the remote office, i.e. they have to be present on both routers and match.

Step 2. Create an encryption key

Encryption key is another thing that should be identical on both routers that participate in the VPN tunnel formation. I recommend making it no less than 50 characters so that it contains digits, letters and special characters. For this example, we’ll just use a simple “12345” key, but that’s not a good idea for a real VPN tunnel.
For the main office:

For the branch office:

The configuration example has the values that you should change to your own highlighted in red. The “0” in the “crypto isakmp key” line means that the key is being entered in an unencrypted form. You should not change this to any other value. When you look at the running configuration, in certain cases the crypto key gets encrypted and displayed in a scrambled format. This is indicated by the number “7” after the “crypto isakmp key”:

This does not mean that the key itself has changed, it means that it is displayed (!) in an encrypted format.
Note that on each router we are specifying the external IP address of the remote location (i.e. we are saying use this key to communicate with this remote mate’s address)

Step 3. Create the tunnel interfaces

Next, we create the virtual tunnel interfaces on each router.
At the main office:

ip address 10.0.0.1 255.255.255.252 — the IP address for this side of the tunnel (for the virtual tunnel interface)
tunnel source FastEthernet 0/0 — use the external interface of this router as source
tunnel destination 2.2.2.2 — use the external IP address of the remote router for destination
tunnel mode ipsec ipv4 — encrypt traffic passing over this interface with IPSec
tunnel protection ipsec profile VTI_PROF — use the “VTI_PROF” profile for encryption parameters

This means that the IOS version that you have does not allow for this method of building a VPN tunnel and you will have to use the second method described later in this article.
For the branch office router:

ip address 10.0.0.2 255.255.255.252 — the IP address for this side of the tunnel (for the virtual tunnel interface)
tunnel source FastEthernet 4 — use the external interface of this router as source
tunnel destination 1.1.1.2 — use the external IP address of the remote router for destination
tunnel mode ipsec ipv4 — encrypt traffic passing over this interface with IPSec
tunnel protection ipsec profile VTI_PROF — use the “VTI_PROF” profile for encryption parameters
If all three steps have been performed correctly, the status of your tunnel interface should change from up/down to up/up. You can check this with the following command:

Step 4. Check the VPN tunnel

You can check whether the VPN tunnel has come up by sending a ping request to the IP address of the remote router’s virtual interface. For example, from the main office:

You should also see if the packets are being encrypted when passing over the tunnel using command sh cry ips sa peer 2.2.2.2:

The last two lines of the above output indicate that the router has encrypted and sent 5 packets and received and decrypted the same number of packets. These counters will get incremented each time when a packet is passed over the tunnel between the two routers.

Step 5. Routing

In order for the internal networks of both offices to be seen by the other office, you also need to configure the routes to the respective subnets on both routers.
For the main office:

For the branch office:

After completing all these steps, all workstations, servers and other hosts should be available for both offices and all traffic between the two locations encrypted.

Method 2. Universal method

This approach can be used to build a VPN tunnel between a router and a Cisco ASA device, or any other equipment that supports IPSec VPN, even if it is not from Cisco. The configurations for encryption parameters, keys, and routing will be essentially the same for another vendor or type of device, but will differ in syntax. We’ll examine using two Cisco routers for this configuration, just for simplicity’s sake:

Step 1. Define the encryption parameters

First, let’s define the encryption parameters for the tunnel. If you don’t know what these are, just copy the lines from this example.

These configurations lines will be exactly identical for R-BRANCH router in the remote office, i.e. they have to be present on both routers and match.

Step 2. Create an encryption key

Next, we define the encryption key. It will be identical for both ends of the tunnel. I recommend making it no less than 50 characters so that it contains digits, letters and special characters. For this example, we’ll just use a simple “12345” key, but that’s not a good idea for a real VPN tunnel.
For the main office router:

For the branch office router:

The configuration example has the values that you should change to your own highlighted in red. The “0” in the “crypto isakmp key” line means that the key is being entered in an unencrypted form. You should not change this to any other value. When you look at the running configuration, in certain cases the crypto key gets encrypted and displayed in a scrambled format. This is indicated by the number “7” after the “crypto isakmp key“:

This does not mean that the key itself has changed, it means that it is displayed in an encrypted format.
Note that on each router we are specifying the external IP address of the remote location (i.e. we are saying use this key to communicate with this remote mate’s address)

Step 3. Define the «interesting traffic» that should be encrypted and sent into the tunnel

Next step is to define the traffic that we need to encrypt. For this example, this is all traffic between subnets 192.168.10.0 /24 of the main office and 192.168.20.0 /24 of the branch office. “Interesting traffic” is defined through creating an access list on each router:
Main office:

Branch office:

Step 4. Create the encryption policy

On each router we create a “crypto map“, which is the policy that brings together all encryption rules and parameters
Main office:

Branch office:

The crypto map policy has to be assigned to the external interface of each router:
At the main office:

At the branch office:

Step 5. Routing

In order for the internal networks of both offices to be seen by the other office, you also need to configure the routes to the respective subnets on both routers. In this case, the route to the remote network needs to point to the gateway of the ISP at that location.
For the main office:

For the branch office:

After completing all these steps, all workstations, servers and other hosts should be available for both offices and all traffic between the two locations encrypted.

Step 6. Check the VPN tunnel

Check the availability of the VPN tunnel by pinging a device from the remote subnet. For example, send a ping request from a workstation at the main office to a server located at the branch office:

Check that the traffic is being sent over the tunnel using command sh cry ips sa peer 2.2.2.2:

The last two lines of the above output indicate that the router has encrypted and sent 5 packets and received and decrypted the same number of packets. These counters will get incremented each time when a packet is passed over the tunnel between the two routers.
This method of building a VPN tunnel requires more administration and and maintenance with configuration changes. It also requires the administrator to be more attentive when configuring the tunnel details.