Static VTI (SVTI): The Modern Way to Build a Site-to-Site VPN

If you are still building site-to-site VPNs with crypto maps in 2026, you are configuring a router the way it was done in 1999. The Static Virtual Tunnel Interface (SVTI) is the modern answer, and the whole idea fits in one command: tunnel mode ipsec ipv4. That single line turns a tunnel interface into a routable, IPsec-protected interface. No crypto ACL. No crypto map. No GRE header. If you want the fundamentals underneath all of this (IKE, ESP, transform sets, proxy IDs), start with the IPsec VPN pillar and come back here.

Everything below was captured on a live CML lab: two cat8000v routers running IOS XE 17.18.02 across a simulated ISP, with the same ping and the same capture point used for the crypto-map build and the GRE over IPsec build. That matters, because the punchline of this article is a direct before-and-after comparison of the same tunnel.

The Mental Shift: Policy-Based vs Route-Based

This is the part that trips people up, so let's be blunt about it.

With a crypto map, you tell the router which traffic to encrypt. You write an extended ACL (the crypto ACL), you attach it to a crypto map entry, you hang the map off a physical interface, and IOS inspects every packet leaving that interface to see if it matches. Match the ACL, get encrypted. Miss the ACL, go out in the clear. The ACL is your policy. That is why this is called policy-based VPN.

With an SVTI, you tell the router nothing about which traffic to encrypt. You build a tunnel interface, you protect it with an IPsec profile, and then you route traffic at it. Anything that gets routed out Tunnel0 is encrypted, because that is what the interface does. Anything routed anywhere else is not. Your routing table is your policy. That is route-based VPN.

The One-Line Change (and the Warning IOS Prints)

Our lab already had a GRE tunnel with tunnel protection ipsec profile applied (that is classic GRE over IPsec). Turning it into an SVTI is exactly one command on the tunnel interface:

EDGE1(config-if)#tunnel mode ipsec ipv4
%WARNING: The tunnel mode has been modified while the tunnel protection is already active.
It is recommended to run "shutdown" and "no shutdown" on Tunnel0 interface to refresh the config.

Read that warning carefully, because it is one of the most useful things IOS XE will tell you all day. You just changed the encapsulation on an interface that already has an active IPsec SA bound to it, and the crypto engine does not silently rebuild itself. Until you bounce the interface (shutdown, then no shutdown, on Tunnel0), you can be staring at a config that says one thing and a data plane that is doing another. In a lab this costs you three seconds. In production it is a change-window item, and it is the single most common reason someone says "I converted to VTI and nothing changed." The mode changed. The tunnel did not.

Proof #1: The Interface Is No Longer GRE

Before the change, the tunnel was GRE. After it, the same interface reports a different transport entirely:

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          <-- was GRE/IP
  Tunnel transport MTU 1438 bytes             <-- was 1476 (no 4-byte GRE header)

Two lines, two facts.

"Tunnel protocol/transport IPSEC/IP" means the interface is no longer wrapping your packets in a GRE header and then handing that to IPsec. IPsec is the encapsulation now. There is no inner GRE at all.

Transport MTU 1438 versus 1476. A 1500-byte Ethernet MTU minus a 20-byte outer IP header minus a 4-byte GRE header gives you the classic 1476 GRE figure. Drop the GRE header and the accounting changes: IOS now reports 1438, which is exactly the same number the crypto engine reported as plaintext mtu 1438 in show crypto ipsec sa on the crypto-map build. That is not a coincidence. With SVTI the interface MTU and the crypto MTU are the same thing, because the interface is the crypto boundary. With GRE over IPsec they were two separate accounting layers stacked on each other, and reconciling them by hand is where fragmentation bugs are born.

Proof #2: OSPF Still Comes Up (This Surprises People)

There is a widespread belief that the moment you drop GRE you lose multicast, therefore you lose your routing protocols, therefore you are back to static routes. It is a reasonable fear (raw IPsec tunnel mode really is a unicast, IP-only transport) and on IOS XE it is simply not what happens. The IPsec VTI still carries the IGP:

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

