FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
ccho
Staff
Staff
Article Id 305165
Description

 

This article describes the new anti-spoof IPsec VPN logic that was introduced in FortiOS7.4.2. If proper conditions are not met, the traffic may be dropped as 'anti-spoof check failed, drop'.

 

Scope

 

FortiOS 7.4.2+.

 

Solution

 

Starting 7.4.2, traffic arriving through the IPsec VPN tunnel must match a valid traffic selector negotiated in the phase2 configuration of the IPsec VPN.

If there is no match for the traffic, the traffic is dropped as a spoof.

 

Packet sniffer shows traffic arriving:

 

diagnose sniffer packet any " host 10.20.50.2 and icmp " 4 0 l
interfaces=[any]
filters=[ host 10.26.10.41 and icmp ]
2024-02-27 17:26:13.425459 TESTVPN in 10.10.50.2 -> 10.20.50.2: icmp: echo request
2024-02-27 17:26:14.443703 TESTVPN in 10.10.50.2 -> 10.20.50.2: icmp: echo request
2024-02-27 17:26:15.425146 TESTVPN in 10.10.50.2 -> 10.20.50.2: icmp: echo request
2024-02-27 17:26:16.435445 TESTVPN in 10.10.50.2 -> 10.20.50.2: icmp: echo request
2024-02-27 17:26:17.452851 TESTVPN in 10.10.50.2 -> 10.20.50.2: icmp: echo request

 

Debug flow shows the following output:

 

2024-02-27 17:45:40 id=65308 trace_id=1311 func=print_pkt_detail line=5888 msg="vd-root:0 received a packet(proto=1, 10.10.50.2:53450->10.20.50.2:2048) tun_id=123.123.123.123 from TESTVPN. type=8, code=0, id=53450, seq=0."
2024-02-27 17:45:40 id=65308 trace_id=1311 func=ipsec_input4 line=279 msg="anti-spoof check failed, drop"

 

Confirm negotiated phase2 settings with the command 'diagnose vpn tunnel list'.

 

proxyid_num=2 child_num=0 refcnt=5 ilast=0 olast=3 ad=/0
stat: rxp=80022 txp=395 rxb=14809443 txb=25814
dpd: mode=on-idle on=1 idle=20000ms retry=3 count=0 seqno=36
natt: mode=none draft=0 interval=0 remote_port=0
fec: egress=0 ingress=0
proxyid=TESTVPN proto=0 sa=1 ref=3 serial=13
src: 0:0.0.0.0-255.255.255.255:0
dst: 0:192.168.10.0-192.168.10.3:0
SA: ref=3 options=10025 type=00 soft=0 mtu=1446 expire=1733/0B replaywin=0
seqno=8 esn=0 replaywin_lastseq=00000000 qat=0 rekey=0 hash_search_len=1
life: type=01 bytes=0/0 timeout=1767/1800
dec: spi=36123e0e esp=3des key=24 d569b167770be97121e5b0a6545519b52c991f526864ec12
ah=sha1 key=20 f028a15a42b0dcdd26ffc77838b4851928c875ea
enc: spi=dd113712 esp=3des key=24 991b59099c3f8dd69576fa102e3c308997b544a62a3fc2b8
ah=sha1 key=20 3494b9d54e11e14486554b0f0ad70522586b065a
dec:pkts/bytes=1365/263845, enc:pkts/bytes=7/824
npu_flag=00 npu_rgwy=123.123.123.123 npu_lgwy=123.123.123.123 npu_selid=ff dec_npuid=0 enc_npuid=0
proxyid=TESTVPN proto=0 sa=0 ref=1 serial=14

 

The remote host '10.10.50.2' is not part of the negotiated traffic selectors for the VPN tunnel 'TESTVPN'. Traffic from 10.10.50.2 is dropped as a spoof.

 

To address this problem, both VPN gateways must agree on proper traffic selectors for the expected traffic through the tunnel.

 

Run the debug flow.

 

Related document:

How to run a debug flow

Contributors