This article describes the issue of the SRX device, which has configured VPN with SHA2 in the IPsec proposal, being unable to decrypt the encrypted traffic; even though it has established the VPN tunnel.
Junos and SSG have two generations of SHA2-256 algorithms; the first one uses the 96 bit-length data field and the second one uses the 128 bit-length data field.
Due to this gap, there is an issue with encrypting or decrypting traffic between generations. For example, configure a SSG device and a SRX device as the VPN gateway and use SHA2 in the IPsec proposal:
root> show configuration security ike
proposal p1-prop01 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm md5;
encryption-algorithm 3des-cbc;
}
policy p1-pol01 {
mode main;
proposals p1-prop01;
pre-shared-key ascii-text "$9$Vtb2aZGiq.5aJ36AtOB"; ## SECRET-DATA
}
gateway To-VPNGW1 {
ike-policy p1-pol01;
address 192.168.0.253;
external-interface ge-0/0/1;
}
root> show configuration security ipsec
proposal p2-prop01 {
protocol esp;
authentication-algorithm hmac-sha-256-128;
encryption-algorithm aes-256-cbc;
}
policy p2-pol01 {
perfect-forward-secrecy {
keys group2;
}
proposals p2-prop01;
}
vpn To-VPN1 {
ike {
gateway To-VPNGW1;
ipsec-policy p2-pol01;
}
establish-tunnels immediately;
}
SSG and SRX will match the proposals that are sent from each other. Both of the nodes negotiate to use SHA2 as authentication algorithm. The negotiation will be completed without any error and then the tunnel will come up:
root> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 130996 UP 3fdb113fe97d3517 2e398fb723a316b0 Main 192.168.0.253 root> show security ipsec security-associations Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway <2 ESP:aes-256/sha256 1cf19310 2421/ unlim - root 500 192.168.0.253 >2 ESP:aes-256/sha256 9b7078b9 2421/ unlim - root 500 192.168.0.253 root> show security ipsec security-associations index 2 detail Virtual-system: root Local Gateway: 192.168.0.254, Remote Gateway: 192.168.0.253 Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) DF-bit: clear Policy-name: u2l-p01 Direction: inbound, SPI: 1cf19310, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 2285 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 1647 seconds Mode: tunnel, Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha-256-128, Encryption: aes-cbc (256 bits) Anti-replay service: counter-based enabled, Replay window size: 64 Direction: outbound, SPI: 9b7078b9, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 2285 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 1647 seconds Mode: tunnel, Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha-256-128, Encryption: aes-cbc (256 bits) Anti-replay service: counter-based enabled, Replay window size: 64 root>
However, SRX does not encrypt with the proper message digest length. So, SSG fails to decrypt the traffic. You will notice the Drop log in the debug flow basic log on the SSG side, when pinging from behind SRX to the SSG side:
****** 07472.0: <untrust2/ethernet0/2> packet received [120]****** ipid = 172(00ac), @03e00db0 packet passed sanity check. flow_decap_vector IPv4 process ethernet0/2:10.10.11.1/37988->10.10.11.254/26434,50<Root> existing session found. sess token 16 flow got session. flow session id 16056 flow_decrypt: 359c890(b), flow_decrypt: 359c890(b)pipeline. IPv4 encrypted pak. Dec: SPI = 94646742, Data Len = 120 SA tunnel id=0x00000001, flag<02400063> chip info: PIO. Tunnel id 00000001 invalid esp payload length (60). drop. < SSG finds that the ESP payload length is wrong.
In case of pinging from any source behind SSG to the SRX side, no such logs are found; but only the drop log can be found in flow traceoption:
CID-0:RT:flow_process_pkt_exception: Freeing lpak 3fded8b8 associated with mbuf 0x437d3980
The HMAC calculation on the 2nd generation uses 96 bit length truncation. it was introduced and supported, as mentioned in the following table:
The following combinations experience this compatibility issue:
For example, if a SRX device that uses 11.2R4 connects the VPN tunnel with SSG, which uses 6.3r4 or earlier, It works normally; but if Junos is upgraded to 11.2R6 or ScreenOS is upgraded to 6.3r5, the gateways fail to decrypt the traffic from others. Subsequently, traffic over the VPN tunnel will be dropped.
With the SRX family, this issue is noticed only with SRX branch devices.
If the remote gateway uses 128 bit and the platform is NS/SSG, use set envar hmac-sha256-96=yes on the SSG side to allow 96 bit truncated message digest. In case of SRX/SRX VPN, use the same release on both of the gateways.