I recently came across a scenario as follows: Site A and Site B have a site-to-site VPN connection between themselves. Site C is a new site that needs to also have VPN access to Site B but for some reason, this new VPN access has to go through Site A which will then route it to site B.

At first, it seemed strange (and challenging) to me but after labbing it, the solution is not quite as difficult as I initially thought. In this article, we will look at one of the ways to achieve this considering that all the sites are using Cisco IOS routers.

We will be using the diagram below for this lab:

Note: For this lab, the Internet cloud is just a router that has three interfaces with IP addresses 192.168.10.2, 192.168.20.2 and 192.168.30.2.

Site-to-site VPN between Site A and Site B

Let’s start simple: initially, there is a site-to-site VPN connection between Site A and Site B so let us configure that. The VPN tunnel is to protect communication between 1.1.1.1/32 and 2.2.2.2/32. The configuration on Site A’s router is as follows:

hostname SITE-A
!
ip access-list extended SITE_A-SITE_B
 permit ip host 1.1.1.1 host 2.2.2.2
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
crypto isakmp key cisco address 192.168.20.1
!
crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac
!
crypto map CRYP_MAP 10 ipsec-isakmp
 set peer 192.168.20.1
 set transform-set TRANS_SET
 match address SITE_A-SITE_B
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.10.1 255.255.255.0
 crypto map CRYP_MAP
!
ip route 192.168.20.0 255.255.255.0 192.168.10.2
ip route 2.2.2.2 255.255.255.255 192.168.20.1

The configuration is basic site-to-site VPN configuration. The ACL “SITE_A-SITE_B” matches the traffic to be protected. I then created an ISAKMP policy using MD5 hash and pre-shared key authentication; I specified a pre-shared key of “cisco” for peer 192.168.20.1 (i.e. Site B’s router). I also created a transform set and applied that transform set under a crypto map along with the ACL. I applied the crypto map to the Fa0/0 interface of the router which is the interface that connects to the Internet cloud. Finally, I used static routes to define how to reach the peer and also the peer’s network.

The configuration on Site B’s router is very similar as follows:

hostname SITE-B
!
ip access-list extended SITE_B-SITE_A
 permit ip host 2.2.2.2 host 1.1.1.1
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
crypto isakmp key cisco address 192.168.10.1
!
crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac
!
crypto map CRYP_MAP 10 ipsec-isakmp
 set peer 192.168.10.1
 set transform-set TRANS_SET
 match address SITE_B-SITE_A
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.20.1 255.255.255.0
 crypto map CRYP_MAP
!
ip route 192.168.10.0 255.255.255.0 192.168.20.2
ip route 1.1.1.1 255.255.255.255 192.168.10.1

We can confirm that our VPN tunnel is up by issuing a ping between the protected subnets. For example, if I ping 2.2.2.2 from Site A, sourcing the ping from 1.1.1.1, then the VPN tunnel should be set up and traffic should be protected.

Site-to-site VPN between Site A and Site C

Let’s now add Site C to the mix. For this step, we will be configuring a site-to-site VPN tunnel between Site A and Site C. The configuration for Site C will be similar to the first two. However, the configuration addition on Site A needs further discussion.

You can only apply one crypto map to a particular interface. Since we already have a crypto map on Site A’s router’s Fa0/0 interface for the VPN tunnel between Site A and Site B, we cannot add another crypto map for the VPN tunnel between Site A and Site C on that same interface. However, crypto maps (like ACLs, route maps, etc.), support sequence numbers. It means we can match the new VPN tunnel settings for Site C in a different sequence number under the same crypto map.

The configuration change/addition on Site A’s router is as follows:

ip access-list extended SITE_A-SITE_C
 permit ip host 1.1.1.1 host 3.3.3.3
!
crypto isakmp key cisco address 192.168.30.1
!
crypto map CRYP_MAP 20 ipsec-isakmp
 set peer 192.168.30.1
 set transform-set TRANS_SET
 match address SITE_A-SITE_C
!
interface FastEthernet0/0
 no crypto map CRYP_MAP
 crypto map CRYP_MAP
!
ip route 192.168.30.0 255.255.255.0 192.168.10.2
ip route 3.3.3.3 255.255.255.255 192.168.30.1

The configuration on Site C’s router is as follows:

hostname SITE-C
!
ip access-list extended SITE_C-SITE_A
 permit ip host 3.3.3.3 host 1.1.1.1
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
crypto isakmp key cisco address 192.168.10.1
!
crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac
!
crypto map CRYP_MAP 10 ipsec-isakmp
 set peer 192.168.10.1
 set transform-set TRANS_SET
 match address SITE_C-SITE_A
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.30.1 255.255.255.0
 crypto map CRYP_MAP
!
ip route 192.168.10.0 255.255.255.0 192.168.30.2
ip route 1.1.1.1 255.255.255.255 192.168.10.1

We can also confirm that this site-to-site VPN tunnel between Site A and Site C is working by issuing a similar ping as we did before.

Site B and Site C communication via Site A

All the configuration we have been doing has been for this moment: Site B and Site C should be able to communicate with each other. What makes this scenario different is that for Site B and Site C to communicate, they must go through Site A. In short, it is like a hub-and-spoke topology with Site A being the hub and Site B and Site C acting as spokes.

To achieve this, we need to alter the ACLs that define interesting traffic on all our routers:

  1. On Site A’s router, we need to add “3.3.3.3 to 2.2.2.2” to the SITE_A-SITE_B access list. We will also need to add “2.2.2.2 to 3.3.3.3” to the SITE_A-SITE_C access list.
  2. On Site B’s router, we will add “2.2.2.2 to 3.3.3.3” as part of the traffic to be protected under the SITE_B-SITE_A access list.
  3. Finally, on Site C’s router, we will add “3.3.3.3 to 2.2.2.2” under the SITE_C-SITE_A access list.

Also, to sort out routing, we need to specify that the spokes can reach the other spoke’s network via the hub.

The configuration addition on Site A’s router therefore, is as follows:

ip access-list extended SITE_A-SITE_B
 permit ip host 3.3.3.3 host 2.2.2.2
!
ip access-list extended SITE_A-SITE_C
 permit ip host 2.2.2.2 host 3.3.3.3

The configuration addition on Site B’s router is as follows:

ip access-list extended SITE_B-SITE_A
 permit ip host 2.2.2.2 host 3.3.3.3
!
ip route 3.3.3.3 255.255.255.255 192.168.10.1

The configuration addition on Site C’s router is as follows:

ip access-list extended SITE_C-SITE_A
 permit ip host 3.3.3.3 host 2.2.2.2
!
ip route 2.2.2.2 255.255.255.255 192.168.10.1

Hint: You may have to remove and re-apply the crypto map on your interface for the configuration to take effect.

I will now ping between the spokes e.g. from 2.2.2.2 to 3.3.3.3.

The first two ping packets failed while the connection was being set up but you will notice that the ping succeeded seamlessly after that.

We can check the IPsec SAs on the hub (Site A) to see the packets encrypted and decrypted by issuing the show crypto ipsec sa command:

You can also check the spoke routers to see that they only have one ISAKMP SA with the hub and none between themselves.

Summary

In this article, we have seen how to bridge two sites on separate VPN tunnels together. We saw that this resulted in a hub-and-spoke topology. In the next part to this article, we will look at another way of achieving this configuration using Virtual Tunnel Interfaces.

I hope you have found this article insightful.

References and further reading