Adding a Subnet to IPsec: Crypto Map ACL vs SVTI Route

Adding a subnet to an IPsec VPN exposed the difference between these two builds. With the crypto map, I changed the selectors on both routers and got a second ESP SA pair. With the static VTI, I added one OSPF network statement on site-a. Site-b learned the route without a configuration change, and the existing ESP pair carried the new traffic.

Quick answer from this lab:

• The crypto map needed one new permit line at each end. Changing only site-a left A1 working and A2 failing in both directions.
• This IOL image rejected edits to an attached crypto ACL. Detaching its map reference, editing, and reattaching worked, but flushed the existing SAs. The same error appears on IOS XE cat8000v in our crypto maps vs VTI lab.
• Static VTI OSPF reached FULL across Tunnel35. Adding A2 changed routing at one end; the wildcard selectors and ESP SPIs stayed the same.
• The persistent VTI fault settled at Tunnel35 up/line protocol down, with no OSPF neighbor or learned LAN routes. Restoring the destination recovered forwarding; a later coordinated protection detach/rebind verified GCM on both ends.
• VTI host forwarding worked only after no ip cef on both crypto routers. That is a lab-image quirk observed here, not a production requirement.

The crypto maps vs VTI design comparison covers choosing the design. This exercise concentrates on the change: the same WAN endpoints and hosts, rebuilt both ways, followed by a subnet addition, a partial failure, and recovery.

Topology and addressing

This lab was built in my home lab in Containerlab. Site-a and site-b terminate IPsec through a carrier router. A1 is the original site-a LAN; A2 is the added LAN. Tunnel35 exists only in the VTI build.

All three routers ran Cisco IOL 17.18.2 from the vrnetlab/cisco_iol:17.18.02 image. There was no IOSv fallback. The three hosts used Alpine 3.24.2. Required IKEv2, VTI mode, and tunnel-protection commands were accepted.

The carrier had connected WAN routes only, no default and no routes to the private LANs. Both builds were tested with host ping and HTTP in both directions. Successful router-originated pings alone were insufficient, as the VTI troubleshooting showed.

Use each router's IOS console for the configuration and show commands below. These are excerpts from the recorded configurations and console sessions; a line containing only ... omits whole lines. The redacted PSK fields need the private shared key when reproducing the build.

Shared IKEv2 configuration

Both designs kept the same IKEv2 objects: AES-CBC-256, SHA-256 and group 19, with peer-address identity matching and pre-shared authentication. Site-a's configuration was:

crypto ikev2 proposal PL-IKEV2-PROP 
 encryption aes-cbc-256
 integrity sha256
 group 19
...
crypto ikev2 policy PL-IKEV2-POL 
 proposal PL-IKEV2-PROP
...
crypto ikev2 keyring PL-KEYRING
 peer PL-PEER
  address 198.18.35.5
  pre-shared-key local <redacted-psk>
  pre-shared-key remote <redacted-psk>
...
crypto ikev2 profile PL-IKEV2-PROF
 match identity remote address 198.18.35.5 255.255.255.255 
 authentication remote pre-share
 authentication local pre-share
 keyring local PL-KEYRING

On site-b, the keyring peer address and remote identity match were 198.18.35.1. The final move to GCM changed ESP, while IKEv2 stayed AES-CBC-256/SHA-256/group 19. Keep those layers separate when reading the output. IKEv2 explained covers the exchange; IPsec explained: IKE phases provides the background for reading control-plane state alongside data SAs.

Build 1: crypto map and the original LAN

The baseline used ESP AES-256/SHA-256 in tunnel mode. On site-a, the map selected A1-to-B traffic and attached to Ethernet0/1 (the full build is in site-to-site IPsec with crypto maps):

crypto ipsec transform-set PL-TS esp-aes 256 esp-sha256-hmac 
 mode tunnel
...
crypto map PL-CMAP 10 ipsec-isakmp 
 set peer 198.18.35.5
 set transform-set PL-TS 
 set pfs group19
 set ikev2-profile PL-IKEV2-PROF
 match address PL-CMAP-ACL
...
interface Ethernet0/1
 ip address 198.18.35.1 255.255.255.252
 crypto map PL-CMAP
...
ip access-list extended PL-CMAP-ACL
 10 permit ip 10.35.10.0 0.0.0.255 10.35.20.0 0.0.0.255

