ESP not being blocked by local-in-policy for existing IPsec Session?

[tanr]

On our 5.6.5 FortiGates, I'm seeing what looks like attempted attacks on our IPsec connection to a branch office, but am unclear how they are getting past my local-in-policy to get blocked further in.

The VPN log event I see is "Received ESP packet with unknown SPI." coming from an IP that is NOT our branch office.

It seems clear this is an attempted attack because I'll see the same thing, from the same IP, tried in sequence against all of our public IPs.

I have a local-in-policy rule which specifically allows IKE, ESP, and NATT only from our branch office public IP to our main office public IP, followed by a local-in-policy rule which specifically denies IKE, ESP, and NATT to any of our public IPs.

What I don't understand is how this packet is getting past the local-in-policy that should be specifically denying it.

Any ideas what might be going on here?

[darwin_FTNT]

Do you have the mantis bug no.?  Also a specific pcap to replay and sample configuration to block would help.  The team handling the mantis bug have already processed it and more familiar with it (my group belong to the IPS module though).  Thanks.

[tanr]

Already handed off configs and pcaps as part of the ticket.  No bug number since it was "by design", though I think a design change should be considered.

If you'd like to follow up feel free to PM me for the ticket number.

[tanr]

Okay all, I have more information and a bug number for this issue.  Thanks, @darwin_FTNT, for following up on this.

Bug number is 0515255.

My understanding from the ticket is that the IKE/ESP connections are actually being blocked by the local-in-policy, but that in this case the report of a UDP encapsulated ESP packet without matching SPI is received (or maybe generated?) *before* the local-in-policy blocks it.  

So (if I'm understanding the explanation) the local-in-policy is correctly blocking this, but the report / log entry is getting generated before the blocking happens, which is causing us to see all these error reports.

I've asked that my ticket be changed to "Pending Bug Fix" so I can track this.

[tanr]

Fortinet have decided to close this without changing the behavior.

I don't know if the fix was difficult or a design issue, but it's really too bad, as the noise from these sort of invalid logs can hide actual attack attempts.