| Description | This article describes limitations of trusted hosts and alternatives to using a local-in policy for granular control. |
| Scope | All supported versions of FortiGate (7.4.3 is the latest at the time of writing). |
| Solution |
Note: trusted host configuration under the management interface level is limited to a maximum of three sets. Configure a local-in policy instead of trusted hosts to bypass this.
Enable management access for the interface level. See this article for instructions.
The following screenshot example shows the trusted host can only configure up to 3 IPv4 and IPv6 subnets. See the CLI reference.
Alternatively, trust hosts can be added under the admin profile. See this article.
Up to 10 hosts can be configured for the admin profile. See this document for more information.
To improve the scope of administrative access, configure a local-in policy to control administrative access.
To enable local-in policy, then navigate to System -> Feature Visibility -> Local-in Policy.
The local-in policy option will appear under Policy & Object -> Local-in Policy.
There are two types of local-in policy:
1. System-generated local-in policy.
For example, if Port 10 has enabled HTTPS/HTTP/PING/SSH/TELNET for administrative access:
A local-in policy will be created by FortiOS automatically to allow administrator access via the method shown above. See the screenshot below in the local-in policy area.
Those policies cannot be modified - this is expected behavior. However, disabling HTTPS/HTTP access for port10 will cause the system to move the related local-in policy away. See the following example:
2. Custom Local-in policy.
A custom local-in policy to control administrative access only can be created through the command line. This local-in policy works similarly to a normal firewall policy. See this document for the CLI syntax:
Be mindful of the following during migration from a current trusted-IP setup to a local-in policy:
Trusted IP needs to be removed completely from the interface level, as a Local-in policy will otherwise not function. Trusted IP on the interface level will take precedence over any Local-in policy. Arrange console access to FortiGate while doing this to avoid unexpected admin control loss.
In the following example, the current port 3 has trusted IP configured and a local-in policy allowed Windows access. However, it does not work for the reasons explained above:
Local-in policy and address.
The reason is the Windows machine 10.78.1.50 is not listed under the trusted IP (1.1.1.1 and 2.2.2.2) setting on the interface level.
Trusted IP will take priority over any local-in policy, meaning that even though a local-in policy has allowed the administrative access, the connection will still be denied and time out.
Configuration example:
Purpose: Configure port 10 to allow only specific host to have administrative access. Applicable Machines: Windows, host IP 10.78.1.50 / FortiGate port 10 IP: 10.78.1.44.
config firewall local-in-policy edit 2 set intf "port3" set srcaddr "windows" set dstaddr "all" set action accept set service "SSH" "HTTPS" "HTTP" "TELNET" set schedule "always" next edit 1 <- The deny action will not appear when using 'show policy' but will appear when executing 'show full'. set intf "port3" set srcaddr "all" set dstaddr "all" set service "ALL" set schedule "always" next end
Policy edit 2 allows access and edit 1 denies other access from different IPs or hosts. Since the policy is only available in CLI configuration, move policy sequences as needed with the following command:
config firewall local-in-policy move policyid User defined local in policy ID. 2 1
move 2 after move after before move before
move 2 before 1 end
An action can be moved before or after depending on requirements. The policy lookup process for a Local-in policy will be the same as general Firewall policy look up. It is recommended to insert a deny all policy at the bottom to act as an 'implicit deny' to deny IPs that are not listed as trusted.
HTTPS access will now function as expected:
 |
