VPNCCNA 200-301

IPsec Transform Set Mismatch Between Peers

Presenting Symptom

IPsec VPN tunnel fails to establish between two Cisco routers; Phase 2 negotiation fails with 'transform set proposal mismatch' error.

Network Context

Two Cisco 4331 routers (IOS XE 16.9) are configured for site-to-site IPsec VPN between a branch office (10.1.1.0/24) and headquarters (10.2.2.0/24). The routers are directly connected via serial links. The VPN configuration uses IKEv1 with pre-shared keys. The tunnel was working until a recent configuration change on the branch router.

Diagnostic Steps

Check Phase 2 SA status

show crypto ipsec sa

interface: Tunnel0
    Crypto map tag: CMAP, local addr 192.168.1.1
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
   current_peer 192.168.2.1 port 500
     PERMIT, flags={}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 192.168.1.1, remote crypto endpt.: 192.168.2.1
     path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0
     current outbound spi: 0x0(0)
     PFS (Y/N): N, DH group: none

If no IPsec SA is present (SPI = 0x0), Phase 2 has not completed. This indicates a mismatch in transform sets or other Phase 2 parameters.

Check Phase 2 proposal on both peers

show crypto ipsec transform-set

Transform set ESP-AES256-SHA: { esp-256-aes esp-sha-hmac }
   will negotiate = { Transport, Tunnel, }

Compare the transform sets on both routers. Look for differences in encryption algorithm, hash algorithm, or mode. For example, one router may have 'esp-3des' while the other has 'esp-aes 256'.

Enable debug for ISAKMP and IPsec

debug crypto ipsec

IPSEC(validate_proposal): transform set proposal mismatch: local transform set {esp-256-aes esp-sha-hmac} vs remote {esp-3des esp-sha-hmac}

The debug output explicitly states the mismatch. Note the exact algorithms in the local and remote proposals.

Verify crypto map configuration

show crypto map

Crypto Map "CMAP" 10 ipsec-isakmp
    Peer = 192.168.2.1
    Extended IP access list 100
    access-list 100 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
    Current peer: 192.168.2.1
    Security association lifetime: 4608000 kilobytes/3600 seconds
    PFS (Y/N): N
    Transform sets={TSET},

Confirm which transform set is applied to the crypto map. Then check that the transform set exists and matches the peer's configuration.

Root Cause

The branch router's transform set was changed from 'ESP-AES256-SHA' (esp-256-aes, esp-sha-hmac) to 'ESP-3DES-SHA' (esp-3des, esp-sha-hmac) during a maintenance window, but the headquarters router still uses 'ESP-AES256-SHA'. The mismatch causes Phase 2 negotiation to fail.

Resolution

On the branch router, reconfigure the transform set to match the headquarters router: ``` configure terminal crypto ipsec transform-set ESP-AES256-SHA esp-256-aes esp-sha-hmac mode tunnel exit crypto map CMAP 10 ipsec-isakmp set transform-set ESP-AES256-SHA end ``` This sets the transform set to use AES-256 encryption and SHA-1 hashing in tunnel mode, then applies it to the crypto map.

Verification

Run 'show crypto ipsec sa' on both routers. Expected output should show active IPsec SAs with non-zero SPI values and packet counters incrementing: ``` interface: Tunnel0 Crypto map tag: CMAP, local addr 192.168.1.1 protected vrf: (none) local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0) current_peer 192.168.2.1 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10 #pkts decaps: 8, #pkts decrypt: 8, #pkts verify: 8 #send errors 0, #recv errors 0 local crypto endpt.: 192.168.1.1, remote crypto endpt.: 192.168.2.1 path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0 current outbound spi: 0x12345678(305419896) PFS (Y/N): N, DH group: none ``` Also verify with 'show crypto ipsec transform-set' that both routers show the same transform set.

Prevention

1. Use a standardized IPsec transform set template across all VPN peers. 2. Implement change management procedures that require peer configuration review before applying changes. 3. Use IKEv2 with multiple transform set proposals to allow fallback if one set mismatches.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario appears in troubleshooting questions where you must identify why an IPsec tunnel fails. The exam tests your ability to interpret 'show crypto ipsec sa' and 'debug crypto ipsec' output to pinpoint a transform set mismatch. Key fact: Transform sets must match exactly on both peers for Phase 2 to succeed.

Exam Tips

Memorize the 'show crypto ipsec sa' command and look for 'spi: 0x0' indicating no SA established.

Remember that transform set mismatch is a common Phase 2 issue; Phase 1 (ISAKMP) may succeed but Phase 2 fails.

Know that 'debug crypto ipsec' will show 'transform set proposal mismatch' when the algorithms differ.

Commands Used in This Scenario

debug crypto ipsec

Use this command to enable real-time debugging of IPsec security association (SA) negotiations and packet processing, typically for troubleshooting VPN connectivity issues.

show crypto ipsec sa

Displays the current state and statistics of IPsec security associations (SAs) to verify VPN tunnel establishment and monitor encrypted traffic.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions