Advantages of VTI configuration for IPSec tunnels.

Blog

Dec 5, 2010 12:53 PM
Dec 5th, 2010

1. History.

Several years ago, while being new to security team in Brussels TAC, a case appeared in our queue that would change my view on IPSec VPN (and not only!).

The problem description was quite clear - unable to go out through IPSec VPN to the internet when connected with Cisco VPN Client to a 1841 series router in full tunnel mode.

Seems quite easy, right?

Little did I know, that it would require me to grasp a new, and alien at that time, technology very fast.

2. Briefly about the technical problem.

What happens when your VPN client, with private IPv4 address assigned wanted to communicate to the outside world?

Typical edge device for a small business will have one IPv4 address assigned to interface of router.

Users on LAN segment also with private IPv4 address, will want to use this WAN IP to connect to the Internet by virtue of PAT/NAT overload.

Very often this method has to be used by VPN users.

Problem with typical (legacy) ezvpn configuration is that (unlike LAN) VPN users do not have their own interface to use certain features, like "ip nat inside" in this particular case. Thus router isn't aware that it is supposed to have VPN traffic NAT'ted.

u-turn.jpeg

3. The solution.

Previous solutions to this particular problem involved sending VPN traffic (after decapsulation) to a loopback interface by using PBR (the interface would have "ip nat inside" enabled).

This was a neat trick but we can forget about it since we have Dynamic Virtual Tunnel Interface (DVTI).

In this case I configured DVTI, added "ip nat inside" command on it and it worked straight out of the box!

4. About VTI - high level about Virtual Tunnel interfaces.

While my case was solved, I barely started to see the surface of how useful VTI was.

A few things you should know when starting.

VTI comes in two flavors, SVTI (tunnel interface) and DVTI (virtual-template interface).

SVTI are used to have static "on-all-the-time" IPSec tunnels, while DVTI is used to provide "on-demand" connectivity.

SVTI typically should be thought of as a lan to lan tunnel, while DVTI would be used in case of ezvpn (both server and client!) and recently webvpn.

5. Let's have a look at some advantages of VTI.

1. Dynamic routing and multicast through VTI!

Remember one nasty limitation of IPSec - no multicast through unless you used GRE?

Getting devices to talk to each other via OSPF or EIGRP required some tweaks.

Now it's available by default!

That being said GRE is not out of the picture, it's still broadly used and more flexible is more-than-one-better.

2. No GRE overhead.

Have a ping with df-bit set over your tunnel interface when it's VTI and GRE over IPSec...

For example:

ping TUNNEL_IP_ON_THE_OTHER_SIDE source tunnel X df-bit size 1436

3. Tunnel protection and tunnel mode...

Two commands that make VTI.

tunnel mode ipsec ipv4 (or ipv6!)
tunnel protection ipsec profile PROFILE_NAME

Yes, no need to put in an access-list to create a tunnel.

And, no, you don't need to have crypto map applied anywhere!

4. Per-interface/per-tunnel features.

QoS, uRPF, CBAC/ZBF, PBR, access-lists anyone?

5. SVTI to DVTI IPSec tunnel.

You can have SVTI spokes connecting to DVTI hub location and still utlize above benefits.

6. Want to know more?

Configuration guide:

VTI:

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_ipsec_virt_tunnl_ps10592_TSD_Products_Configuration_Guide_Chapter.html

SVTI configuration example:

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_ipsec_virt_tunnl_ps10592_TSD_Products_Configuration_Guide_Chapter.html#wp1027265

DVTI ezvpn server configuration example:

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_easy_vpn_srvr_ps10592_TSD_Products_Configuration_Guide_Chapter.html#wp1519564

DVTI ezvpn client configuration example:

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_easy_vpn_rem_ps10592_TSD_Products_Configuration_Guide_Chapter.html#wp1262673

VTI with webvpn configuration example:

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_ssl_vpn_ps10592_TSD_Products_Configuration_Guide_Chapter.html#wp1461695

7. Comments? Feedback? Flames?

Post a comment :-)

Average Rating: 5 (4 ratings)

Comments

