Technical Tip: Impact of Local-In Policies and Trusted Hosts Configuration on FortiGate Access

The trusted hosts configuration for system administrators defines a set of IP addresses or subnets permitted to access the device’s administrative interfaces, such as the web GUI or CLI. This feature helps enhance security by restricting administrative access to trusted sources only.

Below is an example of the trusted host configured on a FortiGate:
(more hosts or subnets can be added)

config system admin
     edit "admin"
        set trusthost1 10.128.202.253 255.255.255.255
        set accprofile "super_admin"
        set vdom "root"
     next
end

With this setting, only traffic from the source 10.128.202.253 will be allowed for administrative access to FortiGate.

A local-in policy in FortiGate controls all the traffic destined for the device itself in general, including access to administrative interfaces. It defines rules that regulate which traffic can reach FortiGate unit and critical services offered by the unit. This protects the device from unauthorized access and attacks.
Local-in policies apply to traffic that directly targets the FortiGate device, ensuring only trusted sources are allowed to connect.

The following is an example of the local-in-policy configured on FortiGate to accept the traffic coming from port1 and the network 10.128.202.0/24 to access FortiGate's port1 IP(10.21.4.84) using HTTP service (TCP port 80 by default) and HTTPS service (TCP port 443 by default). Check 'config firewall service custom HTTP' and HTTPS to make sure those service definitions fit what's expected).

config firewall local-in-policy
     edit 1
        set intf "port1"
        set srcaddr "Allowed Network"
        set dstaddr "wan_ip_fgt"
        set action accept
        set service "HTTP" "HTTPS"
        set schedule "always"
     next

     edit 2
        set intf "port1"
        set srcaddr "all"
        set dstaddr "wan_ip_fgt"
        set service "HTTP" "HTTPS"

        set schedule "always"
     next

end

An alternative way to configure a local-in policy to block access from all IPs except a specific allowed network using a single policy.

config firewall local-in-policy

    edit 1

        set intf "port1"

        set srcaddr "Allowed Network"

        set srcaddr-negate enable <----- This command will negate the rule. It will only allow IPs specified in 'Allowed Network' and then deny all other IP addresses.

        set dstaddr "wan_ip_fgt"

        set action deny

        set service "HTTP" "HTTPS"

        set schedule "always"

        set status enable

    next

end

config firewall address
    edit "Allowed Network"
        set subnet 10.128.202.0 255.255.255.0
    next

    edit "wan_ip_fgt"
        set subnet 10.21.4.84 255.255.255.255
    next
end

Even if the local-in policy is configured to accept the traffic, the FortiGate will perform additional check to determine whether administrative access should be allowed for a source IP address based on the 'trusted hosts' configuration.

In this example, traffic from source 10.128.202.254 to 10.21.4.84:443 is allowed by local-in policy number 1, but is blocked by FortiGate because the 'trusted hosts' configuration allows only a single IP 10.128.202.253 to access the FortiGate using HTTP/HTTPS.
As shown below, the FortiGate does not respond to SYN, with SYN-ACK for this traffic flow, as expected.

diagnose sniffer packet any " host 10.21.4.84 and port 443 " 4 0 l
Using Original Sniffing Mode
interfaces=[any]
filters=[ host 10.21.4.84 and port 443 ]
2025-01-12 09:43:52.266036 port1 in 10.128.202.254.64650 -> 10.21.4.84.443: syn 3307511406
2025-01-12 09:43:56.277973 port1 in 10.128.202.254.64650 -> 10.21.4.84.443: syn 3307511406
2025-01-12 09:43:56.745078 port1 in 10.128.202.254.64651 -> 10.21.4.84.443: syn 146995253

In summary:

1. Local-in policies steps in first and govern all traffic coming directly towards and to the FortiGate unit as destination (not for traffic intended to pass through, destination behind the FortiGate, as that is handled by firewall policies).
2. Trusted hosts setting and mechanism is secondary filter, further limiting access to administrative interfaces and co-working with local-in policies.
3. When a local-in policy is configured to accept traffic and the incoming traffic matches this policy, then FortiGate performs an additional check against the trusted hosts configuration to determine whether to allow or deny the connection.
4. If no local-in policies are configured, FortiGate will rely only on the trusted hosts configuration to decide whether to allow or deny the connection.
5. However, if the traffic matches a DENY local-in policy, the connection will be dropped. And the FortiGate will not do  anything further, like check the trusted hosts configuration for that connection.

Note:
When configuring trusted hosts to restrict administrative access to the FortiGate GUI/CLI, ensure that all system administrator accounts on the FortiGate are configured with trusted hosts settings to prevent the device from responding to connections from non-trusted sources.

Consider use of both mechanisms, trusted hosts and local-in policies in conjunction to further harden the administrative access. Use out-of-band management networks and VPN solutions to further increase admin access security.

Starting from Fortios v7.6.0, Local-in policies can be created in the GUI. See Technical Tip: Creating a Local-In policy (IPv4 and IPv6) on GUI.