Description

Anti-replay is an IPSec security mechanism at a packet level which helps to avoid unwanted users from intercepting and modifying an ESP packet. It does this by adding a sequence number to the ESP encapsulation which is verified by the VPN peer so that packets are received within a correct sequence. This will cause issues if for any reason packets are not received in the order in which they were sent out.

This article discusses the causes of this issue and suggests a configuration solution.

Symptoms

By default the SRX Series has a replay window of 64 or 32, depending on the platform. This causes out-of-order packets that are not within this window to be dropped.

SRX>show security ipsec security-associations index 16384 detail

Direction: inbound, SPI: 1993755933, AUX-SPI: 0
Hard lifetime: Expires in 3352 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2775 seconds
Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: -
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
Anti-replay service: enabled, Replay window size: 32 <<<<<<<<<<<

To verify that the SRX is receiving replay errors, decryption errors or replay error logs for the VPN in question, use the show security ipsec statistics and show log messages commands.

SRX> show security ipsec statistics
ESP Statistics:
Encrypted bytes: 2186178848
Decrypted bytes: 2426574164
Encrypted packets: 2812235607
Decrypted packets: 4058561044
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 5674818 <<<<<<
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
 
SRX>show log messages
RT_IPSEC_REPLAY: Replay packet detected on IPSec tunnel on .local..0 with tunnel ID 0x2000d! From 1.1.1.1 to 2.2.2.2, ESP, SPI 0xbd48845f, SEQ 0x347bb.

Solution

  • ISP devices which may be load balancing traffic, routing through different devices due to congestion, or just processing the packets out of order will cause these packets to be dropped. 

  • When a device/interface is handling high loads of traffic out of order, packets may be expected but will be seen as replayed packets and dropped.

  • ISP devices which may be load balancing traffic or just processing the packets out of order will cause these packets to be dropped.

  • Under certain network conditions, especially for high delay networks, fragments may arrive at the SRX with high variance, which results in fragments being dropped because the fragment cache expired. This will cause IPSec traffic to be lost. In the worst case scenario, the loss can happen continuously over several tens of packets. This level of lost traffic will trigger anti-replay logic and cause a false alarm.

  • QoS configurations which may be giving a lower priority to ESP packets may cause out of order packets.

  1. To avoid interoperability issues, make sure this feature is enabled or disabled on both ends in order. Also, configure no-anti-replay on the tunnel having issues so the sequence numbers are not verified.

    #set security vpn name ike no-anti-replay

    vpn vpn-1 {
    bind-interface st0.1;
    vpn-monitor {
    source-interface ge-0/0/2.0;
    destination-ip 192.168.10.253;

    ike {
    gateway gw-1;
    no-anti-replay;
    ipsec-policy ipsec-pol;
              }
    establish-tunnels immediately;

  2. Modify TCP MSS to 1350 in case this is caused due to fragmentation issues.

  3. If unexpected traffic is consuming bandwidth, locate the source of this traffic.

Modification History

2020-06-12: Article reviewed for accuracy; no changes required

Related Information