Courseiva
VPNCCNA 200-301

IPsec Crypto ACL Mismatch Between Peers — Tunnel Not Encrypting

Presenting Symptom

Traffic between two sites is not encrypted by IPsec, and the tunnel shows as up but no packets are being encrypted or decrypted.

Network Context

Two Cisco routers (R1 and R2) are configured as IPsec VPN peers in a small branch office to headquarters setup. Both run IOS 15.x. The tunnel interface (Tunnel0) is up/up, but 'show crypto ipsec sa' shows 0 packets encapsulated/decapsulated. The crypto map is applied to the outside interface (GigabitEthernet0/0).

Diagnostic Steps

1

Check IPsec Security Association (SA) status

show crypto ipsec sa
interface: GigabitEthernet0/0
    Crypto map tag: CMAP, local addr 192.168.1.1
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
   current_peer 192.168.2.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

If #pkts encaps and decaps are 0, the tunnel is not encrypting traffic. Check the local and remote identities (ACL) to see if they match the actual traffic.

2

Verify the crypto ACL configuration on both peers

show access-lists 101
Extended IP access list 101
    10 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Compare the ACL on both peers. The ACL on R1 should permit traffic from its local subnet to the remote subnet. The ACL on R2 should be the mirror image (permit from 192.168.2.0 to 192.168.1.0). A mismatch occurs if the ACLs are not mirrored.

3

Check the crypto map configuration

show crypto map
Crypto Map "CMAP" 10 ipsec-isakmp
    Peer = 192.168.2.1
    Extended IP access list 101
    Current peer: 192.168.2.1
    Security association lifetime: 4608000 kilobytes/3600 seconds
    PFS (Y/N): N
    Transform sets={TS,}

Verify that the ACL referenced in the crypto map matches the ACL number used. Also confirm the peer IP is correct.

4

Debug IPsec packet processing to see why traffic is not matched

debug crypto ipsec
IPSEC(sa_request): ,
  (key eng. msg.) src= 192.168.1.1, dest= 192.168.2.1,
    src_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),
    dest_proxy= 192.168.2.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac ,
    lifedur= 3600s and 4608000kb,
    spi= 0x12345678(305419896), conn_id= 0, keysize= 128, flags= 0x4004

If no debug output appears when sending traffic, the ACL is not matching the traffic. If the src_proxy or dest_proxy are incorrect, the ACL is misconfigured.

Root Cause

The IPsec crypto ACL on one peer does not mirror the ACL on the other peer. For example, R1's ACL permits 192.168.1.0/24 to 192.168.2.0/24, but R2's ACL permits 192.168.2.0/24 to 192.168.1.0/24 (correct), but the source/destination order is reversed or the subnet masks are mismatched. This causes the IPsec SA to be established but no traffic to match the ACL, resulting in zero encrypted packets.

Resolution

1. On R2, configure the correct mirrored ACL: R2(config)# ip access-list extended 101 R2(config-ext-nacl)# permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 R2(config-ext-nacl)# end 2. Clear the IPsec SAs to force renegotiation: R2# clear crypto sa 3. Verify the ACL is applied to the crypto map (if not already): R2(config)# crypto map CMAP 10 ipsec-isakmp R2(config-crypto-map)# match address 101

Verification

Run 'show crypto ipsec sa' on both peers. Expected output shows #pkts encaps and #pkts decrypt incrementing when traffic is sent. Also run 'show access-lists 101' to confirm the ACL entries are correct and mirrored.

Prevention

1. Always configure crypto ACLs as mirror images on both peers, ensuring source/destination are swapped. 2. Use a consistent naming convention for ACLs and crypto maps. 3. After configuration, test with ping and verify packet counters before relying on the tunnel.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario appears in troubleshooting questions where the tunnel is up but no encryption occurs. The exam tests the understanding that IPsec requires mirrored ACLs for traffic selection. A common multiple-choice question asks: 'Which configuration issue causes the tunnel to be up but no packets encrypted?' The correct answer is 'Crypto ACL mismatch.'

Exam Tips

1.

Remember that IPsec ACLs must be mirror images: source on one peer becomes destination on the other.

2.

Use 'show crypto ipsec sa' to check packet counters; if encaps/decaps are 0, the ACL is not matching traffic.

3.

The 'debug crypto ipsec' command shows the proxy identities; if they don't match the actual traffic, the ACL is wrong.

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 access-lists

Displays all configured access control lists (ACLs) on the device, including their entries and match counters, used to verify ACL configuration and traffic filtering.

show crypto ipsec sa

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

show crypto map

Displays the configured crypto map entries, including their match criteria, peer addresses, and transform sets, used to verify IPsec VPN policy configuration.

Test Your CCNA Knowledge

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

Practice CCNA Questions