Site-b used the same transform set, with the peer and selector reversed:

crypto map PL-CMAP 10 ipsec-isakmp 
 set peer 198.18.35.1
 set transform-set PL-TS 
 set pfs group19
 set ikev2-profile PL-IKEV2-PROF
 match address PL-CMAP-ACL
...
interface Ethernet0/1
 ip address 198.18.35.5 255.255.255.252
 crypto map PL-CMAP
...
ip access-list extended PL-CMAP-ACL
 10 permit ip 10.35.20.0 0.0.0.255 10.35.10.0 0.0.0.255

Traffic followed each site's default route toward the carrier. The crypto ACL selected the LAN packet for encryption as it left the WAN interface. There was no tunnel interface or OSPF route across the VPN in this build.

Baseline proof: proxy IDs, SPIs and session

After A1-to-B traffic, site-a showed IKEv2 READY:

Tunnel-id Local                 Remote                fvrf/ivrf            Status 
1         198.18.35.1/500       198.18.35.5/500       none/none            READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:19, Auth sign: PSK, Auth verify: PSK

Its IPsec output named the two /24 proxy IDs, counted traffic in both directions, and showed separate inbound and outbound ESP SPIs:

   local  ident (addr/mask/prot/port): (10.35.10.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.35.20.0/255.255.255.0/0/0)
   current_peer 198.18.35.5 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 17, #pkts encrypt: 17, #pkts digest: 17
    #pkts decaps: 17, #pkts decrypt: 17, #pkts verify: 17
...
     current outbound spi: 0x84DEBBC2(2229189570)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x7C3DB7BB(2084419515)
        transform: esp-256-aes esp-sha256-hmac ,
...
     outbound esp sas:
      spi: 0x84DEBBC2(2229189570)
        transform: esp-256-aes esp-sha256-hmac ,

The corresponding session excerpt was:

Interface: Ethernet0/1
Profile: PL-IKEV2-PROF
Uptime: 00:00:09
Session status: UP-ACTIVE     
...
  IPSEC FLOW: permit ip   10.35.10.0/255.255.255.0 10.35.20.0/255.255.255.0 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 17 drop 0 life (KB/Sec) 4177290/3590
        Outbound: #pkts enc'ed 17 drop 0 life (KB/Sec) 4177290/3590

Here, Active SAs: 2 means one inbound SA and one outbound SA: one pair. It does not mean two independently protected subnet pairs. Baseline host ping and HTTP passed both ways.

PFS group 19 was configured in the map, but this initial child-SA display reported N/none. Later negotiations displayed Y/group19. The configured requirement and a particular negotiated SA's displayed fields are different evidence; this run did not include a measured rekey test.

Routing protocol reality

Enabling OSPF on the physical WANs did not create a site-to-site adjacency:

site-a#show ip ospf neighbor
site-a#show ip ospf interface Ethernet0/1
Ethernet0/1 is up, line protocol is up 
...
  Neighbor Count is 0, Adjacent neighbor count is 0 

The carrier-side capture contained an OSPF hello from 198.18.35.1 to 224.0.0.5 with TTL 1, alongside ESP carrying the host tests. The carrier did not run OSPF or forward those link-local hellos. Enabling the process on both WAN ports therefore did not turn this crypto-map VPN into a routed overlay. Cisco also limits IPsec itself to unicast datagrams (Cisco IPsec configuration guide), which is why routing over crypto maps usually needs GRE or a VTI.

That observation is specific to this topology and configuration. For the separate GRE approach, GRE vs IPsec explains the encapsulation choice, and routing protocols over GRE follows the routing adjacency. Here, the second build used native IPsec VTI mode.

One end only: no IPSEC policy found for received TS

First I activated site-a's already-addressed A2 interface:

site-a(config)#interface Ethernet0/3
site-a(config-if)#no shutdown

Opening the attached crypto ACL for editing failed:

site-a(config)#ip access-list extended PL-CMAP-ACL
%ACL PL-CMAP-ACL can not be modified/deleted, as it is used in crypto-map PL-CMAP
%Please first remove the ACL from crypto map or remove the crypto map from the interface
% Cannot modify this ACL.
Other processes have control of this ACL

