이 문서에서는 IPsec(Internet Protocol Security) 재전송 방지 검사 실패와 관련된 문제에 대해 설명하고 가능한 해결책을 제공합니다.
리플레이 공격은 유효한 데이터 전송이 악의적 또는 부정하게 기록되고 나중에 반복되는 네트워크 공격의 한 형태입니다. 합법적인 통신을 녹음하고 이를 반복하는 사람이 올바른 사용자를 가장하여 합법적인 연결에 부정적인 영향을 주거나 방해하기 위해 보안을 파괴하려는 시도입니다.
IPsec에서 암호화된 각 패킷에 단조롭게 증가하는 시퀀스 번호를 할당하여 공격자에 대한 재전송 방지 보호를 제공합니다. 수신 IPsec 끝점은 이러한 번호를 사용할 때 이미 처리된 패킷과 허용 가능한 시퀀스 번호의 슬라이딩 윈도우를 추적합니다. Cisco IOS® 구현의 기본 재전송 방지 창 크기는 이 이미지에 표시된 대로 64개 패킷입니다.

IPsec 터널 엔드포인트에 재전송 방지 보호가 활성화된 경우 수신 IPsec 트래픽은 다음과 같이 처리됩니다.
재생 확인 실패가 발생하고 패킷이 삭제되는 경우 라우터는 다음과 유사한 syslog 메시지를 생성합니다.
%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle n, src_addr x.x.x.x, dest_addr y.y.y.y, SPI 0xzzzzzzzz
앞서 설명한 것처럼, 재생 검사의 목적은 합법적인 패킷의 악의적인 반복을 방지하는 것입니다. 재생 검사가 실패할 수 있는 몇 가지 일반적인 조건은 다음과 같습니다.
IPsec 재생 삭제 트러블슈팅의 핵심은 재생으로 인해 어떤 패킷이 삭제되었는지 식별하고, 패킷 캡처를 사용하여 이러한 패킷이 실제로 재생된 패킷인지 또는 재생 창 외부에 있는 수신 라우터에 도착한 패킷인지 확인하는 것입니다. 삭제된 패킷을 스니퍼 추적에서 캡처한 패킷과 정확히 일치시키기 위해 첫 번째 단계는 삭제된 패킷이 속한 피어 및 IPsec 흐름과 패킷의 ESP 시퀀스 번호를 식별하는 것입니다.
Cisco IOS® XE 소프트웨어를 실행하는 라우터 플랫폼에서, 삭제된 패킷이 속하는 피어 및 특정 터널을 식별하는 데 도움이 되도록 재생 삭제가 발생할 때 피어 및 IPsec SPI(Security Parameter Index)에 대한 정보가 syslog 메시지에 인쇄됩니다. 그러나 ESP 시퀀스 번호는 이 출력에 인쇄되지 않습니다. ESP 시퀀스 번호는 지정된 IPsec 흐름 내에서 IPsec 패킷을 고유하게 식별하는 데 사용됩니다. 시퀀스 번호가 없으면 패킷 캡처에서 어떤 패킷이 삭제되는지 정확하게 식별하기가 어려워집니다.
Cisco IOS® XE datapath 패킷 추적 기능은 다음과 같은 syslog 메시지와 함께 재생 삭제를 확인할 때 이 상황에서 사용할 수 있습니다.
%IOSXE-3-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:060 TS:00000001132883828011
%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 3, src_addr 10.2.0.200, dest_addr 10.1.0.100, SPI 0x4c1d1e90
삭제된 패킷의 ESP 시퀀스 번호를 식별하기 위해 패킷 추적 기능을 사용하여 다음 단계를 완료합니다.
1단계. 피어 디바이스의 트래픽을 매칭하려면 플랫폼 조건부 디버그 필터를 설정합니다.
debug platform condition ipv4 10.2.0.200/32 ingress
debug platform condition start
2단계. 패킷 헤더 정보를 복사하려면 copy 옵션을 사용하여 패킷 추적을 활성화합니다.
debug platform packet-trace packet 64
debug platform packet-trace copy packet input l3 size 100
3단계. 재생 오류가 감지되면 패킷 추적 버퍼를 사용하여 재생으로 인해 삭제된 패킷을 식별하고 복사된 패킷에서 ESP 시퀀스 번호를 찾을 수 있습니다.
Router#show platform packet-trace summary
Pkt Input Output State Reason
0 Gi4/0/0 Tu1 CONS Packet Consumed
1 Gi4/0/0 Tu1 CONS Packet Consumed
2 Gi4/0/0 Tu1 CONS Packet Consumed
3 Gi4/0/0 Tu1 CONS Packet Consumed
4 Gi4/0/0 Tu1 CONS Packet Consumed
5 Gi4/0/0 Tu1 CONS Packet Consumed
6 Gi4/0/0 Tu1 DROP 053 (IpsecInput)
7 Gi4/0/0 Tu1 DROP 053 (IpsecInput)
8 Gi4/0/0 Tu1 CONS Packet Consumed
9 Gi4/0/0 Tu1 CONS Packet Consumed
10 Gi4/0/0 Tu1 CONS Packet Consumed
11 Gi4/0/0 Tu1 CONS Packet Consumed
12 Gi4/0/0 Tu1 CONS Packet Consumed
13 Gi4/0/0 Tu1 CONS Packet Consumed
이전 출력에서는 패킷 번호 6과 7이 삭제되었으므로 이제 자세히 검토할 수 있습니다.
Router#show platform packet-trace packet 6
Packet: 6 CBUG ID: 6
Summary
Input : GigabitEthernet4/0/0
Output : Tunnel1
State : DROP 053 (IpsecInput)
Timestamp : 3233497953773
Path Trace
Feature: IPV4
Source : 10.2.0.200
Destination : 10.1.0.100
Protocol : 50 (ESP)
Feature: IPSec
Action : DECRYPT
SA Handle : 3
SPI : 0x4c1d1e90
Peer Addr : 10.2.0.200
Local Addr: 10.1.0.100
Feature: IPSec
Action : DROP
Sub-code : 019 - CD_IN_ANTI_REPLAY_FAIL
Packet Copy In
45000428 00110000 fc329575 0a0200c8 0a010064 4c1d1e90 00000006 790aa252
e9951cd9 57024433 d97c7cb8 58e0c869 2101f1ef 148c2a12 f309171d 1b7a4771
d8868af7 7bae9967 7d880197 46c6a079 d0143e43 c9024c61 0045280a d57b2f5e
23f06bc3 ab6b6b81 c1b17936 98939509 7aec966e 4dd848d2 60517162 9308ba5d
ESP 시퀀스 번호는 이전 출력에서 굵게 강조된 대로 IP 헤더의 시작으로부터 24바이트(또는 IP 패킷 페이로드 데이터의 4바이트)의 오프셋을 갖습니다. 이 특정 예에서 삭제된 패킷의 ESP 시퀀스 번호는 0x6입니다.
재생 확인 실패로 인해 삭제된 패킷에 대한 패킷 정보를 식별하는 것 외에 문제의 IPsec 흐름에 대한 패킷 캡처를 동시에 수집해야 합니다. 이는 동일한 IPsec 흐름 내에서 ESP 시퀀스 번호 패턴을 검사하여 재생 삭제 이유를 확인하는 데 도움이 됩니다. Cisco IOS XE 라우터에서 EPC(Embedded Packet Capture)를 사용하는 방법에 대한 자세한 내용은 Embedded Packet Capture for Cisco IOS and Cisco IOS XE Configuration Example을 참조하십시오.
WAN 인터페이스의 암호화된(ESP) 패킷에 대한 패킷 캡처가 수집되면 Wireshark를 사용하여 임의의 시퀀스 번호 이상 징후에 대한 ESP 시퀀스 번호 분석을 수행할 수 있습니다. 먼저 이미지에 표시된 대로 Preferences(환경 설정) > Protocols(프로토콜) > ESP에서 Sequence Number Check(시퀀스 번호 확인)가 활성화되어 있는지 확인합니다.

