There was a weird situation where I applied a workaround to fix for now. Just wanted to know if there is any other good solution I can deploy in my environment.
Issue: Users were unable to ping the default gateway (setup on Fortigate) though the interface had PING enabled. After analyzing the logs, I found that the FG was dropping off the packet considering it to be high threat. The issue seems to be the admin profile I had setup on the device. There were only 2 subnets which were defined as protected subnet. I guess the issue was the Fortigate considering only the management traffic trusted only from the defined protected subnet and rest all as untrusted, so it was dropping packets for untrsuted network even when they were connected directly to the Fortigate.
Workaround: I created a test profile with no access and applied it on a test user profile. After this, the FG interface started responding.
So, just wanted to know if there is any CLI command where I can defined PING to be allowed from any network for the PING enabled interface?
I can see the local-in firewall policy and even after removing the dummy profile I created, it remains same allowing ICMP_ANY service. I have a query- does Fortigate check for threshold count before considering the source untrusted and then modify the local-in FW policy?
I don't know the inner workings and dependencies between GUI "Trusted Hosts" and the local-in policies. But fortunately I don't have to. The local-in policies are effective - traffic traverses top-down. If not matched at the end traffic reaches the management.
I think you got me wrong. Sometimes settings in the GUI "look" different or are spread over several distinct settings in the CLI but still they need to be changed manually. For example, checking the option "Use dedicated management port" in the HA setup GUI sets up 3 options in the CLI, "config system ha".
I would always expect that both representations are in sync at all times. Removing the dummy admin should then change the local-in policy as well. If not, I'd consider this a bug.
The "Trusted Hosts" are trusted because you declare them to be. It's a whitelist of IP addresses for admin access.
If you want to further protect the admin access (without TH) then you may add an IPS rate filter to a local-in policy. Rate filters looks for certain events (traffic patterns) which are detected by an IPS signature, count and time them and trigger an action if the event occurs more often per time unit than specified. The client IP address is then either blocked permanently or suspended for some time period.
The goal is to prevent brute forcing a password protected access.
In the past, I've posted such an IPS rate filter here, searching should find it. In v5.2, IPS rate filters can be created in the GUI. The difficult part probably is how to detect an invalid login attempt, by scanning either client traffic or the server's response messages.
If you mean that the issue was caused due to IPS action, I would agree with you to great extent. The Local-in-policy had the ICMP allowed and again the issue was encountered today. So, my solution with a profile with no access defined with protected subnet allowed accessible any was the right solution and working now..
no, we both are only assuming that local-in policies can take an IPS sensor. It would just be beautiful to assume that a similar construct would allow similar options. I didn't have the resources on Sunday to test this but may do so in the next days.
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.