The working method removed the ACL reference from the map, added sequence 20, then restored the reference. This was the actual site-a console sequence:

site-a(config)#crypto map PL-CMAP 10 ipsec-isakmp
site-a(config-crypto-map)#no match address PL-CMAP-ACL
site-a(config-crypto-map)#exit
site-a(config)#ip access-list extended PL-CMAP-ACL
site-a(config-ext-nacl)#20 permit ip 10.35.11.0 0.0.0.255 10.35.20.0 0.0.0.255
site-a(config-ext-nacl)#exit
site-a(config)#crypto map PL-CMAP 10 ipsec-isakmp
% NOTE: This crypto map is incomplete. 
    To remedy the situation add a peer and a valid access-list to this crypto map.
site-a(config-crypto-map)#match address PL-CMAP-ACL
site-a(config-crypto-map)#end

Removing the reference flushed SAs. The incomplete-map note occurred before the reference was restored. Initial traffic rebuilt the original flow, with transient packet loss; its original SPI did not survive this edit.

At this point site-b still knew only the original mirrored selector. In steady testing, A1 ping and HTTP worked both ways. A2 ping lost all four packets in each direction, and both HTTP attempts timed out. Site-a had a new flow with no active SAs; site-b logged the selector rejection:

  IPSEC FLOW: permit ip   10.35.11.0/255.255.255.0 10.35.20.0/255.255.255.0 
        Active SAs: 0, origin: crypto map
        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
        Outbound: #pkts enc'ed 0 drop 6 life (KB/Sec) 0/0
...
*Oct 21 06:24:44.572: IKEv2-ERROR:(SESSION ID = 2,SA ID = 1):: There was no IPSEC policy found for received TS
*Oct 21 06:24:44.572: IKEv2-ERROR:(SESSION ID = 2,SA ID = 1):: Create child exchange failed

Cisco documents this check: a responder accepts a peer-proposed flow only if its crypto ACL permits it (Cisco crypto ACL guide).

The useful distinction was that one protected LAN still worked. A single UP-ACTIVE session did not prove that every flow under that session had usable data SAs. Read the flow for the added source network, then compare the opposite ACL.

When adding a network to an IPsec crypto ACL, the reverse policy matters: site-a proposed A2-to-B, while site-b had no corresponding B-to-A2 policy. The Phase 1 up, Phase 2 down lab tests several causes of failed data SAs; here, the added selector failed while the original LAN kept forwarding.

Mirror the ACL and verify two SA pairs

Site-b needed the reverse permit, using the same detach/edit/reattach method. Cisco recommends mirror-image crypto ACLs at each peer (Cisco IPsec configuration guide, Cisco crypto ACL guide). The site-b sequence was:

site-b(config)#crypto map PL-CMAP 10 ipsec-isakmp
site-b(config-crypto-map)#no match address PL-CMAP-ACL
site-b(config-crypto-map)#exit
site-b(config)#ip access-list extended PL-CMAP-ACL
site-b(config-ext-nacl)#20 permit ip 10.35.20.0 0.0.0.255 10.35.11.0 0.0.0.255
site-b(config-ext-nacl)#exit
site-b(config)#crypto map PL-CMAP 10 ipsec-isakmp
% NOTE: This crypto map is incomplete. 
    To remedy the situation add a peer and a valid access-list to this crypto map.
site-b(config-crypto-map)#match address PL-CMAP-ACL
site-b(config-crypto-map)#end

After traffic rebuilt the SAs, site-a's session showed both flows active:

  IPSEC FLOW: permit ip   10.35.10.0/255.255.255.0 10.35.20.0/255.255.255.0 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 52 drop 0 life (KB/Sec) 4279541/3583
        Outbound: #pkts enc'ed 53 drop 0 life (KB/Sec) 4279541/3583
...
  IPSEC FLOW: permit ip   10.35.11.0/255.255.255.0 10.35.20.0/255.255.255.0 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 18 drop 0 life (KB/Sec) 4326194/3582
        Outbound: #pkts enc'ed 18 drop 0 life (KB/Sec) 4326194/3582

