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.
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.