Advantages of VTI configuration for IPSec tunnels.

Marcin Latosiewicz · ‎12-05-2010

[toc:faq]

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.

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.

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!

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.

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.

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

Comments? Feedback? Flames?

Post a comment :-)

Jean Paul Enerst · ‎12-14-2010

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

Marcin Latosiewicz · ‎12-16-2010

Hi Jean,

Thanks for your comment. Hopefully new content will also be interesting :-)

FYI, I think SDM is not much under development and CCP is the replacement, not sure how much easier to work with it is:

http://www.cisco.com/en/US/products/ps9422/index.html

Marcin

yuri_slobodyanyuk · ‎01-18-2011

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

Alexander Hartmaier · ‎01-24-2011

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 · ‎01-24-2011

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.

Alexander Hartmaier · ‎01-24-2011

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.

Frederic Detienne · ‎06-20-2012

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

Alexander Hartmaier · ‎06-21-2012

Hi Frederic,

can you point me at a list of vendors/models that also support such a config style?

Frederic Detienne · ‎06-21-2012

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

Frederic Detienne · ‎07-30-2012

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

harish.pal · ‎02-04-2016

Hi All,

Have a Question.

have CISCO 2900 series ISR Router and CISCO ASA.

Does CISCO ASA support Virtual tunnel Interface IPSec VPN?

if yes could you please help me to get the configuration.

Thank you.

Regards,

Harish Pal

nibose · ‎02-17-2016

How different would this be from creating split-tunnel configuration for the VPN client users?

Marcin Latosiewicz · ‎02-17-2016

Split tunnelling being enabled or disabled is a matter of policy typically, this particular example outlines some of advantages of logical interfaces irt traffic flow.

Yes it could solve the u-turn problem by essentially not sending traffic towards the headend, but it requires additional configuration.

It's also worth mentioning that the two features are not exclusive, you can run VTI with split tunnelling.