[SRX] Traffic not passing through VPN tunnel when hmac-sha-256-96 is used

Summary:

VPN traffic received from peer may fail to decrypt when using IPsec proposals that use the authentication algorithm of hmac-sha-256-56.

security {
    ipsec {
        proposal esp-aes256-sha256-3600 {
            protocol esp;
            authentication-algorithm hmac-sha-256-96;
            encryption-algorithm aes-256-cbc;
            lifetime-seconds 3600;
        }
}

This article explains the cause for VPN traffic to not pass through the SRX device and provides a solution to avoid the problem.

Symptoms:

The Phase1 and Phase2 SAs are up.
Traffic received via VPN is not passing through the SRX device as indicated by the IPsec statistics that are not reflecting an increase in Decap:

root> show security ipsec statistics            
ESP Statistics:
  Encrypted bytes:             1360
  Decrypted bytes:                0
  Encrypted packets:             10
  Decrypted packets:              0 <==================
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

Flow traces will report receipt of ESP packets, but will not show decapsulated traffic.
The PFE (vty) command, show usp ipsec pkt-stat, reflects an increasing "Decrypt prepare vector failed" counter value.

>run request pfe execute target fwdd command "show usp ipsec pkt-stat"
Decrypt Error Stats
        Received for decap failed             : 451
        SAE context init failed               : 0
        SAE enque failed for decrypt          : 0
        Decrypt failed with invalid flow context: 0
        Decrypt failed with invalid context   : 0
        Decrypt failed with bad SPI           : 0
        Decrypt failed with pre auth anti replay check : 0
        Decrypt failed with inactive SA       : 0
        Decrypt failed with expired lifesize  : 0
        Decrypt failed with expired lifetime  : 0
        Decrypt prepare vector failed         : 451 <==================
        Decrypt failed with invalid nsp tunnel: 0
        Decrypt failed with invalid nsp tunnel in post: 0
        Decrypt failed with mini nsp tunnel: 0
        Decrypt finish vector failed          : 0
        SAE decryption result failed          : 0
        Post decrypt processing failed        : 0
        Decrypt pkts failed in POT            : 0
        Replay Check fail with zero seq number: 0
        Replay Check fail with too new seq nbr: 0
        Replay Check fail with too old seq nbr: 0
        Replay Check fail but not too old with bigger window: 0
        Replay Check fail with already seen seq number: 0

Cause:

The issue occurs when the VPN peers use two different IPsec proposals with one peer using hmac-sha-256-96 and the other peer using hmac-sha-256-128. Both these proposals use different encryption lengths.

Solution:

To avoid this issue, confirm that both VPN peers are using the same IKE/IPsec proposal settings. Review the Phase 2 proposals by using show security ipsec, and confirm that the configuration matches the Phase 2 proposals configured by the peer.

root@srx210# show security ipsec
proposal esp-aes256-sha256-3600 {
    protocol esp;
    authentication-algorithm hmac-sha-256-96;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 3600;
}
policy ipsec-phase2-policy {
    perfect-forward-secrecy {
        keys group2;
    }
    proposals esp-aes256-sha256-3600;
}
vpn ike-vpn-srx1 {
    vpn-monitor;
    ike {
        gateway gw-srx1;
        ipsec-policy ipsec-phase2-policy;
    }
}

Note: The IPsec authentication algorithm hmac-sha-256-96 setting has been deprecated on SRX devices as of Junos OS 12.3X48-D20.

Knowledge Base