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.

• 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

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.

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.