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

[nprakash]

Description	This article explains how the local-in policy and trusted hosts configuration on FortiGate affects service connections to the FortiGate unit and administrative access to that device.
Scope	FortiGate.
Solution	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 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: 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). Trusted hosts setting and mechanism is secondary filter, further limiting access to administrative interfaces and co-working with local-in policies. 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. 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. 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.