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

[auerhahn]

Hello,

since a few days i am getting error notifications from one of my VPN Interfaces:

Message meets Alert condition
date=2022-03-08 time=19:56:42 deventtime=1646765802743694420 tz="+0100" logid="0101037128" type="event" subtype="vpn" level="error" vd="root" logdesc="Progress IPsec phase 1" msg="progress IPsec phase 1" action="negotiate" remip=109.90.XX.XX locip=185.88.XX.XX remport=500 locport=500 outintf="wan2" cookies="5f648bb6bf2a59f4/160e2a9da9745054" user="N/A" group="N/A" useralt="N/A" xauthuser="N/A" xauthgroup="N/A" assignip=N/A vpntunnel="VPN-App" status="failure" init="remote" mode="main" dir="inbound" stage=3 role="responder" result="ERROR"

Message meets Alert condition
date=2022-03-08 time=19:56:42 devname=Auerhahn-Primary-60F devid=FGT60FTK19001713 eventtime=1646765802743658120 tz="+0100" logid="0101037124" type="event" subtype="vpn" level="error" vd="root" logdesc="IPsec phase 1 error" msg="IPsec phase 1 error" action="negotiate" remip=109.90.XX.XX locip=185.88.XX.XX remport=500 locport=500 outintf="wan2" cookies="5f648bb6bf2a59f4/160e2a9da9745054" user="N/A" group="N/A" useralt="N/A" xauthuser="N/A" xauthgroup="N/A" assignip=N/A vpntunnel="VPN-App" status="negotiate_error" reason="probable preshared key mismatch" peer_notif="NOT-APPLICABLE"

I tried to block those attempts with local-in-policy:

config firewall local-in-policy

    edit 1

        set uuid ccd0a336-9ee7-51ec-98d3-876b3e95b348

        set intf "wan2"

        set srcaddr "Banned_IPs"

        set dstaddr "all"

        set service "ALL"

        set schedule "always"

    next

end

Banned IPs contain the suspicious IP.

But i still get those errors. What am i doing wrong?

Thanks for hints,

Tobias

[Sachin_Alex_Cherian_]

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-negotiation...

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

[slautenschlager]

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/p...

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

[Tristan_C]

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

[auerhahn]

 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.

[ede_pfau]

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.