In the first part of this article, I presented the following scenario: 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. In that article, we were able to achieve the configuration using normal crypto maps and multiple entries in the access lists that defined interesting traffic.

In this article, we will look at another way of achieving the same thing using virtual tunnel interfaces (VTIs). The diagram still remains the same as follows:

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

Site-to-site VPN using VTIs

Virtual Tunnel Interfaces (VTIs) bring more flexibility to VPN configuration because rather than defining crypto maps and applying them to physical interfaces, we just route traffic to be encrypted through a virtual interface. Using this option, features like QoS and multicast routing can be used over the VPN tunnels. Multicast routing means that you can run dynamic routing protocols over these tunnels which may provide you more scalability than using static routes.

For site-to-site VPN tunnels, we use a static VTI. We can break down the configuration of site-to-site VPN tunnels using VTIs into the following steps:

  1. Define your ISAKMP policies. Like with any other VPN configuration, we need to create ISAKMP policies which define the authentication method, encryption type, and so on. If using pre-shared key authentication, you must also define your pre-shared keys.
  2. Define Transform set. We will also define transform sets like any normal VPN configuration.
  3. Define IPsec Profile. This is where the difference begins to show. We need to create an IPsec profile (which will include the transform set) to be applied to the tunnel interface.
  4. Create VTI. The VTI is just a normal tunnel interface (e.g. like the one used for GRE tunnels) except that the tunnel mode is different. Here, we will configure settings like IP address, tunnel source and destination, and the tunnel protection IPsec profile under the VTI.

With this information, let us now create the VPN tunnels on our routers. Keep in mind that there should only be two VPN tunnels: between Site A and Site B and between Site A and Site C. Traffic between Site B and Site C should flow through Site A.

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

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 isakmp policy 10
 hash md5
 authentication pre-share
!
crypto isakmp key cisco address 192.168.20.1
crypto isakmp key cisco address 192.168.30.1
!
crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac
!
crypto ipsec profile IPSEC_PROF
 set transform-set TRANS_SET
!
interface tunnel0
 description ***SITE_A to SITE_B tunnel***
 ip addr 10.0.12.1 255.255.255.0
 tunnel source Fa0/0
 tunnel destination 192.168.20.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC_PROF
!
interface tunnel1
 description ***SITE_A to SITE_C tunnel***
 ip addr 10.0.13.1 255.255.255.0
 tunnel source Fa0/0
 tunnel destination 192.168.30.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC_PROF
!
ip route 192.168.20.0 255.255.255.0 192.168.10.2
ip route 192.168.30.0 255.255.255.0 192.168.10.2

Since Site A will be having two VPN tunnels (one to Site B and the other to Site C), I have created two VTIs. The IP address subnet of the tunnel between Site A and Site B is 10.0.12.0/24 while that for the tunnel between Site A and Site C is 10.0.13.0/24. I have also used Fa0/0 as the tunnel source for both tunnels and specified the tunnel destination accordingly. You will also notice that the tunnel mode is ipsec ipv4 and finally, I attached the IPsec profile I created to protect the tunnel.

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

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 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 ipsec profile IPSEC_PROF
 set transform-set TRANS_SET
!
interface tunnel0
 description ***SITE_B to SITE_A tunnel***
 ip addr 10.0.12.2 255.255.255.0
 tunnel source Fa0/0
 tunnel destination 192.168.10.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC_PROF
!
ip route 192.168.10.0 255.255.255.0 192.168.20.2

Finally, the configuration on Site C’s router is as follows:

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 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 ipsec profile IPSEC_PROF
 set transform-set TRANS_SET
!
interface tunnel0
 description ***SITE_C to SITE_A tunnel***
 ip addr 10.0.13.3 255.255.255.0
 tunnel source Fa0/0
 tunnel destination 192.168.10.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC_PROF
!
ip route 192.168.10.0 255.255.255.0 192.168.30.2

Using static routes to define networks to be routed via the VTI

In this first case, we will use static routes to define which destinations should be routed via the VTI. Because of the tunnel protection profile on the VTI, any traffic sent via that VTI will be protected. The configuration on the routers will be as follows:

Site A

ip route 2.2.2.2 255.255.255.255 10.0.12.2
ip route 3.3.3.3 255.255.255.255 10.0.13.3

Site B

ip route 1.1.1.1 255.255.255.255 10.0.12.1
ip route 3.3.3.3 255.255.255.255 10.0.12.1

Site C

ip route 1.1.1.1 255.255.255.255 10.0.13.1
ip route 2.2.2.2 255.255.255.255 10.0.13.1

We can test by initiating a ping request between any of the routers.

We can also view the IPsec SAs to verify that the ping traffic is indeed being encrypted and decrypted i.e. going over the VPN tunnel.

Using dynamic routing

Like I said earlier, one of the benefits of using VTIs is the fact that they can carry multicast traffic which is used by many routing protocols. Therefore, we can enable a dynamic routing protocol to advertise our tunnel interfaces and also the subnets that we want protected.

The configuration on the routers is as follows:

Site A

no ip route 2.2.2.2 255.255.255.255 10.0.12.2
no ip route 3.3.3.3 255.255.255.255 10.0.13.3
!
router eigrp 10
 no auto
 network 10.0.0.0 0.0.255.255
 network 1.1.1.1 0.0.0.0

Site B

no ip route 1.1.1.1 255.255.255.255 10.0.12.1
no ip route 3.3.3.3 255.255.255.255 10.0.12.1
!
router eigrp 10
 no auto
 network 10.0.12.0 0.0.0.255
 network 2.2.2.2 0.0.0.0

Site C

no ip route 1.1.1.1 255.255.255.255 10.0.13.1
no ip route 2.2.2.2 255.255.255.255 10.0.13.1
!
router eigrp 10
 no auto
 network 10.0.13.0 0.0.0.255
 network 3.3.3.3 0.0.0.0

After applying this configuration, if we check the routing table of Site B’s router for example, we see that both the 1.1.1.1/32 and 3.3.3.3/32 routes are reachable via Site A’s router’s tunnel IP address.

The ping test will also be successful as shown below:

Summary

In this article, we have seen another way of bridging two sites on separate VPN tunnels together. We used Virtual Tunnel Interfaces to achieve this which also made the use of dynamic routing protocols over the VPN tunnel possible.

In the next part of this article, we will see yet another way of achieving the same result. I hope you have found this article insightful.

References and further reading