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 /30Cisco 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.
R-MAIN(config)#
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto ipsec transform-set ESP_3DES_SHA_HMAC esp-3des esp-sha-hmac
crypto ipsec df-bit clear
crypto ipsec profile VTI_PROF
set transform-set ESP_3DES_SHA_HMAC
set pfs group2
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:
R-MAIN(config)#
crypto isakmp key 0 12345 address 2.2.2.2
For the branch office:
R-BRANCH(config)#
crypto isakmp key 0 12345 address 1.1.1.2
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”:
R-MAIN#sh run
/...output cut.../
crypto isakmp key 7 ^bn UjbsdfgsujGsdf address 1.1.1.2
/...output cut.../
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:
R-MAIN(config)#
interface Tunnel1
description Link to R-BRANCH
ip address 10.0.0.1 255.255.255.252
tunnel source FastEthernet 0/0
tunnel destination 2.2.2.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI_PROF
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
Important!
If entering the last two lines of the above configuration gives you error messages on the router, then you will have to delete the previously created encryption profile with the command:
no crypto ipsec profile VTI_PROF
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:
R-BRANCH(config)#
interface Tunnel1
description Link to R-MAIN
ip address 10.0.0.2 255.255.255.252
tunnel source FastEthernet 4
tunnel destination 1.1.1.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI_PROF
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:
R-MAIN# sh inter tun 1
Tunnel1 is up, line protocol is up
/...output cut.../
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:
R-MAIN#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
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:
R-MAIN#sh cry ips sa peer 2.2.2.2
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 2.2.2.2
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 2.2.2.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps:5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
/...output cut.../
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:
R-MAIN(config)#
ip route 192.168.20.0 255.255.255.0 10.0.0.2
For the branch office:
R-BRANCH(config)#
ip route 192.168.10.0 255.255.255.0 10.0.0.1
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.
R-MAIN(config)#
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto ipsec transform-set ESP_3DES_SHA_HMAC esp-3des esp-sha-hmac
crypto ipsec df-bit clear
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:
R-MAIN(config)#
crypto isakmp key 0 12345 address 2.2.2.2
For the branch office router:
R-BRANCH(config)#
crypto isakmp key 0 12345 address 1.1.1.2
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“:
R-MAIN#sh run
/...output cut.../
crypto isakmp key 7 ^bn UjbsdfgsujGsdf address 1.1.1.2
/...output cut.../
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:
R-MAIN(config)#
ip access-list extended ACL_CRYPTO_BRANCH
permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
Branch office:
R-BRANCH(config)#
Ip access-list extended ACL_CRYPTO_MAIN
permit ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255
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:
R-MAIN(config)#
crypto map CRYPTO_MAP 1 ipsec-isakmp
set peer 2.2.2.2
set transform-set ESP_3DES_SHA_HMAC
match address ACL_CRYPTO_BRANCH
Branch office:
R-BRANCH(config)#
crypto map CRYPTO_MAP 1 ipsec-isakmp
set peer 1.1.1.2
set transform-set ESP_3DES_SHA_HMAC
match address ACL_CRYPTO_MAIN
The crypto map policy has to be assigned to the external interface of each router:
At the main office:
R-MAIN(config)#
Interface FastEthernet0/1
crypto map CRYPTO_MAP
At the branch office:
R-BRANCH(config)#
Interface Fa 4
crypto map CRYPTO_MAP
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:
R-MAIN(config)#
ip route 192.168.20.0 255.255.255.0 1.1.1.1
For the branch office:
R-BRANCH(config)#
ip route 192.168.10.0 255.255.255.0 2.2.2.1
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:
R-MAIN#ping 192.168.20.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
Check that the traffic is being sent over the tunnel using command sh cry ips sa peer 2.2.2.2:
R-MAIN#sh cry ips sa peer 2.2.2.2
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 2.2.2.2
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)
current_peer 2.2.2.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps:5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
/...output cut.../
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.
Important!
Don’t forget to save the changes you made to the configuration of all devices with the write or copy run start commands. Otherwise you will lose all changes after the next reload.
R-MAIN#write
Building configuration...
[OK]
This article was written by Alexey Yurchenko
Very good! Thank you!