Dynamic VTI + RRI Query

Devlin Thornicroft · ‎08-28-2013

Hi all

Apologies if this has been asked before. I have looked around for an answer to my query, could just be my fried brain missing it.

The situation is this: we have a requirement to implement a large hub and spoke network whereby each spoke should have its data traffic encrypted. There will be approximately 250 spoke sites.

Clearly, a static approach, i.e. static VTIs at the head-end/hub and the spokes would not scale well and would require a great deal of config (human error) at either end. So a more dynamic approach is needed.

I was looking into a static and dynamic VTI approach where I create a dynamic VTI at the head-end/hub and static VTIs at each spoke. This way the head-end config is minimal with the majority of config done at each branch site.

I did find a great article here that explains how to configure the static/dynamic VTI:

http://stack.nil.com/ipcorner/IPsecVPN3/

With two trusty routers I set about my mission and successfully got it working where a VTI was established between the head-end/hub and the spoke, as confirmed using the following commands:

SPOKE#show crypto session
Crypto session current status

Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 10.254.0.1 port 500
IKEv1 SA: local 10.254.0.3/500 remote 10.254.0.1/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

HUB1#show crypto session
Crypto session current status

Interface: Virtual-Access1
Profile: DVTI
Session status: UP-ACTIVE
Peer: 10.254.0.3 port 500
IKEv1 SA: local 10.254.0.1/500 remote 10.254.0.3/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

HUB1#show ip interface brief

Interface IP-Address OK? Method Status Protocol

Embedded-Service-Engine0/0 unassigned YES unset administratively down down

GigabitEthernet0/0 unassigned YES unset administratively down down

GigabitEthernet0/1 10.254.0.1 YES manual up up

Loopback0 10.122.20.1 YES manual up up

Virtual-Access1 10.122.20.1 YES unset up up

Virtual-Template1 10.122.20.1 YES unset up down

Vlan1 unassigned YES unset down down

The VTI is indeed up but this does not necessarily mean that any traffic emanating from the spoke is being encrypted right? Would I not need to somehow define what should be encrypted? For example, with the crypto map style of configuration you would create an ACL that defines the "interesting traffic".

Behind the spoke I have a LAN and any traffic from that LAN into the head-end/hub should be encrypted. On the link above it says:

Dynamic VTIs can also mimic the functionality of dynamic crypto maps. A central site can be reconfigured to use dynamic VTIs while retaining existing IPsec tunnels from remote sites using static crypto maps. Functionality like that of reverse route injection (RRI) is automatic with dynamic VTIs, whereby a static route is created automatically for each remote network negotiated via IKE.

As I understand it RRI will dynamically enter a static route into the hub's IP routing table for a spokes LAN subnet. However, this is not the case on my test lab. And it's probably something really simple that I am missing.

Can someone in easy to understand language please explain where I'm going wrong? In a nutshell how do I let the head-end know about the spoke's LAN subnet that the head-end would then need to create a dynamic static route (RRI) to?

The full configs are here:

hostname SPOKE

!

crypto keyring WPSK

pre-shared-key address 10.254.0.1 key cisco

!

crypto isakmp policy 10

encr 3des

authentication pre-share

group 2

!

crypto ipsec transform-set TS esp-3des esp-sha-hmac

mode tunnel

!

crypto ipsec profile VTI

set transform-set TS

!

interface Loopback0

ip address 10.122.10.1 255.255.255.255

!

interface Loopback10

description Simulated LAN

ip address 10.180.10.1 255.255.255.0

!

interface Tunnel0

ip unnumbered Loopback0

tunnel source GigabitEthernet0/1

tunnel mode ipsec ipv4

tunnel destination 10.254.0.1

tunnel protection ipsec profile VTI

!

interface GigabitEthernet0/1

description WAN INTERFACE

ip address 10.254.0.3 255.255.255.0

duplex auto

speed auto

!

router bgp 65532

bgp log-neighbor-changes

network 10.122.10.1 mask 255.255.255.255

neighbor 10.254.0.1 remote-as 65400

!

***************************************************************

!

hostname HUB1

!

crypto keyring WPSK

pre-shared-key address 0.0.0.0 0.0.0.0 key cisco

!

crypto isakmp policy 10

encr 3des

authentication pre-share

group 2

crypto isakmp profile DVTI

keyring WPSK

match identity address 0.0.0.0

virtual-template 1

!

crypto ipsec transform-set TS esp-3des esp-sha-hmac

mode tunnel

!

crypto ipsec profile VTI

set transform-set TS

!

interface Loopback0

ip address 10.122.20.1 255.255.255.255

!

interface GigabitEthernet0/1

description WAN INTERFACE

ip address 10.254.0.1 255.255.255.0

duplex auto

speed auto

!

interface Virtual-Template1 type tunnel

ip unnumbered Loopback0

tunnel mode ipsec ipv4

tunnel protection ipsec profile VTI

!

router bgp 65400

bgp log-neighbor-changes

network 10.122.20.1 mask 255.255.255.255

neighbor 10.254.0.3 remote-as 65532

!

Many thanks in advance for your help and advice.

Marcin Latosiewicz · ‎08-28-2013

Devlin,

SVTI negotiates "any any" as their IPsec SAs. You can accomodate multiple of those (unlike crypto maps) because of separate VA for each tunnel.

In case you have "any any" it makes little sense to perform RRI, it's way better to rely on dynamic routing protocol (unicast or mcast based) to route traffic you want over the tunnels (if you're going to BGP, look into listen range).

router bgp 65001
 network 192.168.0.0
 bgp log-neighbor-changes
 bgp listen range 10.1.1.0/24 peer-group Spokes
 aggregate-address 192.168.0.0 255.255.0.0 summary-only
 neighbor Spokes peer-group
 neighbor Spokes remote-as 65001

What you can look also look into is DMVPN or FlexVPN which would allow you to do GRE or VTI-like approach with a few more added perks.

Devlin Thornicroft · ‎08-28-2013

Hi Marcin

First off thanks for your reply and suggestions. Unfortunately due to time constraints I am unable to consider DMVPN or FlexVPN. Another point I should mention is that all sites will be interconnected through a Layer 3 VPN service. The BGP config above simply mimics this connection with the subsequent advertisement of the loopback for the VTI establishment. I understand I could have simply used another IGP for this purpose in my lab scenario.

Running a routing protocol over the VTI is an avenue I have explored and got working, however, again there are constraints which would take a long time to go into here.

So essentially I am very keen to try (I emphasise the word 'try') to get this working using RRI. It would make my life so much easier. Therefore I ask you and the community once more for any advice that could make this work.

Thank you

Marcin Latosiewicz · ‎08-29-2013

Devlin,

RRI is not the way to go with SVTI on spoke ends. What you can try to go for in this case is multi-SA DVTI on hub with crypto maps on spoke, in which case proxy IDs could be negotitated more specificailly and inserted into routing table.

Or just use DVTI ezvpn... Or move to crypto maps completely.

M.