IPsec VTI vs Policy-Based VPN: Choosing and Configuring

"Which VPN type should we use?" is really a question about routing. A policy-based VPN with crypto maps encrypts based on an access list that names the interesting traffic, which means the tunnel follows the ACL, not the routing table. A route-based VPN with an IPsec VTI creates a real interface that you route across, and the difference shows up the moment you want dynamic routing, overlapping subnets, or per-tunnel QoS. Here is how to choose, and how to configure each properly.

The architectural difference

The documented trade-off is worth quoting precisely: SVTIs let you enable dynamic routing protocols on the tunnel interface without the extra 24 bytes of GRE header, which is pure efficiency compared to the GRE-over-IPsec design that was once the only way to get routing over a tunnel.

Configuring a static VTI (IKEv2, pre-shared key)

crypto ikev2 proposal IKEv2-PROP
 encryption aes-cbc-256
 integrity sha256
 group 14
!
crypto ikev2 policy IKEv2-POL
 proposal IKEv2-PROP
!
crypto ikev2 keyring KEYRING
 peer BRANCH-1
  address 203.0.113.10
  pre-shared-key local Str0ngL0calKey
  pre-shared-key remote Str0ngRem0teKey
!
crypto ikev2 profile IKEv2-PROF
 match identity remote address 203.0.113.10 255.255.255.255
 identity local address 198.51.100.1
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile IPSEC-PROF
 set transform-set TS
 set ikev2-profile IKEv2-PROF
!
interface Tunnel100
 description VPN to branch-1
 ip address 10.255.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel destination 203.0.113.10
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROF
!
router ospf 10
 network 10.255.0.0 0.0.0.3 area 0

Everything downstream of the tunnel interface behaves normally: the route to the branch subnet points at Tunnel100, and the routing protocol advertises it through the tunnel. No ACL defines "interesting traffic", which removes an entire class of "Phase 2 is up but traffic is not encrypted" problems.

Applying policy to the tunnel

! QoS on the clear-text side belongs on the tunnel interface
class-map match-any VOICE
 match dscp ef
!
policy-map WAN-EGRESS
 class VOICE
  priority percent 30
 class class-default
  fair-queue
!
interface Tunnel100
 service-policy output WAN-EGRESS

This is a genuine practical advantage: on a crypto map design, features for clear-text packets are applied in one place and features for encrypted packets in another, and getting that split wrong means your priority queue never sees the traffic it was meant to protect. With a VTI, clear-text policy lives on the tunnel interface and encrypted policy on the physical outside interface.

When you still want GRE

• Multicast routing or non-IP protocols across the tunnel: IPsec VTI handles IP unicast and multicast only; GRE is more permissive.
• Dynamic VTI for hub-and-spoke with many spokes: the hub uses a virtual template and creates a virtual access interface per spoke, which is the modern replacement for per-spoke crypto maps. On the spoke side you can use a static VTI, and the hub should advertise its VTI address over IKEv2 so routing and path monitoring work in both directions.
• Migrating an existing crypto-map estate: run VTIs for new sites and migrate the LAN-to-LAN maps when convenient — mixing both on one device is supported, but keep tunnel groups distinct to avoid the default tunnel group collision.
• ASA platforms: VTIs are configurable in IPsec mode only; terminating GRE on the ASA is not supported, so a GRE-based design needs a router.

Migration checklist

1. Decide per site, not globally — a small single-subnet site does not need OSPF and a crypto map is fine.
2. For VTIs: configure IKEv2 profile, IPsec profile, tunnel interface, then the route. Verify with show crypto ikev2 sa and show ip route pointing at the tunnel.
3. Number the tunnel interfaces consistently across the estate (Tunnel100 per site is a common convention) so the routing design stays readable.
4. Put clear-text QoS on the tunnel interface and encrypted QoS on the physical interface, then verify with counters.
5. Keep a rollback path: removing a crypto map returns traffic to the old path immediately if the tunnel does not come up.

Rule of thumb: if the design has more than one subnet per peer, any dynamic routing, or any need for per-tunnel policy — use a VTI. The crypto map is for the simple case and nothing else.

Related Reading on This Site

• IPsec IKEv2 Troubleshooting: SA_INIT and IKE_AUTH Debugs
• Cisco ASA Site-to-Site IPsec VPN CLI Configuration
• Palo Alto Site-to-Site IPsec VPN: CLI Configuration

原文链接：https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/sec-vpn/b-security-vpn/m_sec-ipsec-virt-tunnl-0.pdf (Cisco IOS - IPsec Virtual Tunnel Interfaces configuration guide)