A1 and A2 each had one inbound/outbound ESP pair, four active ESP SAs in total. Each permit entry defines its own data flow and SAs (Cisco crypto ACL guide); Cisco even notes a 10-second delay between SA creations for different ACEs (Cisco IPsec configuration guide). The selectors were disjoint /24 pairs; that result is not a rule for arbitrary overlapping ACLs. Stable ping and HTTP passed from each A LAN to B and back.

The persistent crypto change was one permit line per router. On this image, performing it required three mutation commands per router: detach the reference, add the permit, reattach. Activating A2 added one more command at site-a.

Build 2: static VTI with OSPF

The crypto-map addition created another selector pair and another ESP pair. In the VTI build, the new subnet entered routing while the existing wildcard ESP pair stayed in use. That is the change to look for in the next snapshots.

To migrate from a crypto map to a VTI in this lab, I removed the WAN map attachment, deleted the map and crypto ACL, removed the diagnostic WAN OSPF process, and cleared the crypto SAs on both routers. The IKEv2 objects and CBC transform set remained. This was a rebuild with an outage, not a hitless migration procedure.

Both peers used this IPsec profile:

crypto ipsec profile PL-IPSEC-PROF
 set transform-set PL-TS 
 set pfs group19
 set ikev2-profile PL-IKEV2-PROF

Site-a's tunnel and baseline OSPF configuration were:

interface Tunnel35
 ip address 10.35.255.1 255.255.255.252
 ip ospf network point-to-point
 tunnel source Ethernet0/1
 tunnel mode ipsec ipv4
 tunnel destination 198.18.35.5
 tunnel protection ipsec profile PL-IPSEC-PROF
...
router ospf 35
 router-id 35.35.35.1
 passive-interface default
 no passive-interface Tunnel35
 network 10.35.10.0 0.0.0.255 area 0
 network 10.35.255.0 0.0.0.3 area 0

Site-b used:

interface Tunnel35
 ip address 10.35.255.2 255.255.255.252
 ip ospf network point-to-point
 tunnel source Ethernet0/1
 tunnel mode ipsec ipv4
 tunnel destination 198.18.35.1
 tunnel protection ipsec profile PL-IPSEC-PROF
...
router ospf 35
 router-id 35.35.35.2
 passive-interface default
 no passive-interface Tunnel35
 network 10.35.20.0 0.0.0.255 area 0
 network 10.35.255.0 0.0.0.3 area 0

OSPF ran point-to-point over Tunnel35, with passive LAN interfaces and the WAN excluded. Initially only A1 and B were advertised. A2's interface remained active from the earlier test, but its network statement was absent.

The IOL forwarding quirk before a usable baseline

With CEF enabled, IKEv2 negotiated and OSPF reached FULL, but host ping and HTTP failed. Router-to-router tunnel and LAN-address pings worked. A capture at host-b1 showed echo requests arriving and replies leaving, without matching return ESP. Refreshing adjacency state did not fix forwarding.

Host forwarding worked only after disabling IPv4 CEF on both crypto routers. The working configuration and site-a readback included:

no ip cef
...
site-a#show ip cef
%IPv4 CEF not running

All successful VTI host tests below used process switching. This is a lab-image workaround for IOL 17.18.2, not a production requirement or a performance recommendation. The run did not establish a vendor bug ID or prove the internal cause. A FULL neighbor had been real; it simply had not proved host forwarding.

Baseline proof: tunnel, OSPF and wildcard selectors

After that workaround, site-a showed the tunnel up/up, a FULL neighbor, and B's LAN learned through Tunnel35:

site-a#show interfaces tunnel 35
Tunnel35 is up, line protocol is up 
...
site-a#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
35.35.35.2        0   FULL/  -        00:00:34    10.35.255.2     Tunnel35
...
O        10.35.20.0/24 [110/1010] via 10.35.255.2, 00:03:17, Tunnel35

The IPsec selectors were wildcard addresses at both ends:

interface: Tunnel35
    Crypto map tag: Tunnel35-head-0, local addr 198.18.35.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 198.18.35.5 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 62, #pkts encrypt: 62, #pkts digest: 62
    #pkts decaps: 59, #pkts decrypt: 59, #pkts verify: 59
...
     current outbound spi: 0x8CA82ED2(2359832274)

The session reported one flow and one ESP pair:

  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 59 drop 0 life (KB/Sec) 4338697/3401
        Outbound: #pkts enc'ed 62 drop 0 life (KB/Sec) 4338697/3401

