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.
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.
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!
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.
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...
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.
SVTI configuration example:
DVTI ezvpn server configuration example:
DVTI ezvpn client configuration example:
VTI with webvpn configuration example:
Post a comment :-)