다음으로, 다음과 같이 Analyze(분석) > Expert information(전문가 정보)에서 ESP Sequence Number(ESP 시퀀스 번호) 문제를 확인합니다.

다음과 같이 추가 세부사항을 보려면 잘못된 시퀀스 번호의 패킷을 클릭합니다.

피어가 식별되고 재생 삭제에 대한 패킷 캡처가 수집되면 재생 실패를 설명할 수 있는 세 가지 시나리오가 있습니다.
Cisco IOS를 사용하는 레거시 ISR G2 Series 라우터의 IPsec 재생 삭제는 Cisco IOS XE를 사용하는 라우터와 다릅니다.
%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=529, sequence number=13
메시지 출력이 피어 IP 주소 또는 SPI 정보를 제공하지 않습니다. 이 플랫폼에서 문제를 해결하려면 오류 메시지에 "conn-id"를 사용하십시오. 재생은 SA별 검사(피어별이 아님)이므로 오류 메시지에서 "conn-id"를 식별하고 show crypto ipsec sa 출력에서 이를 찾습니다. syslog 메시지는 패킷 캡처에서 삭제된 패킷을 고유하게 식별하는 데 도움이 되는 ESP 시퀀스 번호도 제공합니다.
이 그림은 다음과 같습니다.
%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=529, sequence number=13
Router#show crypto ipsec sa | in peer|conn id
current_peer 10.2.0.200 port 500
conn id: 529, flow_id: SW:529, sibling_flags 80000046, crypto map: Tunnel0-head-0
conn id: 530, flow_id: SW:530, sibling_flags 80000046, crypto map: Tunnel0-head-0
Router#
Router#show crypto ipsec sa peer 10.2.0.200 detail
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 10.1.0.100
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 10.2.0.200 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 27, #pkts encrypt: 27, #pkts digest: 27
#pkts decaps: 27, #pkts decrypt: 27, #pkts verify: 27
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 21
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 10.1.0.100, remote crypto endpt.: 10.2.0.200
path mtu 2000, ip mtu 2000, ip mtu idb Serial2/0
current outbound spi: 0x8B087377(2332586871)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xE7EDE943(3891128643)
transform: esp-gcm ,
in use settings ={Tunnel, }
conn id: 529, flow_id: SW:529, sibling_flags 80000046, crypto map:
Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4509600/3223)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
<SNIP>
이 출력에서 알 수 있듯이, 재생 삭제는 10.2.0.200 피어 주소에서 0xE7EDE943의 인바운드 ESP SA SPI로 시작합니다. 삭제된 패킷의 ESP 시퀀스 번호는 로그 메시지 자체에서도 13임을 확인할 수 있습니다. 피어 주소, SPI 번호 및 ESP 시퀀스 번호의 조합을 사용하여 패킷 캡처에서 삭제된 패킷을 고유하게 식별할 수 있습니다.
이전 Cisco IOS XE 릴리스를 실행하는 라우터에서 syslog에 보고된 "REPLAY_ERROR"는 재생된 패킷이 삭제되는 피어 정보와 함께 실제 IPsec 흐름을 인쇄할 수 없습니다.
%IOSXE-3-PLATFORM: F0: cpp_cp: QFP:00 Thread: 095 TS:00000000240306197890
%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 3
올바른 IPsec 피어 및 흐름 정보를 식별하려면 QFP(Quantum Flow Processor)에서 IPsec 흐름 정보를 검색하려면 syslog 메시지에 인쇄된 DP(Data Plane) Handle을 이 명령의 입력 매개 변수 SA Handle로 사용합니다.
Router#show platform hardware qfp active feature ipsec sa 3
QFP ipsec sa Information
QFP sa id: 3
pal sa id: 2
QFP spd id: 1
QFP sp id: 2
QFP spi: 0x4c1d1e90(1276976784)
crypto ctx: 0x000000002e03bfff
flags: 0xc000800
: src:IKE valid:Yes soft-life-expired:No hard-life-expired:No
: replay-check:Yes proto:0 mode:0 direction:0
: qos_preclassify:No qos_group:No
: frag_type:BEFORE_ENCRYPT df_bit_type:COPY
: sar_enable:No getvpn_mode:SNDRCV_SA
: doing_translation:No assigned_outside_rport:No
: inline_tagging_enabled:No
qos_group: 0x0
mtu: 0x0=0
sar_delta: 0
sar_window: 0x0
sibling_sa: 0x0
sp_ptr: 0x8c392000
sbs_ptr: 0x8bfbf810
local endpoint: 10.1.0.100
remote endpoint: 10.2.0.200
cgid.cid.fid.rid: 0.0.0.0
ivrf: 0
fvrf: 0
trans udp sport: 0
trans udp dport: 0
first intf name: Tunnel1
<SNIP>
EEM(Embedded Event Manager) 스크립트를 사용하여 데이터 수집을 자동화할 수도 있습니다.
event manager applet Replay-Error
event syslog pattern "%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error"
action 1.0 regexp "([0-9]+)$" "$_syslog_msg" dph
action 2.0 cli command "enable"
action 3.0 cli command "show platform hardware qfp active feature ipsec sa $dph |
append bootflash:replay-error.txt"
이 예에서는 수집된 출력이 부트플래시로 리디렉션됩니다. 이 출력을 보려면 more bootflash:replay-error.txt 명령을 사용합니다.
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
7.0 |
14-Sep-2026
|
재인증 |
6.0 |
21-Nov-2025
|
기계 번역, 브랜딩, 서식 지정 및 일부 링크를 수정했습니다. |
5.0 |
04-Sep-2024
|
업데이트된 SEO, 기계 번역, 참조 및 서식. |
2.0 |
13-Feb-2022
|
추가 정보 |
1.0 |
15-Dec-2013
|
최초 릴리스 |