Data Centre for Cisco Network Security

VTI VPNs introduced to Cisco ASA 9.7.x

Data Centre for Cisco Network Security

Virtual Private Networks constitute a hot topic in networking because they provide low cost and secure communications between sites (site-to-site VPNs) whilst improving productivity by extending corporate networks to remote users (remote access VPNs). Naturally the VPN technology is widely deployed on all internet edge devices and most ASAs.

Cisco is very proud of its VPN solutions. It’s one of the few vendors that support such a wide range of VPN technologies with so many features and flexibility. Cisco Routers and Cisco ASA Firewalls are the two types of devices that are used most often to build Cisco Virtual Private Networks.  Cisco has been very strict about the way its routers and firewalls should be used and what technologies are available to them – routers will do the full range of Site-To-Site of VPNs: Traditional (Policy-based) IPsec VPNs, but also GRE IPsec VPNs, DMVPNs, GET VPNs, and have limited capabilities for the remote access VPNs: IPsec and SSL based. However, the ASA is very different so far it could do just traditional policy based L2L IPsec VPN but will have the full functionality for remote based VPNs. The message was very clear, for large organization and ISP use Routers for remote access VPN and static traditional Site-to-Site use the ASAs.

Things changed, Cisco very recently introduced a new feature with its 9.7.x code in the VPN module of the ASA – the VTI (Virtual Tunnel Interface). VTI were long available in Cisco Routers but never in Cisco Firewalls but similar technologies (Route-Based VPNs) were available in most competitors and the demand for that features finally took effect on Cisco and they introduced it.

Now before understanding why VTI are so important we will do a quick comparison between the traditional Site-to-Site IPsec VPN (Policy Based VPNs) and the VTI (Route-Based VPNs)

Policy Based VPNs

They rely on static (policy based) configuration of the encryption domain (usually by ACLs) and do not pass multicasts, not great for dynamic routing and voice/video and other multicast applications and requires re-configuration on both sides if the networks that traverse the VPN should change. The configuration is quite complex involving many steps that need to be same or mirrored (encryption domains/ACL config) and that is prone to mistakes.

However, the benefits are that this is a well matured configuration process and the IPsec VPN is a IETF standard which means all vendors must implement it according to the specifications of the standard, hence in theory it should always work between in multivendor scenarios. This is important because the two main uses of L2L (Site-to-Site) VPNs is connecting same company sites over internet thus replacing more expensive intranets or connecting one company to another company/partner/provider of services over Internet in a secure manner. In that second case, there is a big chance that both companies will use different vendors for VPN devices.

Route-Based VPNs

A route-based VPN configuration uses Layer3 routed tunnel interfaces (either GRE based or VTI based) as the endpoints of the VPN. Instead of selecting a static subset of traffic to pass through the VPN tunnel using an Access List, all traffic passing through the special Layer3 tunnel interface is placed into the VPN. Therefore, you need to configure routing accordingly. Either a dynamic routing protocol (such as EIGRP or OSPF) or static routing must be configured to divert VPN traffic through the special Layer3 tunnel interface. That makes the selection of interesting traffic dynamic and you have the flexibility to perform changes and introduce new traffic to the VPN without redoing the VPN configuration (only by changing the routing so new traffic gets routed to the interface). Another benefit is that this type of VPN can pass multicast traffic thus allowing dynamic routing protocols and enabling multicast applications to work.

There are some limitation and considerations that need to be taken in mind. First VTI is a proprietary to Cisco technology, despite other vendors having similar route-based VPN technology, there is no guarantee these will work between each other. Also, the tunnel interface itself does not provide inherited security, IPsec protection is an add-on and needs to be configured on top for encryption/security of traffic.

Summary and conclusions:

Introducing VTIs in ASAs is a big step forward in making the firewall an even more versatile network edge device. The VTI capability to provide security and encryption on multicast traffic and its flexibility for tunneling the traffic via dynamic routing with zero reconfiguration on the VPN, means that any small or middle-sized organization with ASA on network edge can now benefit very strongly from that functionality and would not need to purchase additional hardware thus maximizing its return on investment value.

References:

Release notes:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/release/notes/asarn97.html#ID-2172-00000128

Configuration:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/configuration/vpn/asa-97-vpn-config/vpn-vti.html

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *