VPN failures and negotiate errors from Suspicious IP - Local in Policy Not Working

Hi,

Is this a dial-up VPN or site to site VPN?

If you have already established that the source IP is malicious you can block the same using local-in-policy. The below link explains it to some extent:

https://docs.fortinet.com/document/fortigate/6.2.7/cookbook/201046/blocking-unwanted-ike-negotiations-and-esp-packets-with-a-local-in-policy

Perhaps, if you cross verify and find the config to be correct, you can verify the processing using the flow trace commands on Fortigate.

Dear Tobias,

the local-in-policy should match the traffic from what I see in the logs. As you still receive these events it would be worth to make the debug flow trace as my colleague already stated to see why this traffic is still arriving the kernel. 

Another approach would be to create a DoS policy for these source addresses with a very low threshold for udp flood for service IKE as the DoS policy is handled before reaching the IKE daemon :

https://docs.fortinet.com/document/fortigate/6.2.0/parallel-path-processing-life-of-a-packet/86811/packet-flow-ingress-and-egress-fortigates-without-network-processor-offloading

In case you still see these log entries even with correct configured localin and DoS policy from these sources I would suggest to raise a TAC case to have a closer look on this issue.

Best Steffen

The IPsec engine is before the Kernel I believe as stated previously

 Thanks for all your answer. I have made a trace on UDP Port 500:

d=20085 trace_id=39 func=print_pkt_detail line=5727 msg="vd-root:0 received a packet(proto=17, 109.90.XX.XX:500->185.88.XX.XX:500) from wan2. "

id=20085 trace_id=39 func=resolve_ip_tuple_fast line=5808 msg="Find an existing session, id-06864a14, reply direction"

id=20085 trace_id=40 func=print_pkt_detail line=5727 msg="vd-root:0 received a packet(proto=17, 185.88.XX.XX:500->109.90.XX.XX:500) from local. "

id=20085 trace_id=40 func=resolve_ip_tuple_fast line=5808 msg="Find an existing session, id-06864a14, original direction"

id=20085 trace_id=40 func=ipd_post_route_handler line=490 msg="out wan2 vwl_zone_id 1, state2 0x10000, quality 1.

109.90.XX.XX is the suspicious IP. I can't see any specific reason why this Packet is allowed, or do i need another trace command? 

I used 

# diagnose debug flow filter dport 500 # diagnose debug flow trace start 10 # diagnose debug enable

I played a little bit with DoS filters, also nu real success. The Suspicious IP tries to connect all 2-3 minutes with 5 retries  i think, which is to low volume for a dos filter to step in i think.

In the CLI, please run a

"show full | grep -f "109.90.XX.XX"

From the trace it appear to me the the incoming packet is allowed in an already established session from inside to WAN. That would explain why the local-in policy doesn't catch it.