Experience with MSR36 not being able to communicate due to IPsec anti-replay function
- 0 Followed
- 0Collected ，3643Browsed
Network Topology
HQ (MSR3620) establishes IPsec with Branch (MSR1008)
Problem Description
HQ (MSR3620) establishes IPsec with Branch (MSR1008) and can negotiate IKE/IPsec SA, but private network services are blocked.
Process Analysis
The general troubleshooting ideas for this type of problem are: confirm whether the IPSec SA at both ends is consistent, confirm whether the IPSec SA count is normal, and confirm the location of packet loss.
1. Confirm whether the SA table entries are consistent, and generally pay attention to the following points:
a. Whether the interface corresponding to the SA is consistent with the configuration expectation;
b. Whether the flow of interest is completely symmetrical;
c. Whether the branch in SPI is consistent with the headquarters out SPI, and whether the branch out SPI is consistent with the headquarters in SPI.
In this case, the above parameters are all correct.
|
Branch |
HQ |
|
===============display ipsec sa=============== ------------------------------- Interface: Tunnel1 -------------------------------
----------------------------- IPsec profile: Almaty_prof Mode: ISAKMP ----------------------------- Tunnel id: 1 Encapsulation mode: tunnel Perfect forward secrecy: Transmitting entity: Responder Path MTU: 1326 Tunnel: local address: 172.21.0.78 remote address: 172.21.0.70 Flow: sour addr: 0.0.0.0/0.0.0.0 port: 0 protocol: ip dest addr: 0.0.0.0/0.0.0.0 port: 0 protocol: ip
[Inbound ESP SAs] SPI: 378128209 (0x1689c751) Connection ID: 1053894780125186 Transform set: ESP-ENCRYPT-AES-CBC-128 ESP-AUTH-SHA1 SA duration (kilobytes/sec): 1843200/3600 SA remaining duration (kilobytes/sec): 1816349/2437 Max received sequence-number: 50432 Anti-replay check enable: Y Anti-replay window size: 64 UDP encapsulation used for NAT traversal: N Status: Active
[Outbound ESP SAs] SPI: 2330739159 (0x8aec41d7) Connection ID: 1155346202624 Transform set: ESP-ENCRYPT-AES-CBC-128 ESP-AUTH-SHA1 SA duration (kilobytes/sec): 1843200/3600 SA remaining duration (kilobytes/sec): 1830608/2437 Max sent sequence-number: 40292 UDP encapsulation used for NAT traversal: N Status: Active |
===============display ipsec sa=============== ------------------------------- Interface: Tunnel18 -------------------------------
----------------------------- IPsec profile: Konaev_prof Alias: profile-Konaev_prof Mode: ISAKMP ----------------------------- Tunnel id: 0 Encapsulation mode: tunnel Perfect forward secrecy: Transmitting entity: Initiator Path MTU: 1326 Tunnel: local address/port: 172.21.0.70/500 remote address/port: 172.21.0.78/500 Flow: sour addr: 0.0.0.0/0.0.0.0 port: 0 protocol: ip dest addr: 0.0.0.0/0.0.0.0 port: 0 protocol: ip
[Inbound ESP SAs] SPI: 2330739159 (0x8aec41d7) Connection ID: 1086626725891 Transform set: ESP-ENCRYPT-AES-CBC-128 ESP-AUTH-SHA1 SA duration (kilobytes/sec): 1843200/3600 SA remaining duration (kilobytes/sec): 1829866/2372 Max received sequence-number: 43658 Anti-replay check enable: Y Anti-replay window size: 64 UDP encapsulation used for NAT traversal: N Status: Active
[Outbound ESP SAs] SPI: 378128209 (0x1689c751) Connection ID: 803158884354 Transform set: ESP-ENCRYPT-AES-CBC-128 ESP-AUTH-SHA1 SA duration (kilobytes/sec): 1843200/3600 SA remaining duration (kilobytes/sec): 1814258/2372 Max sent sequence-number: 57725 UDP encapsulation used for NAT traversal: N Status: Active |
2. After confirming that ipsec sa is correct, you need to check the packet sending and receiving status at both ends. The commonly used command is dis ipsec statistics. In this case, the branch device is used as an example to check the status.
===============display ipsec statistics===============
IPsec packet statistics:
Received/sent packets: 12974210/10251814
Received/sent bytes: 10986853200/1655580064
Dropped packets (received/sent): 410351/0
Dropped packets statistics
No available SA: 2
Wrong SA: 0
Invalid length: 0
Authentication failure: 0
Encapsulation failure: 0
Decapsulation failure: 0
Replayed packets: 410349 // This count is abnormal, indicating that the branch device determines that the message is a replay packet and will discard it.
ACL check failure: 0
MTU check failure: 0
Loopback limit exceeded: 0
Crypto speed limit exceeded: 0
===================================================
The IPsec anti-replay function of the MSR device is enabled by default. Generally, this type of count occurs because after the device receives the IPsec message, it determines that the message is a replay packet based on the message ID. The device believes that parsing such messages is meaningless and takes up performance, so it is discarded. The occurrence of such messages may be related to the ID encapsulation behavior of the packet sending device, the NAT modification of the message header by the intermediate device, and the disorder of the message sending and receiving due to line congestion. You can manually turn off the anti-replay detection by undo IPsec anti-replay check.
Solution
Disable ipsec anti-replay check to solve the problem.
Command:
undo ipsec anti-replay check