If you are building a brand new site-to-site tunnel in 2026, this is the one you should build: IKEv2 for the control plane, AES-GCM-256 for the data plane, and a static VTI for the forwarding plane. No crypto ACL. No proxy-ID mismatch at 2am. No legacy cipher suite that a scanner will flag next quarter. Just a routable tunnel interface that happens to be encrypted. This article is part of the PingLabz IPsec VPN cluster, and it is the config we would hand someone on day one.
Everything below was captured on a real lab: a cat8000v HUB at 203.0.113.1 talking to a cat8000v SPOKE1 at 198.51.100.2, both on IOS XE 17.18.02, with an ISP router in between. Every line of CLI output on this page came off those boxes.
Why This Combination and Not Another
There are four moving decisions in a site-to-site build, and most of the bad tunnels in the world got at least one of them wrong.
The alternative build, IKEv2 bolted onto a crypto map, still works and we lab it out here because you will meet it on brownfield gear. But if nothing is forcing you into a crypto map, do not choose one voluntarily.
The Complete Build, Bottom to Top
The whole config is five blocks. Read it once and it fits in your head.
1. The IKEv2 proposal and policy
The proposal is the cipher suite offered in IKE_SA_INIT. The policy is the container that decides which proposal applies to which peers.
crypto ikev2 proposal PLZ-IKEV2-PROP
encryption aes-gcm-256
prf sha256
group 19
crypto ikev2 policy PLZ-IKEV2-POL
proposal PLZ-IKEV2-PROPNotice what is missing: there is no integrity line. With AES-GCM you configure a PRF and no integrity algorithm, because GCM does integrity itself. IOS XE will tell you this out loud while you are typing an incomplete proposal:
IKEv2 proposal MUST either have a set of an encryption algorithm other than aes-gcm, an
integrity algorithm and a DH group configured or
encryption algorithm aes-gcm, a prf algorithm and a DH group configuredThat is not an error, it is a hint, and it is the AEAD rule stated in the CLI. Group 19 is a 256-bit ECP curve (a sane 2026 floor).
2. The keyring
Where the pre-shared key lives, scoped to a peer address.
crypto ikev2 keyring PLZ-KEYRING
peer SPOKE1
address 198.51.100.2
pre-shared-key PingLabz-IKEv2-PSK-013. The IKEv2 profile
The profile is the glue: it says which remote identities we accept, what identity we present, how both sides authenticate, and which keyring to use.
crypto ikev2 profile PLZ-IKEV2-PROF
match identity remote address 198.51.100.2 255.255.255.255
identity local address 203.0.113.1
authentication local pre-share
authentication remote pre-share
keyring local PLZ-KEYRINGBoth authentication local and authentication remote are required. IKEv2 authentication is asymmetric by design (each side independently states how it proves itself), which is exactly why you can later move one side to certificates without touching the other.
4. The IPsec profile (this is the line people miss)
The transform set defines the data-plane cipher. The IPsec profile binds that transform set and the IKEv2 profile together, and then the tunnel interface consumes the whole bundle.
crypto ipsec transform-set PLZ-TS-GCM esp-gcm 256
mode tunnel
crypto ipsec profile PLZ-IPSEC-PROF
set transform-set PLZ-TS-GCM
set ikev2-profile PLZ-IKEV2-PROFThat set ikev2-profile PLZ-IKEV2-PROF line inside crypto ipsec profile is the single most commonly forgotten command in this entire build. Leave it out and IOS will happily accept the config, bring the tunnel interface to up/up (it is a tunnel, it does not need crypto to be line-protocol up), and then quietly fall back to whatever default IKEv2 profile logic it can find instead of the one you carefully wrote. If your proposal, keyring, or identity settings are not being honoured, check this line before you check anything else.
5. The tunnel interface
interface Tunnel1
ip address 10.0.1.1 255.255.255.252
tunnel source GigabitEthernet2
tunnel mode ipsec ipv4
tunnel destination 198.51.100.2
tunnel protection ipsec profile PLZ-IPSEC-PROFTwo lines carry all the weight. tunnel mode ipsec ipv4 makes this an IPsec VTI rather than a GRE tunnel (get this wrong and you have built GRE-over-IPsec, which is a different thing with different overhead). tunnel protection ipsec profile attaches the crypto. That is it. There is no crypto map anywhere in this config, and no interface on the router has one applied.
Steering Traffic In: Routing, Not a Crypto ACL
With a crypto map, you tell the router what to encrypt by writing an access list, and the far end has to write the mirror image of it. Get the mask wrong on one side and you get a proxy-ID mismatch, which produces a tunnel that negotiates phase 1 beautifully and then refuses to pass a single packet.
With a VTI, you tell the router what to encrypt by routing it out the tunnel:
ip route 10.30.10.0 255.255.255.0 Tunnel1That is the entire traffic-selection policy. Anything the routing table hands to Tunnel1 gets encrypted; anything it does not, does not. Because the VTI is a real Layer 3 interface, an IGP works exactly as well: run OSPF or EIGRP over the tunnel and let the far end advertise its own prefixes. You can also apply an output service policy, a QoS shaper, NetFlow, or an ACL to Tunnel1 like any other interface. None of that is possible on a crypto map, where the encryption is a property of the physical interface and the "tunnel" is not an object you can point at.
Verification: What Correct Looks Like
Bring the tunnel up with interesting traffic and check three things.
Does it pass traffic?
HUB#ping 10.30.10.1 source Loopback10 repeat 5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/12/17 msIs the interface actually an IPsec tunnel?
HUB#show interface Tunnel1
Tunnel1 is up, line protocol is up
Tunnel protocol/transport IPSEC/IP
Tunnel transport MTU 1446 bytesTunnel protocol/transport IPSEC/IP confirms tunnel mode ipsec ipv4 took effect. If you see GRE/IP there, you built a GRE tunnel and wrapped it in IPsec, which is not what this article is about.
What is the crypto session actually protecting?
HUB#show crypto session detail
Session status: UP-ACTIVE
Peer: 198.51.100.2 port 500 fvrf: (none) ivrf: (none)
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Inbound: #pkts dec'ed 5 drop 0 life (KB/Sec) 4607999/3576
Outbound: #pkts enc'ed 5 drop 0 life (KB/Sec) 4607999/3576Look at that IPSEC FLOW line. permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 is any-to-any. The VTI negotiates a wildcard traffic selector, which is precisely why there is no crypto ACL to mismatch. Both ends agree to protect "everything that arrives on this interface", and the routing table decides what arrives. If you have ever spent an afternoon diffing two crypto ACLs across a change window, that one line is the payoff for the whole design.
The MTU Detail Nobody Measures: 1446 vs 1438
Most articles hand-wave IPsec MTU with a vague "expect around 1400". We measured it, twice, on the same platform, and the number moved with the cipher.
Same platform, same tunnel type, same physical MTU of 1500. The only variable is the cipher, and the difference is 8 bytes. A CBC + SHA-256 ESP packet has to carry a truncated HMAC field on top of the encrypted payload. A GCM packet does not: the authentication tag is part of the AEAD construction and the ESP overhead is smaller. Eight bytes will not save your network on its own, but it is a concrete, checkable demonstration that AEAD is not just a security argument, it is a wire-efficiency argument too. And it is a good sanity check: if your GCM VTI is not showing 1446 on IOS XE with a 1500-byte underlay, something in the stack is not what you think it is.
Why AES-GCM, Specifically
AES-GCM is an AEAD cipher: authenticated encryption with associated data. Confidentiality and integrity are produced by a single pass over the data instead of "encrypt, then compute a separate HMAC over the ciphertext". Three consequences you can see:
- It shows up in the SA as an absence. The IKEv2 SA reads
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, and the child SA readsEncr: AES-GCM, keysize: 256, esp_hmac: None.Hash: Noneis not a misconfiguration, it is the point. - It is hardware-friendly. Modern CPUs and ASICs implement AES-GCM natively, and the single-pass design parallelises where encrypt-then-MAC does not.
- It is smaller on the wire. See the 8 bytes above.
The one thing to respect: GCM is unforgiving about IV/nonce reuse. That is a job for the implementation, not for you, but it is the reason you should be running current code rather than an image from 2015.
Where This Design Stops Working
Be honest about the ceiling. A static VTI is one tunnel interface per peer. Every remote site needs its own Tunnel interface, its own tunnel destination, and its own routing. Add a keyring entry per peer, or accept a wildcard PSK you probably do not want.
At three sites, that is fine. It is explicit, greppable, and trivially troubleshootable, and you should not over-engineer it. At ten sites it is annoying. At thirty sites it is a config-management problem you have invented for yourself, and if you also want spoke-to-spoke traffic, static VTIs cannot give it to you without a full mesh (n(n-1)/2 tunnels, which is a number that stops being funny fast).
That is exactly the gap FlexVPN and DMVPN exist to fill. Both replace the per-peer static tunnel with a dynamic one: a single virtual-template or mGRE interface that spawns tunnels on demand, with hub-pushed routing (FlexVPN's IKEv2 authorization policy) or NHRP-driven spoke-to-spoke shortcuts (DMVPN Phase 3). The crypto you learned here does not change; the encapsulation and the tunnel lifecycle do.
Hardening Checklist
match identity remote plus a wildcard PSK is how you accidentally build an open VPN concentrator.ip tcp adjust-mss on the tunnel if you have TCP applications and a path that eats ICMP fragmentation-needed messages.Key Takeaways
- IKEv2 + AES-GCM-256 + static VTI is the default 2026 site-to-site build. Route-based, AEAD, and short enough to read on one screen.
- The IPsec profile is the join.
set transform-setgives it the cipher,set ikev2-profilegives it the IKEv2 policy. Forgetting the second line is the classic failure. - The tunnel interface needs two magic lines:
tunnel mode ipsec ipv4andtunnel protection ipsec profile. Verify withTunnel protocol/transport IPSEC/IP. - There is no crypto ACL.
show crypto session detailproves it:IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0. Routing selects the traffic, and an IGP over the VTI works because the VTI is a real interface. - AEAD is measurable. GCM gave us a 1446-byte transport MTU where CBC + SHA-256 gave 1438 on the same platform. Eight bytes, because GCM carries no separate HMAC, which is also why the SA reads
Hash: None. - One static VTI per peer. Fine at three sites, painful at thirty. That is what FlexVPN and DMVPN are for.
Build this one first, get comfortable with what a healthy show crypto session detail looks like, and then go read the rest of the IPsec VPN cluster to see how the same crypto gets reused underneath the dynamic designs.