FULL, over Tunnel0, with GRE gone. Same adjacency we had on the plain GRE tunnel, same adjacency we had on GRE over IPsec. The VTI is treated as a real point-to-point interface by the IP stack, so OSPF's hellos get handled and the neighbor forms.

This kills the last honest argument for GRE over IPsec on a simple two-site design. You used to need GRE for one reason: to give multicast and non-IP traffic a ride through IPsec. If your only non-unicast requirement is an IPv4 IGP, an SVTI covers it. (If you genuinely need to carry multicast user traffic, or a non-IP protocol, GRE is still your answer, and that is exactly the call the crypto maps vs VTI decision guide walks through.)

And the data plane works, on the same ping we have been running all lab:

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 ms

Proof #3: The Defining SVTI Capture

This is the one. If you remember nothing else from this article, remember this output:

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     <-- ANY/ANY. No crypto ACL.
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 18 drop 0
        Outbound: #pkts enc'ed 14 drop 0

permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0. Any source, any destination. That is the proxy ID the SVTI negotiated with the peer, and we never wrote an ACL to produce it. The tunnel does not care what is inside the packets. It encrypts whatever the routing table sends it.

Now put that next to what the same two routers negotiated when they were running a crypto map with a two-line crypto ACL:

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/3562

Two crypto ACL lines produced two separate IPSEC FLOWs, each with its own SA pair. The SVTI produced one, and it covers everything. Same peers, same transform set, same IPsec profile. The only difference is how traffic gets selected.

(Yes, origin: crypto map still shows up in the SVTI output. That is an internal label IOS uses for the tunnel-protection construct. There is no crypto map anywhere in the configuration.)

Why "One SA Pair, Any/Any" Scales Better

The crypto ACL is not just ugly. It is a scaling liability, and it fails in a specific, miserable way.

That third row is the killer. In the troubleshooting section of this same lab, breaking one crypto ACL line produced this:

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)

Error 32 is a proxy-ID mismatch: the two ends disagree about which networks the SA is supposed to cover. It is one of the top reasons a site-to-site VPN that "was working yesterday" is down today, and it exists only because the crypto ACL exists. An SVTI negotiating any/any has nothing to disagree about.

The fourth row is the operational insult on top of it. Try to fix a crypto ACL on a live router:

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.

To add one subnet to your VPN you have to pull the crypto map off the interface (which drops the tunnel), edit the ACL, put the map back, and hope you did the same thing on the far end. With a VTI you type ip route, or you let the IGP do it, and nobody notices.

How You Steer Traffic Into an SVTI

This is the practical question everyone asks next. If there is no crypto ACL, how does the router know to encrypt the branch subnet? It does not "know" anything. You route it. Three options, in rough order of how often you should reach for them:

• An IGP over the tunnel. This is what our lab does. OSPF is adjacent over Tunnel0 (FULL, as shown above), the far end advertises 10.30.10.0/24, our routing table learns it with Tunnel0 as the outgoing interface, and every packet destined there gets encrypted. Add a subnet at the branch and it just shows up. Nothing on the VPN touches crypto.
• A static route out the tunnel. ip route 10.30.10.0 255.255.255.0 Tunnel0. Perfectly fine for a small, stable two-site design where you do not want an IGP across the WAN. It is still route-based, it is just a manual route.
• A default route out the tunnel. ip route 0.0.0.0 0.0.0.0 Tunnel0 gives you full-tunnel backhaul: everything, including internet-bound traffic, goes to the hub encrypted. The any/any proxy ID already supports it, so no crypto change is needed. (Watch for recursive routing here: the tunnel destination itself must stay reachable by a more specific route, not through the tunnel.)

Compare that to the crypto-map world, where "steering" means hand-editing an ACL on two devices and praying they match. The routing table was always the right tool for this job. Route-based VPN just lets you use it.

The Two Things a Crypto Map Simply Cannot Do

