Let's troubleshoot... We also do trainings .. Checkout our training page https://asame2.blogspot.com/p/we-also-deliver-trainings.html

Featured Post

How to generate a CSR on Cisco ASA using CLI? CSR- (Certificate signing request)

First thing we need is an RSA key pair:   crypto key generate rsa label SSL-Key modulus 1024 noconfirm Create a trust-point crypto ca...

Recent Comments

Recent Post

Wednesday 13 January 2016

Replay check failed on Cisco Router with IPsec


Hello Again!!!

You are absolutely right, I am back with another issue with VPN :(

So this time, I have a router and have VTI tunnel setup on it. I don't know how it all started but I now see some logs on my router :

%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
        connection id=3625, sequence number=1281790

So I started to figure out what does this message mean?

Replay Attack: A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. In a replay attack someone records legitimate communications and repeats them in order to impersonate a valid user, and to disrupt or cause negative impact for legitimate connections.

 Replay Check Failure: IPSec provides anti-replay protection against an attacker who duplicates encrypted packets with the assignment of a monotonically increasing sequence number to each encrypted packet. The receiving IPSec endpoint keeps track of which packets it has already processed on the basis of these numbers with the use of a sliding window of all acceptable sequence numbers. Currently, the default anti-replay window size in Cisco IOS implementation is 64 packets.

How the incoming IPSec traffic on the receiving tunnel endpoint will be processed with anti-replay enabled?

 

  1. When a packet is received, if the sequence number falls within the window and was not previously received, the packet is accepted, and marked as received before it is sent to integrity verification.
  2. If the sequence number falls within the window and was previously received, the packet is dropped, and the replay counter is incremented. (In this case a replay check failure occurs, and the router displays an error message similar to this: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed)
  3. If the sequence number is greater than the highest sequence number in the window, the packet is accepted, and marked as received. The sliding window is then moved to the right.
  4. If the sequence number is less than the lowest sequence in the window, the packet is dropped, and the replay counter is incremented. (In this case a replay check failure occurs, and the router displays an error message similar to this: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed)
I have referred this doc here:

http://www.cisco.com/c/en/us/support/docs/ip/internet-key-exchange-ike/116858-problem-replay-00.html#anc2



If the window size is small (which it is by default 64) then the packet gets dropped due to a replay failure (it is not really an attack).
In such scenarios, increase the size of the replay window in order to ensure that such delays are accounted for and prevent legitimate packets from being dropped. By default, the window size is fairly small (window size of 64). If you increase the size, it does not greatly increase the risk of an attack.

Use show crypto ipsec sa peer ip-address platform command in order to verify the hardware anti-replay window size.
 
How can I change the Window size?

1. Change the window size globally : Configure IPsec Anti-Replay Window: Expanding and Disabling globally (so that it affects all SAs that are created— except for those that are specifically overridden on a per-crypto map basis)
crypto ipsec security-association replay window-size 512

2. Configuring IPsec Anti-Replay Window: Expanding and Disabling
on a Crypto Map 

crypto map Test 10 ipsec-isakmp
set security-association replay window-size 512

 

  

 

 

0 comments: