Courseiva
VPNCCNA 200-301

IPsec PFS (Perfect Forward Secrecy) Mismatch

Presenting Symptom

IPsec VPN tunnel is established but no traffic passes; Phase 2 (IPsec SA) fails to establish with 'PFS mismatch' errors in the logs.

Network Context

A small branch office (site B) connects to the main headquarters (site HQ) via a site-to-site IPsec VPN using Cisco IOS routers (e.g., Cisco 4321 at HQ, Cisco 891 at branch). Both routers run IOS 15.x. The tunnel was working until a recent configuration change at HQ. The problem is isolated to the IPsec SA negotiation; IKE Phase 1 completes successfully.

Diagnostic Steps

1

Check IPsec 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): (192.168.10.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)
   current_peer 192.168.2.2 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
    #pkts compressed: 0, #pkts decompress: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0
     local crypto endpt.: 192.168.1.1, remote crypto endpt.: 192.168.2.2
     path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0
     current outbound spi: 0x0(0)
     PFS (Y/N): N, DH group: none

If the SA shows #pkts encaps: 0 and no inbound/outbound SPI, the IPsec SA is not established. The line 'PFS (Y/N): N' indicates PFS is not enabled locally. If the remote side expects PFS, negotiation will fail.

2

Check IKE Phase 1 status

show crypto isakmp sa
dst             src             state          conn-id slot status
192.168.2.2     192.168.1.1     MM_ACTIVE      1       0     ACTIVE

If IKE SA is in MM_ACTIVE state, Phase 1 completed. The problem is in Phase 2.

3

Check crypto map configuration for PFS

show run | section crypto map
crypto map CMAP 10 ipsec-isakmp
 set peer 192.168.2.2
 set transform-set TSET
 match address VPN_ACL
 set pfs group14

Look for 'set pfs' statement. If one side has 'set pfs group14' and the other does not, or uses a different group, PFS mismatch occurs.

4

Check transform set details

show crypto ipsec transform-set
Transform set TSET: { esp-aes 256 esp-sha-hmac }
   will negotiate = { Tunnel,  },
   PFS group: None

The transform set itself does not specify PFS; PFS is configured in the crypto map. If the transform set shows 'PFS group: None', but the crypto map sets PFS, the local router will propose PFS. If the remote does not support it, negotiation fails.

5

Enable debug for IPsec negotiation

debug crypto ipsec
IPSEC(validate_proposal): transform proposal not acceptable for policy 0x...
IPSEC(validate_proposal): PFS group mismatch

The debug output explicitly states 'PFS group mismatch', confirming the root cause.

Root Cause

The IPsec VPN tunnel fails because Perfect Forward Secrecy (PFS) is configured on one peer (HQ) but not on the other (branch), or the DH group for PFS differs between the two peers. This causes Phase 2 negotiation to fail, as the peers cannot agree on the PFS parameters.

Resolution

Ensure both peers have matching PFS configuration. On the branch router, add the same PFS group as HQ: 1. Enter global configuration mode. 2. Enter the crypto map configuration: `crypto map CMAP 10` 3. Set PFS: `set pfs group14` 4. Exit and verify. Alternatively, remove PFS from HQ if not required: `no set pfs` under the crypto map. Exact commands: ``` configure terminal crypto map CMAP 10 set pfs group14 end ```

Verification

Run `show crypto ipsec sa` and verify that the IPsec SA is established with non-zero packet counts and an active SPI. Also check `show crypto isakmp sa` to ensure Phase 1 remains active. The output should show: #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10 #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5 current outbound spi: 0xABCDEF(123456789) PFS (Y/N): Y, DH group: group14

Prevention

1. Standardize IPsec VPN configurations across all sites using templates to ensure PFS settings match. 2. Always verify both Phase 1 and Phase 2 parameters (including PFS) during initial setup and after any changes. 3. Use IKEv2 which can negotiate PFS more gracefully, but still ensure consistency.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario may appear as a troubleshooting question where you must identify why an IPsec tunnel fails to pass traffic despite Phase 1 being up. The exam tests understanding of IPsec Phase 2 parameters, specifically PFS and its DH group. A candidate must know that 'show crypto ipsec sa' and 'debug crypto ipsec' are key commands, and that PFS mismatch is a common cause of Phase 2 failure.

Exam Tips

1.

Remember that 'show crypto ipsec sa' shows PFS status per SA; if PFS is 'N' but the peer expects it, the SA will not form.

2.

The exam may present a scenario where the transform set matches but the crypto map has 'set pfs' on one side only — that is a mismatch.

3.

Know that 'debug crypto ipsec' will show 'PFS group mismatch' explicitly; this is a definitive clue.

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.

show crypto isakmp sa

Displays the current state of Internet Key Exchange (IKE) Security Associations (SAs) used for IPsec VPN tunnels, allowing verification of Phase 1 tunnel establishment.

Test Your CCNA Knowledge

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

Practice CCNA Questions