Cisco documents the SVTI selector as always 'IP any any' by default (Cisco VTI configuration guide). In show crypto ipsec sa, the VTI's 0.0.0.0 addresses describe the negotiated wildcard selector scope; the routes determine which packets enter Tunnel35. It does not mean a default route through the VPN was installed.

IOS still printed origin: crypto map and Tunnel35-head-0. Those implementation labels appeared with tunnel protection and no configured WAN crypto map. The tunnel configuration, interface field, and routing table identify the design.

Add a subnet to a VTI: one OSPF line, same SPIs

Under site-a's OSPF process, the entire routing change was:

site-a(config)#router ospf 35
site-a(config-router)#network 10.35.11.0 0.0.0.255 area 0
site-a(config-router)#end

Site-b's full saved configuration was byte-identical before and after the addition. Its routing table gained A2:

O        10.35.10.0/24 [110/1010] via 10.35.255.1, 00:03:58, Tunnel35
O        10.35.11.0/24 [110/1010] via 10.35.255.1, 00:00:21, Tunnel35

At site-a, encapsulation rose from 62 to 121 and decapsulation from 59 to 119. The post-addition snapshot retained the baseline outbound SPI:

    #pkts encaps: 121, #pkts encrypt: 121, #pkts digest: 121
    #pkts decaps: 119, #pkts decrypt: 119, #pkts verify: 119
...
     current outbound spi: 0x8CA82ED2(2359832274)

Those totals include OSPF and test traffic; they are not packet counts attributable solely to A2. The unchanged SPIs, wildcard selectors, learned route, and passing host tests establish the useful result: A2 used the existing ESP pair without editing crypto at either end.

VTI faults: a GCM change that did not stick, then a typo

The first attempt changed site-b's attached profile to GCM while site-a remained on CBC, then cleared site-b's child SA:

site-b(config)#crypto ipsec transform-set PL-TS-GCM esp-gcm 256
site-b(cfg-crypto-trans)#mode tunnel
site-b(cfg-crypto-trans)#exit
site-b(config)#crypto ipsec profile PL-IPSEC-PROF
site-b(ipsec-profile)#set transform-set PL-TS-GCM
site-b(ipsec-profile)#end
site-b#clear crypto sa peer 198.18.35.1
site-b#show interfaces tunnel 35
Tunnel35 is up, line protocol is down 

That immediate snapshot showed up/down and no OSPF neighbor. It did not remain broken. OSPF dropped at 06:31:21.891 and returned to FULL at 06:31:37.544. The recovered SAs used the old CBC/SHA-256 transform even though site-b's running profile selected GCM:

     inbound esp sas:
      spi: 0x79BBCF25(2042351397)
        transform: esp-256-aes esp-sha256-hmac ,
...
crypto ipsec profile PL-IPSEC-PROF
 set transform-set PL-TS-GCM 
 set pfs group19
 set ikev2-profile PL-IKEV2-PROF

The one-sided transform change therefore did not hold as a fault on this image. A profile showing GCM was not proof that the active child SA used GCM. Cisco's VTI procedure says to shut the tunnel before configuring tunnel protection for an IPsec profile (Cisco VTI configuration guide); the final change followed that order. These observations do not establish a persistent transform rejection or a NO_PROPOSAL_CHOSEN result.

Persistent fault: wrong tunnel destination

For the sustained failure, I returned site-b's profile selection to PL-TS and changed its tunnel destination from 198.18.35.1 to 198.18.35.9:

site-b(config)#crypto ipsec profile PL-IPSEC-PROF
site-b(ipsec-profile)#set transform-set PL-TS
site-b(ipsec-profile)#exit
site-b(config)#interface Tunnel35
site-b(config-if)#tunnel destination 198.18.35.9
site-b(config-if)#end
site-b#clear crypto sa peer 198.18.35.1

Site-b's immediate interface snapshot still said up/up and retained a FULL neighbor. After clearing the affected SAs on both peers, both tunnels settled at up/down. Site-a's later state was:

site-a#show interfaces tunnel 35
Tunnel35 is up, line protocol is down 
...
site-a#show ip ospf neighbor
site-a#show ip route ospf
...
     current outbound spi: 0x0(0)
...
Interface: Tunnel35
Session status: DOWN

