Description
This article describes how local-in policy is behaving with ingress ESP packets.
Solution
A local-in policy is created to block ESP (protocol 50) packets.
However, FortiGate VPN events still shows logs similar to the below, indicating the packets are not dropped by the policy.
Message meets Alert condition
date=2020-02-24 time=02:07:20 devname=TUNNEL-1 devid=FG1K5Dxxxxxxxxxx logid="0101037131" type="event" subtype="vpn" level="error" vd="root" eventtime=000000000 logdesc="IPsec ESP" msg="IPsec ESP" action="error" remip=208.85.5.74 locip=20.20.20.1 remport=6185 locport=500 outintf="wan1" cookies="N/A" user="N/A" group="N/A" xauthuser="N/A" xauthgroup="N/A" assignip=N/A vpntunnel="N/A" status="esp_error" error_num="Received ESP packet with unknown SPI." spi="4f501234" seq="4f4e1234"
Explanation:
When FortiGate receives an ESP packet, whether it’s UDP encapsulated or not, The IPSec handler checks whether the packet matches an existing SPI.
If it does not, it will drop the packet and generate a log similar to the above.
By design, for ESP packets, this check happens before the local-in policy check.
Related Articles
Technical Note: Filter ingress traffic going to the FortiGate using local-in-policy
