This document describes how to configure VTI ( Virtual Tunnel Intrfaces) between two ASAs (Adaptive Security Appliances) with use of IKEv2 (Internet Key Exchange version 2) protocol to provide secure connectivity between two branches. Both of the branches have two ISP links for high availablility and load balancing purposes. Border Gateway Protocol (BGP) neighborship is established over the tunnels in order to exchange internal routing information. This feature is introduced in ASA version 9.8(1). ASA VTI implementation is compatible with VTI implementation available on IOS routers.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on ASAv firewalls running 9.8(1)6 software version.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Differences between VTI and Crypto Map
Crypto map is an output feature of the interface. In order to send the traffic through crypto map based tunnel, the traffic needs to be routed to the internet facing interface (traditionally called outside interface) and must be matched against crypto ACL. On the other hand, VTI is a logical interface. Tunnel to every VPN peer is represented by a different VTI. If the routing points towards VTI, the packet will be encrypted and sent to the corresponding peer.
VTI eliminates the need to use crypto access lists and Network Address Translation (NAT) exemption rules.
Crypto map Access Control List (ACL) does not allow for overlapping entries. VTI is a route based VPN and regular routing rules apply for the VPN traffic, which simplifies configuration and processes to troubleshoot.
Crypto map automatically prevents traffic between sites to be sent in cleartext if tunnel is down. VTI does not automatically protect against it. Null routes need to be added to ensure equal functionality.
Note: This example is not suitable for the scenario where the ASA is a member of independed autonomous system and has BGP peerings with ISP networks. It covers the topology where ASA has two independent ISP links with public addresses from different autonomous systems. In such case, ISP may deploy anti-spoofing protection that verifies if the received packets are not sourced from public IP that belongs to another ISP. In this configuration, proper measures are taken to prevent this.
The primary link is ISP A interface. ISP B is secondary. The primary link availability is tracked with use of ICMP ping request to a host in the internet, in this example the ASAs use each other ISP A interface as ping destination:
The primary VTI is always established over the ISP A. Secondary VTI is established over ISP B. Static routes towards tunnel destination are needed. This ensures that the encrypted packets leave from the correct physical interface to avoid ISP anti-spoofing drops:
13. (Optional) By default, the ASA BGP process sends keepalives once per 60 seconds. If the keepalive response is not received from the peer for 180 seconds, it is declared dead. In order to speed up the detection neigbor failure, you can configure BGP timers. In this example, the keepalives are sent every 10 seconds and neighbor is declared down after 30 seconds.
ASA-right(config)# show bgp summary BGP router identifier 203.0.113.1, local AS number 65000 BGP table version is 29, main routing table version 29 3 network entries using 600 bytes of memory 5 path entries using 400 bytes of memory 5/3 BGP path/bestpath attribute entries using 1040 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 2040 total bytes of memory BGP activity 25/22 prefixes, 69/64 paths, scan interval 60 secs
Verify routes received from BGP. Routes marked with ">" are installed in the routing table:
ASA-right(config)# show bgp
BGP table version is 29, local router ID is 203.0.113.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path *>i192.168.1.0 10.1.1.2 0 100 0 i * i 10.1.2.2 0 80 0 i *> 192.168.2.0 0.0.0.0 0 32768 i * i192.168.10.0 10.1.1.2 0 100 0 ? *>i 10.1.2.2 0 200 0 ?
Verify routing table:
ASA-right(config)# show route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, + - replicated route Gateway of last resort is 198.51.100.2 to network 0.0.0.0
S* 0.0.0.0 0.0.0.0 [1/0] via 198.51.100.2, ispa S 10.0.0.0 255.0.0.0 is directly connected, Null0 C 10.1.1.0 255.255.255.0 is directly connected, tuna L 10.1.1.1 255.255.255.255 is directly connected, tuna C 10.1.2.0 255.255.255.0 is directly connected, tunb L 10.1.2.1 255.255.255.255 is directly connected, tunb S 172.16.0.0 255.240.0.0 is directly connected, Null0 S 192.168.0.0 255.255.0.0 is directly connected, Null0 B 192.168.1.0 255.255.255.0 [200/0] via 10.1.1.2, 00:02:06 C 192.168.2.0 255.255.255.0 is directly connected, inside L 192.168.2.1 255.255.255.255 is directly connected, inside B 192.168.10.0 255.255.255.0 [200/0] via 10.1.2.2, 00:02:35 C 198.51.100.0 255.255.255.252 is directly connected, ispa L 198.51.100.1 255.255.255.255 is directly connected, ispa S 198.51.100.129 255.255.255.255 [1/0] via 198.51.100.2, ispa C 203.0.113.0 255.255.255.252 is directly connected, ispb L 203.0.113.1 255.255.255.255 is directly connected, ispb S 203.0.113.129 255.255.255.255 [1/0] via 203.0.113.2, ispb