There were no OSPF neighbors or learned OSPF routes, the IKEv2-SA output was empty, and all cross-site host tests failed. Previous packet totals remained visible despite the zero outbound SPI. Those old totals were not evidence of current forwarding.

The syslog explained how OSPF went down:

*Oct 21 06:33:27.764: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel35, changed state to down
*Oct 21 06:33:27.767: %OSPF-5-ADJCHG: Process 35, Nbr 35.35.35.2 on Tunnel35 from FULL to DOWN, Neighbor Down: Interface down or detached

The loss followed interface state, with “Interface down or detached,” rather than waiting for an OSPF dead timer. A later 15-second wait confirmed persistence. Site-b also logged an IKEv2 profile-not-found message while attempting the wrong peer. For this up/down VTI, the wrong destination, empty current SAs, and routing loss identified the fault.

Fix the destination, then verify aligned GCM

First, site-b's destination was restored and the wrong-peer IPsec SAs cleared:

site-b#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
site-b(config)#interface Tunnel35
site-b(config-if)#tunnel destination 198.18.35.1
site-b(config-if)#end
site-b#clear crypto sa peer 198.18.35.9

Bidirectional host tests recovered, and OSPF returned. The later GCM change was coordinated separately. On site-a I shut Tunnel35, detached protection, selected GCM in the profile, and rebound protection:

site-a#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
site-a(config)#interface Tunnel35
site-a(config-if)#shutdown
site-a(config-if)#no tunnel protection ipsec profile PL-IPSEC-PROF
site-a(config-if)#exit
site-a(config)#crypto ipsec transform-set PL-TS-GCM esp-gcm 256
site-a(cfg-crypto-trans)#mode tunnel
site-a(cfg-crypto-trans)#exit
site-a(config)#crypto ipsec profile PL-IPSEC-PROF
site-a(ipsec-profile)#set transform-set PL-TS-GCM
site-a(ipsec-profile)#exit
site-a(config)#interface Tunnel35
site-a(config-if)#tunnel protection ipsec profile PL-IPSEC-PROF
site-a(config-if)#end

I repeated that sequence on site-b while site-a remained shut. Both ends had protection rebound before either tunnel was enabled. Site-a's enable step was:

site-a(config)#interface Tunnel35
site-a(config-if)#no shutdown
site-a(config-if)#end

Final site-b output confirmed up/up, FULL, and actual GCM transforms in both ESP directions:

site-b#show interfaces tunnel 35
Tunnel35 is up, line protocol is up 
...
Neighbor ID     Pri   State           Dead Time   Address         Interface
35.35.35.1        0   FULL/  -        00:00:36    10.35.255.1     Tunnel35
...
     inbound esp sas:
      spi: 0x74EAA8FD(1961535741)
        transform: esp-gcm 256 ,
...
     outbound esp sas:
      spi: 0xE26E4023(3798876195)
        transform: esp-gcm 256 ,
...
  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 47 drop 0 life (KB/Sec) 4165253/3576
        Outbound: #pkts enc'ed 46 drop 0 life (KB/Sec) 4165253/3576

IKEv2 still reported AES-CBC-256/SHA-256/group 19. Final stable tests passed ping and HTTP for A1↔B and A2↔B. For example, B's ping to the added A2 host ended with:

--- 10.35.11.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms

The final carrier capture contained ESP. Its ESP-only filter verifies captured encrypted traffic, but cannot prove the absence of every plaintext protocol.

What changed side by side

These counts describe this run. Mutation counts exclude mode-selection, exit, show, and debug commands, plus the failed edit attempt. The independent WAN OSPF diagnostic setup is excluded from the subnet change.

The last row includes object headers, shared IKEv2 objects, transforms, map/profile, crypto ACL, and interface crypto/endpoint commands. It excludes defaults, tunnel addressing, OSPF, and the CEF workaround. Both baselines used CBC; the count is not the final configuration retaining CBC alongside GCM. That count includes the shared IKEv2 objects both designs need. Counting only the map, ACL and interface lines that the VTI replaces, the VTI is much shorter, as the crypto maps vs VTI build showed.

For this two-LAN baseline, config size barely differed. The operational difference appeared during the addition: seven map-build mutation commands across both routers including LAN activation, versus one VTI routing command after that LAN was already active.