Interface counters. A VTI is a real interface. show interface Tunnel0 gives you input and output rates, packet and byte counters, drops, errors, and an up/down line protocol you can track and alarm on. A crypto map has none of this: it is bolted onto a physical interface, and your only visibility is the #pkts encaps counters buried in show crypto ipsec sa. You cannot graph a crypto map in your NMS. You can graph a tunnel interface, because SNMP treats it as an interface like any other.

Per-tunnel QoS. Because the VTI is an interface, you can apply a service policy to it with service-policy output, so you can shape, prioritise, and queue on a per-VPN basis, before encryption. There is no equivalent for a crypto map, because a crypto map is not an interface and there is nothing to attach a policy to. If you are running voice or video over a site-to-site VPN, this alone decides the design. (The QoS cluster covers the policy side.)

There is a quieter third one: an SVTI can be placed in a VRF, given a per-tunnel ip mtu and ip tcp adjust-mss, and treated by every other IOS feature as a normal Layer 3 interface, because that is exactly what it is.

The Complete SVTI Config

Here is the entire tunnel side of a working, IPsec-protected, OSPF-carrying, 100-percent-ping site-to-site VPN. Six lines:

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-PROF

Plus the IPsec profile it references, which is just a transform set and PFS, and is shared by every tunnel on the box:

crypto ipsec profile PLZ-IPSEC-PROF
 set transform-set PLZ-TS-AES256
 set pfs group14

No crypto map. No match address. No ip access-list extended PLZ-CRYPTO-ACL. Nothing bolted onto GigabitEthernet2 at all. The IKE policy and the pre-shared key still exist (an SVTI is still IPsec, and Phase 1 still has to happen), but the entire traffic-selection apparatus is gone.

Where SVTI Stops

SVTI is static: tunnel destination 198.51.100.2 is hard-coded. That is fine for two sites, or a handful of branches homed back to a hub. It is not fine for a full mesh, because a full mesh of N sites means N x (N-1) / 2 statically configured tunnels, and every new site means touching every existing site.

That is the exact problem DMVPN solves, using mGRE and NHRP to build spoke-to-spoke tunnels on demand from a single template interface. FlexVPN takes the same idea further: an IKEv2 framework where the tunnel interfaces are dynamic (virtual-access interfaces cloned from a virtual-template) and the policy is pushed from the hub. Learn SVTI properly and neither one is magic. They are just VTIs with a control plane that builds them for you.

Key Takeaways

• tunnel mode ipsec ipv4 is the whole feature. It converts a tunnel interface from GRE to native IPsec: route-based, no crypto ACL, no crypto map, no GRE header.
• Bounce the interface after changing the mode. IOS XE warns you that it is "recommended to run shutdown and no shutdown on Tunnel0 interface to refresh the config." On an already-protected tunnel, the change does not take effect until you do.
• show interface Tunnel0 is your proof. "Tunnel protocol/transport IPSEC/IP" (not GRE/IP) and transport MTU 1438 (not 1476) confirm the 4-byte GRE header is gone.
• SVTI still carries OSPF. Our lab shows the neighbor FULL over Tunnel0 with GRE removed. Dropping GRE does not mean dropping your IGP on IOS XE.
• IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 is the defining SVTI capture: one any/any SA pair, versus one SA pair per crypto ACL line on a crypto map. Nothing to mismatch, nothing to keep in sync, and error 32 becomes impossible.
• You steer traffic with routing, not ACLs. An IGP over the tunnel, a static route out Tunnel0, or a default route for full-tunnel backhaul. Adding a subnet means adding a route, not editing crypto on both peers.
• A VTI is a real interface. Interface counters, SNMP, and per-tunnel QoS service policies all work. A crypto map cannot do any of them.
• Use SVTI by default for site-to-site. Reach for GRE over IPsec only when you must carry multicast user traffic or non-IP protocols, and move to DMVPN or FlexVPN when the topology outgrows static peers.

Still deciding which design to deploy? The crypto maps vs VTI decision guide puts the options side by side, and the IPsec VPN pillar is the hub for the whole cluster: IKE and ESP fundamentals, the crypto-map build, GRE over IPsec, NAT traversal, and the troubleshooting error-code map. From here the natural next step is DMVPN, where the tunnel you just built stops being static and starts building itself.