Sooner or later someone hands you two routers, two sites, and "encrypt the traffic between them." On Cisco IOS XE you have two mainstream ways to do it: a crypto map or a virtual tunnel interface (VTI). Same IKE, same ESP, same transform set, same pre-shared key. Very different networks. This is the article you read when you have to pick. For wider context, start at the IPsec VPN pillar.
We did not get this from a doc. We built both designs in CML, on the same two routers (EDGE1 and EDGE2), carrying the same ping between the same two LANs, and captured what each one produced. Every piece of CLI below is real output from that lab. The difference shows up in one line of show crypto session detail, and the whole comparison falls out of it.
The one difference that explains everything
A crypto map is policy-based. You write an access list describing interesting traffic and bolt the map to the physical outside interface. The rule is: "if a packet leaving Gi2 matches this ACL, encrypt it to this peer."
A VTI is route-based. You build a tunnel interface, set tunnel mode ipsec ipv4, protect it with an IPsec profile, and route traffic into it. The rule is: "anything routed out Tunnel0 leaves encrypted."
That is not a syntax preference. It changes what the tunnel can carry, how you operate it, and how it fails.
Proxy IDs: two narrow flows versus one wide one
This is the contrast that is the article. Our crypto ACL on EDGE1 had two lines, one per LAN. Two ACL lines, two proxy identities, two SA pairs. The real session on the crypto map build, after live traffic from both source networks:
EDGE1#show crypto session detail
Interface: GigabitEthernet2
Session status: UP-ACTIVE
Peer: 198.51.100.2 port 500 fvrf: (none) ivrf: (none)
IKEv1 SA: local 203.0.113.1/500 remote 198.51.100.2/500 Active
IPSEC FLOW: permit ip 10.20.10.0/255.255.255.0 10.30.10.0/255.255.255.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 10 drop 0 life (KB/Sec) 4607998/3516
Outbound: #pkts enc'ed 10 drop 0 life (KB/Sec) 4607999/3516
IPSEC FLOW: permit ip 192.168.99.0/255.255.255.0 10.30.10.0/255.255.255.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 7 drop 0 life (KB/Sec) 4607999/3562
Outbound: #pkts enc'ed 7 drop 0 life (KB/Sec) 4607999/3562Now the same two routers, same ping, same ESP, rebuilt as a static VTI:
EDGE1#show crypto session detail
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 18 drop 0
Outbound: #pkts enc'ed 14 drop 0One flow. Any to any. The VTI does not care what is inside the packet: if it arrived on Tunnel0, it gets encrypted. (Ignore the cosmetic origin: crypto map string, IOS reuses the internal database. There is no crypto map in the VTI config.)
Everything else follows from those two blocks. A new subnet behind the crypto map means a new ACL line on both ends and a renegotiated SA pair. Behind the VTI it means a route. Full builds: site-to-site IPsec with crypto maps and static VTI (SVTI) IPsec.
Routing protocols: the VTI has a neighbor, the crypto map cannot
A crypto ACL matches unicast flows between subnets. OSPF hellos are multicast to 224.0.0.5, sourced by the router itself: they do not match your crypto ACL, they are not "interesting traffic," and there is no interface to run OSPF on because the map lives on the public WAN port. You cannot form an adjacency across a crypto map. The VTI is a genuine interface, so it just works:
EDGE1#show interface Tunnel0
Tunnel0 is up, line protocol is up
Tunnel source 203.0.113.1 (GigabitEthernet2), destination 198.51.100.2
Tunnel protocol/transport IPSEC/IP
Tunnel transport MTU 1438 bytes
EDGE1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.255.0.2 0 FULL/ - 00:00:31 10.0.0.2 Tunnel0
EDGE1#ping 10.30.10.1 source Loopback10 repeat 5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 15/20/35 msFULL adjacency, over an encrypted tunnel, no crypto ACL anywhere. Pick a crypto map and you are signing up for static routes forever, hand-maintained at both ends, plus a matching pair of ACL lines per prefix. On two sites that is annoying. On twenty it is a job.
Config size: same security, a fraction of the lines
The crypto map build needs an ISAKMP policy, a PSK, a transform set, a crypto ACL, a crypto map (peer, transform, PFS, match), and the map bound to the physical interface:
crypto isakmp policy 10
encryption aes 256
hash sha256
authentication pre-share
group 14
lifetime 3600
crypto isakmp key PingLabz-L2L-PSK-01 address 198.51.100.2
crypto ipsec transform-set PLZ-TS-AES256 esp-aes 256 esp-sha256-hmac
mode tunnel
ip access-list extended PLZ-CRYPTO-ACL
permit ip 192.168.99.0 0.0.0.255 10.30.10.0 0.0.0.255
permit ip 10.20.10.0 0.0.0.255 10.30.10.0 0.0.0.255
crypto map PLZ-CMAP 10 ipsec-isakmp
set peer 198.51.100.2
set transform-set PLZ-TS-AES256
set pfs group14
match address PLZ-CRYPTO-ACL
interface GigabitEthernet2
crypto map PLZ-CMAPThe VTI keeps the ISAKMP policy, key and transform set (that is the crypto, not the design), drops the ACL and the map, and replaces them with this:
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
tunnel source GigabitEthernet2
tunnel mode ipsec ipv4
tunnel destination 198.51.100.2
tunnel protection ipsec profile PLZ-IPSEC-PROFSix lines. Same AES-256, same SHA-256, same PFS group 14, same peer. What you deleted was not security, it was bookkeeping.
Operations: you can actually see a VTI
A tunnel interface is a first-class interface, with day-two consequences nobody mentions until the outage.
- Counters and state.
show interface Tunnel0gives line protocol, MTU, drops and rates. A crypto map has no interface, so "is the VPN up" means squinting at SA counters. - MTU is visible. The SVTI reports 1438 bytes transport MTU (1476 for plain GRE with its 4-byte header).
- Per-tunnel QoS. You can attach a service policy to a tunnel interface. You cannot attach one to "traffic that matched ACL line 2."
- Independent shut / no shut, without touching the WAN port every other service rides on.
- Routing metrics. It has a cost, so failover is just routing.
The failure modes crypto maps own
The number one cause of site-to-site VPN failures is the mirror-image crypto ACL. Both ends must describe the same flows in exact reverse. Get one line wrong and Phase 1 comes up beautifully while Phase 2 dies. We broke it on purpose:
EDGE2#show logging
Crypto mapdb : proxy_match
map_db_find_best did not find matching map
crypto_mapdb_find_map Fail to find matching policy ivrf 0, fvrf 0, flags 129,
ike_profile NULL, local_proxy 10.30.10.0, remote_proxy 10.20.10.0,
km_local 198.51.100.2, km_remote 203.0.113.1
ISAKMP-ERROR: (1018):IPSec policy invalidated proposal with error 32
ISAKMP-ERROR: (1018):phase 2 SA policy not acceptable! (local 198.51.100.2 remote 203.0.113.1)
ISAKMP-ERROR: (1018):deleting node 1949939457 error TRUE reason "QM rejected"Error 32 means the proxy identities do not match. Worse, the side whose ACL no longer matches does not even try: it sends the packet in the clear and it gets dropped upstream. The reported symptom is "nothing happens." Then IOS twists the knife when you go to fix it:
EDGE2(config)#ip access-list extended PLZ-CRYPTO-ACL
%ACL PLZ-CRYPTO-ACL can not be modified/deleted, as it is used in crypto-map PLZ-CMAP
%Please first remove the ACL from crypto map or remove the crypto map from the interface
% Cannot modify this ACL.You have to pull the map off the interface (dropping the production tunnel) to edit the ACL. A VTI cannot fail this way: it has no crypto ACL to mismatch.
The second trap, hit by accident in the lab: a static crypto map entry shadowing a dynamic one. EDGE1 had a static entry whose ACL matched the proxy pair but whose peer was the old public address. IOS matched the static entry first, saw the peer did not match, and rejected instead of falling through to the dynamic entry:
IPSEC(ipsec_process_proposal): peer address 198.51.100.6 not found
ISAKMP-ERROR: (1011):IPSec policy invalidated proposal with error 64
ISAKMP-ERROR: (1011):phase 2 SA policy not acceptable! (local 203.0.113.1 remote 198.51.100.6)Error 64 means the peer address was not found in any crypto map entry. Crypto map ordering is policy evaluation, and policy evaluation has precedence bugs. A route-based tunnel has no policy list to get wrong. Full fault catalogue: troubleshooting IPsec VPNs.
When a crypto map is still the right answer
"Always use a VTI" is a slogan, not engineering. Crypto maps are still correct in real situations:
- Interop with a policy-based peer. Plenty of third-party and legacy firewalls only negotiate specific proxy IDs. Offer any/any and they reject it. You match their design or there is no tunnel.
- A peer that will not do VTI. The far end is often not yours to change.
- Existing deployments you cannot touch. A working crypto map inside a change freeze is not this quarter's problem.
- A responder taking connections from many unknown peers. The dynamic crypto map is the classic hub-side pattern for spokes on dynamic addresses.
The decision
Need multicast and the GRE header? GRE over IPsec is the middle ground.
Key Takeaways
- Policy-based versus route-based is the whole story. A crypto map encrypts traffic matching an ACL. A VTI encrypts whatever you route out the interface.
- The proxy IDs prove it. Same routers, same traffic: the crypto map negotiated two narrow IPSEC FLOWs (one per ACL line), the SVTI negotiated one,
permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0. - Only the VTI runs a routing protocol. FULL OSPF adjacency across the encrypted tunnel. A crypto map cannot carry multicast hellos, so you get static routes forever.
- Six lines versus a page, with no loss of security (same AES-256, SHA-256, PFS group 14).
- Crypto maps own the ugliest failure mode: mirror-image ACL drift, error 32, Phase 1 up while Phase 2 dies. A VTI has no crypto ACL to mismatch. Error 64 (a static entry shadowing a dynamic one) is the other to know.
- Default to a VTI. Reach for a crypto map only when the peer, the vendor or the change process forces you to.
Both designs, both captures, and the rest of the IKE and NAT-T story: the IPsec VPN pillar.
