|
Issue:
PING is enabled as Administrative Access on the interface, yet the interface does not reply to Ping requests.
Cause:
Local-in policy or trusted hosts are defined for Admin accounts.
Solution:
Trusted hosts also apply to ICMP echo requests.
To have the FortiGate respond to ping requests, whatever the originator, add a restrictive Admin account with no trusted hosts associated with it. For example, default 0.0.0.0/0.0.0.0. Give the new Admin account a complex name, set it with an Access Profile that has no privileges, and use a complex password.
Verify whether a local-in policy has been configured to block ping requests.
config firewall local-in-policy
show
Sample config for allowing ICMP
config firewall local-in-policy
edit 10
set intf "port1"
set srcaddr "all"
set dstaddr "wan_ip_fgt"
set service "PING"
set schedule "always"
next
end
To verify the ping traffic, run the following command.
diagnose sniffer packet any " host x.x.x.x and icmp" 4 0 l
Note:
From v6.0.x onwards, ping service on management interfaces is not included within the scope of trusted hosts. This means that it will be possible to ping the interface from an IP that is not included within trusted hosts.
Make sure Ping is enabled on the network interface:
config system interface
edit portx <----- Port number.
set allowaccess ping
end
Ping-options can also be used from FortiGate to ping the destination device.
execute ping-options source a.a.a.a -> a.a.a.a is the interface IP.
execute ping b.b.b.b -> b.b.b.b is the destination IP
To verify traffic flow, run the below debug:
diagnose debug flow filter addr b.b.b.b -> b.b.b.b is the destination IP.
diagnose debug flow filter proto 1
diagnose debug enable
diagnose debug flow trace start 20
Local in Policy deny logs:
id=20085 trace_id=1 func=fw_local_in_handler line=474 msg="iprope_in_check() check failed on policy 1, drop"
|