GrandVagabond Tue, 12/14/2010 - 19:30

Great post,How i wish that post had been written a few months ago.  Last month, i stumble in the feature when configuring a Remote access VPN server with SDM. SDM did generate the config,but I didn't understand. Unfortunately, I had a few with the SDM generated config, decided to wipe off the router and use the legacy way with ip nat inside/outside.

Hoo Man, you really ROCK me today...

Thanks,

Jean

yuri_slobodyanyuk Tue, 01/18/2011 - 12:50

Great article Marcin, thanks and especially for references.

IF only Ciso VTI could be vendor-independent and work with say Checkopint VTI and vice versa reliably and not as a lab exercise for geeks ...

Yuri

fdetienn Thu, 06/21/2012 - 08:45 (reply to yuri_slobodyanyuk)

Hi Yuri,

If you are still experiencing issues, could you please open a case with us (mention my name) or contact your account team ? This would allow us to determine where the difficulties are stemming from. If it can be made to work and there is interest in interop, we could create such documents and/or improve the interoperability.

best regards,

  Fred

alexhartmaier Mon, 01/24/2011 - 01:07

The feature is useless until you can configure the interesting traffic to be compatible with other vendors which is the main usage of IPSec in our business.

Marcin Latosiewicz Mon, 01/24/2011 - 01:24 (reply to alexhartmaier)

Alexander,

Thanks for bringing this up.

As you mention there is right now problem with interoperability between vendors (not the first time) for SVTI, but people DID get some of the solutions working. I would suggest to contact you account team to push for this, problems like this don't solve by themselves ;-)

I do not agree with you in case of DVTI, it works very well in stand alone scenario AND when/if remote end has DVTI, I have not tested this with other vendors' equipment. But I would not call it useless.

alexhartmaier Mon, 01/24/2011 - 01:36 (reply to Marcin Latosiewicz)

Thanks for the quick answer Marcin!

We only use SVTI to connect to other companies which means the other endpoint is often not Cisco and also not under our control.

VTI always sends 0.0.0.0/0 as interesting traffic which would route all traffic through the tunnel on the other endpoint which makes it useless.

fdetienn Wed, 06/20/2012 - 19:21 (reply to alexhartmaier)

Hi Alexander,

this is correct if the remote peer has a crypto map implementation style.

Other major and minor vendors than Cisco have a VTI-like model that is interoperable and I personally configured such systems.

I do understand and value that this does not apply to your specifc case.

Please understand that I do not mean to contradict you but simply get the record straight: VTI is not a vendor specific option but a choice by some vendors to not support this option.

We could settle for the lowest common denominator (we do support that option too and sometimes there is no choice) but whenever the debate can be elevated, it should. This is what Marcin exposed here.

Best regards,

  Frederic Detienne

fdetienn Mon, 07/30/2012 - 22:58 (reply to alexhartmaier)

Hi Alexander,

I do not want to create an inter-vendor discussion  thread and I will not publish any name in public. I could easily  download documentation (technical and data sheet) from at least 3  vendors and 5 products supporting this option. All the vendors I looked  for are direct (major) competitors of Cisco.I found several interop  documents with sample configs on one of the other vendor's web site.

As  agreed with you earlier, it is true some vendors do not implement a  VTI-like solution (at all or only in a limited product range) but some  more implement GRE/IPsec which grows the interoperability even further  (some actually implement both GRE/IPsec and a VTI).

Both  VTI, GRE/IPsec, IPIP/IPsec or any interface based VPN integrate very  well in network environments. Everything Marcin explains applies to  these.

I fully realize this may not work on your  equipment and we are not throwing any stones but when possible this is the solution we recommend. For all other scenarios, we  obviously support the crypto map model but our stastics show this to be  case generator (misconfigs) and we find the maintenance to be costlier  for our users. We think this is the best advice we can provide.

Best regards,

  Fred

Actions

Login or Register to take actions

This Blog

Posted December 5, 2010 at 12:53 PM
Stats:
Comments:10 Avg. Rating:5
Views:12253   
Shares:0

Related Content

Blogs Leaderboard