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?

[tanr]

Any ideas on how local-in-policy is letting through these ESP packets?

Could I have local-in-policy misconfigured? 

Maybe I need to have the local-in-deny policy destination address be something more than our public facing IPs?

Or perhaps I need to block ISKAMP TCP 0 as shown in http://kb.fortinet.com/kb/viewContent.do?externalId=FD36318&sliceId=1? 

Any ideas appreciated.

[scyllaAndy]

I'm seeing the same thing recently where my local-in-policies aren't stopping attempts from 144.217.0.0/16 across 20 or so of my FortiGate devices that have ipsec VPN setup.  They have specifically been coming from 144.217.181.56.  Thanks for finding that Technical note about creating an ISAKMP service.  I'm going to try that now on a handful of my devices along with my existing deny policy for IKE, GRE, and ESP.

[tanr]

I've already tried the ISKAMP method and am still seeing the attempts come in and not get blocked by local-in-policy.  

I'll be calling TAC tomorrow to bring them in on this.  If you've already created a ticket on this and have a reference number from Fortinet please let me know (through PM if desired) and I'll refer to it when opening my own ticket.

[scyllaAndy]

Strangely enough, I haven't had any attacks since creating the ISAKMP service, but I think that is just dumb luck.  I don't have a ticket open with support yet, but will do so if you think it will help your ticket out.  Just send me your ticket number and I'll put one in to link them together.  Otherwise, please let me know what they say.

Thanks!

[tanr]

I've created a support ticket for this, will post if I get any more info.

[newcit]

Were you able to get any additional help from support on this?  We are seeing the same thing.

Thanks.

[scyllaAndy]

Fortinet support unfortunately said that there is nothing that can be done about these at this time.  The packets are actually coming in on UDP 4500 and local-in-policies cannot block those.  The alerts say UDP 500, but that isn't how they originate.

So - the only fix at this point in time is to get an edge router device to block the packets or disable/tolerate the constant alerts.

[tanr]

That's the answer I got as well.   

I've got a couple EdgeRouters sitting on my desk to possibly filter UDP 4500, though I really don't like that solution.

Does it seem appropriate that the log entry for this has level="alert"?  If it was a lower level I could perhaps filter the notification out from the FAZ.

[tanr]

Thinking about this, if I was doing vdoms perhaps I could have a separate vdom with a virtual wire pair that would do the filtering for me.  Don't think I can do this without vdoms though, due to the routing limitations.  Bleah.