Description

This article documents an issue observed on vSRX devices where OSPF adjacency fails when IPsec VPN (IKEv2) is configured using AES-GCM encryption along with the extended-sequence-number option.

Symptoms

In deployments where OSPF is configured between two vSRX devices over an IPsec (IKEv2) VPN tunnel, OSPF adjacency may go down or fail to establish under specific configuration conditions.

Solution

Trigger:

This issue is observed when all of the following conditions are met:

  • vSRX platform with PMI (Packet Management Infrastructure) enabled
  • IPsec encryption algorithm configured with AES-GCM variants:
    • aes-128-gcm
    • aes-192-gcm
    • aes-256-gcm
  • OSPF configuration includes extended-sequence-number
  • IKED process is enabled

Root Cause:

When PMI is enabled on vSRX, IPsec traffic with AES-GCM encryption is expected to be processed in hardware (PMI mode). However:

  • OSPF packets are instead processed through the software encryption engine
  • Due to an existing defect in AAD (Additional Authenticated Data) computation, the receiving peer fails to authenticate ESP packets
  • As a result, OSPF packets are dropped, causing adjacency failure and routing issues

Workaround:

To mitigate the issue:

  • Change the IPsec encryption algorithm from AES-GCM variants to AES-CBC variants  

This issue is resolved in the following Junos OS versions:

  • 24.2R2
  • 24.4R1
  • Later releases

For more details, refer to the Problem Report:

Modification History

2024-10-02 : Article Created