Understanding local-in-policy usage in FortiGate

When we think about firewall security policy, generally we consider the hosts and networks behind the firewall interfaces and how to restrict and protect the access to them.

However, if we need to restrict a administrative traffic access to the Firewall or allow only IPsec VPN peers from a pre-defined geolocation group and deny a BGP neighbors to negotiate from specific address list?

So, while security profiles control traffic flowing through the FortiGate, local-in policies control inbound traffic that is going to a FortiGate interface.

The administrative access traffic to protocols HTTPS, PING, SSH, and others, can be controlled by allowing or denying the service in the interface settings. In addition to protect the administrative access to the FortiGate the local-in policies allow administrators to granular define the source and destination addresses, interface, and services like create access policy to traffic VPN or BGP. It is possible using geographic set of IP addresses, IP addresses from Threat Feeds or even ISDB to blocking attempts from some malicious scanner.

An important point here is, the creation or editing of local-in-policy is only by CLI. You can view the existing local-in policies in the GUI by enabling it in System > Feature Visibility under the Additional Features section. The custom local-in policies not be viewed.

Said that, let's see some examples:

01 Block ICMP from Bogons

#config firewall local-in-policy
edit 1
set intf "any"
set srcaddr "Bogon_Range_Group"
set dstaddr "all"
set service "PING"
set schedule "always"
set action deny
next
end

On first example, we can block ICMP access from Bogons networks. We can block more than ICMP if administrators want, service group is allowed. Lets see the debug flow output:

02 Block Malicious ISDB

config firewall local-in-policy
edit 2
set intf "any"
set dstaddr "all"
set internet-service-src enable
set internet-service-src-group "ThreatSEC-ISDB-IN"
set service "ALL"
set schedule "always"
set action deny
next
end

On second example we can create a ISDB group with malicious sources that were classified as scanners and block them. (You can read our article about ISDB usage clicking here)

An important detail is, by default, no local-in policies are defined, so there are no restrictions on local-in traffic. When you define a local-in policy, if no action is set manually, then the action will default to deny. The implicit deny policy should be placed at the bottom of the list of local-in-policies. Local-in-policies are created for each interface, but if you want to create a general implicit deny rule for all interfaces for a specific service, source, address, or destination address, use any interface.

An additional option here is the use of virtual patching for mitigating vulnerability exploits against OT devices by applying patches virtually on the FortiGate if you have license subscription.