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
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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:
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 :
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.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1702 | |
1092 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.