Choosing a design for the next subnet

For another subnet addition between these two routing-controlled endpoints, I'd choose the VTI workflow: advertise the LAN and verify its route, forwarding, and existing SAs. The byte-identical site-b config is the result I'd want to repeat. The host-forwarding workaround means I would still validate the intended production platform separately.

If the existing peer arrangement required these narrow selectors, I'd extend the crypto map with both ACL changes prepared together. Here, detaching the reference interrupted existing SAs, so even a small persistent delta needed an interruption plan. The lab gives a concrete change to rehearse for either design.

For the wider design choice (routing protocols, scale, interop), see crypto maps vs VTI.

Verification checklist

• Establish working host ping and HTTP in both directions before the change; include both the original and added LAN afterward.
• Check IKEv2 READY alongside the individual IPsec flows, current SPIs, and counter changes. UP-ACTIVE alone missed the A2 selector failure.
• For the crypto map, compare each added permit with its reverse at the peer. Verify two active ESP pairs after exercising both disjoint LAN pairs.
• For VTI, check Tunnel35, OSPF FULL, and the specific learned LAN routes together. Compare the wildcard selectors and SPIs before and after adding A2.
• Read the active ESP transform after a profile change. This image recovered to CBC during the first GCM attempt; final GCM required protection detach/rebind.
• Treat old packet totals and immediate interface snapshots carefully. The destination fault settled after SA clears, and host tests established whether forwarding actually worked.

Related IPsec labs

• IKEv2 with crypto maps — Build the IKEv2 policy-based baseline.
• Static VTI (SVTI) configuration — Follow the tunnel-interface configuration.
• IKEv2 SVTI configuration — Work through the IKEv2 and IPsec profile bindings.
• Phase 1 up, Phase 2 down — Compare five separate data-SA fault tests.
• Site-to-site IPsec with crypto maps — The full crypto map build on IOS XE.
• Crypto maps vs VTI — Pick the design before the change.
• IPsec VPN guide — The hub for every PingLabz IPsec lab.

FAQ

Does adding a subnet to a crypto map require both routers to change?

In this lab, yes. A2 needed a permit at site-a and its reverse at site-b. The one-sided addition preserved A1 forwarding but left A2 without an active ESP pair. Mirroring the ACL repaired it.

Why does a VTI show 0.0.0.0 selectors and origin: crypto map?

The VTI negotiated one wildcard selector pair, while routing steered A1, A2, and OSPF through Tunnel35. The crypto-map origin string was an IOS implementation label in this output; the saved configuration used an IPsec profile on a tunnel interface.

Does Tunnel35 up/up prove that hosts can use the VPN?

No. The initial VTI had working OSPF while host forwarding failed until the IOL-specific CEF workaround. During the destination fault, site-b also briefly retained up/up before settling at up/down. Check current SAs, routes, and host traffic together; the IPsec troubleshooting guide provides the broader workflow.

Did the one-sided GCM change produce a lasting transform mismatch?

No. It briefly dropped the tunnel and OSPF, then negotiated CBC while the profile showed GCM. The persistent fault used the destination typo. After destination recovery, both ends were explicitly detached, aligned to GCM, rebound, and verified from the negotiated ESP SAs.

What does 'There was no IPSEC policy found for received TS' mean?

The responder found no crypto ACL entry matching the proposed traffic selector. Here site-a proposed A2-to-B, and site-b had no B-to-A2 permit. Cisco documents that a peer-initiated flow must be permitted by a crypto ACL on the responder's crypto map entry (Cisco crypto ACL guide). Adding the mirrored line fixed it.

Do you have to remove the crypto map from the interface to edit its ACL?

Not on this IOL image: removing only match address from the map entry allowed the edit. It still flushed the existing SAs, so plan it as an interruption. The same 'can not be modified' error appears on IOS XE in our crypto maps vs VTI lab.

Can a static VTI use per-subnet SAs like a crypto map?

Yes, optionally. By default an SVTI's selector is always 'IP any any'. From IOS XE 16.12.1, Multi-SA SVTI can attach a permit-only ACL, which creates an SA per selector, and both ends must then match (Cisco VTI configuration guide). In that mode, adding a subnet means ACL edits on both peers again. This lab used the default any/any.