Description
This article explains the difference between Local-in-policy and Trusted hosts.
Scope
Any supported version of FortiGate.
Solution
Local-in-policy:
Local-in-policies to restrict administrative access(HTTPS, PING, SSH, and others) in the interface level. It is necessary to define the source IP, destination IP, interface to which it should be applicable, and the service in the policy. Network traffic that satisfies the condition mentioned is either allowed or denied depending on the configuration.
It is possible to define a local-in-policy to restrict access based on geographical location as well.
Note: By default, no local-in-policy is defined.
Configuration in the CLI:
Local-in-policy is not configurable from the GUI. Once configured from CLI, verify it in the GUI by enabling it under System -> Feature Visibility under the Additional Features section.
Trusted hosts:
Unlike a local-in-policy that allows administrative access based on the interface, IP and service configured in the policy; trusted hosts are configured to permit access based on the admin user and the IP allocated to the admin user as a trusted host.
A single IP or subnet is added under the trusted host config of the admin user configuration. If an incoming connection attempt comes from a source-IP that does not match anything in this pool, the connection is dropped. Up to 10 trusted host IP addresses can be added.
When the source-IP of a connection attempt matches the trusted host of any admin, TCP/TLS is allowed and the FortiGate Login screen appears. Once the credentials are entered, the source IP is checked against the trusted hosts configured for that user and access is allowed if applicable. If the user or the trusted host mismatches, access is denied.
Trusted host GUI configuration:
When both Trusted hosts and Local in policy are used, local in policy will not work as expected.
In the following scenario, the local-in policy is configured for geoblocking from any other country but Canada:
When trying to reach from one of the public IP addresses (24.114.x.x) within Canada, the GUI page does not load. The GUI in the example is on the default HTTPS port 443.
The following is the local-in policy set for GUI access:
config firewall local-in-policy
edit 1
set uuid 4573e5d6-90b3-51ef-86b3-b3d193059987
set intf "wan1"
set srcaddr "Canada"
set dstaddr "all"
set action accept
set service "HTTPS"
set schedule "always"
set status enable
next
edit 2
set uuid 523696f6-90b3-51ef-fdcc-9cf7fcc42029
set intf "wan1"
set srcaddr "all"
set dstaddr "all"
set action deny
set service "ALL"
set schedule "always"
set status enable
next
end
The debug log output for this traffic will resemble the following excerpt:
id=20085 trace_id=130 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=6, 24.114.x.x:40483->10.0.0.180:443) tun_id=0.0.0.0 from wan1. flag [S], seq 3461910851, ack 0, win 65535"
id=20085 trace_id=130 func=init_ip_session_common line=6046 msg="allocate a new session-02bc17e2, tun_id=0.0.0.0"
id=20085 trace_id=130 func=vf_ip_route_input_common line=2611 msg="find a route: flag=80000000 gw-10.0.0.180 via root"
id=20085 trace_id=130 func=fw_local_in_handler line=500 msg="iprope_in_check() check failed on policy 0, drop" <<<---Dropping the traffic by default policy
It is evident that the traffic is not matching the local policy created to allow this traffic, as it is being dropped by default policy.
Check on the FortiGate whether there are any constraints that might be preventing the local-in policy from working.
The first step is to check if there are any trusted hosts on the Administrators under System -> Administrators.
As in the above screenshot, the trusted hosts are configured; the trusted hosts are taking precedence, and that is why they are not hitting the policy.
Once the public IP address of the device trying to reach FortiGate is added from a trusted host, the page loads.
The local-in policy for the administrative access will only work if there are no trusted hosts. As trusted hosts have the higher preference, it will match trusted hosts and not the local in policy.
The following excerpt shows an example where there is no trusted host local in policy:
# id=65308 trace_id=10000 func=print_pkt_detail line=5920 msg="vd-root:0 received a packet(proto=6, 24.114.x.x :31986->10.9.10.159:443) tun_id=0.0.0.0 from port1. flag [S], seq 3374202118, ack 0, win 64240"
id=65308 trace_id=10000 func=init_ip_session_common line=6110 msg="allocate a new session-0013d8b7"
id=65308 trace_id=10000 func=__vf_ip_route_input_rcu line=1988 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=10000 func=ip_session_confirm_final line=3128 msg="npu_state=0x0, hook=1"
id=65308 trace_id=10001 func=print_pkt_detail line=5920 msg="vd-root:0 received a packet(proto=6, 10.9.10.159:443->24.114.x.x:31986) tun_id=0.0.0.0 from local. flag [S.], seq 490849151, ack 3374202119, win 29200"
id=65308 trace_id=10001 func=resolve_ip_tuple_fast line=6013 msg="Find an existing session, id-0013d8b7, reply direction"
Another example where the IP is dropped as it matches the second local-in policy:
# id=65308 trace_id=17310 func=print_pkt_detail line=5920 msg="vd-root:0 received a packet(proto=6, 124.16.x.x :33215->10.9.10.159:443) tun_id=0.0.0
.0 from port1. flag [S], seq 4200756073, ack 0, win 64240"
id=65308 trace_id=17310 func=init_ip_session_common line=6110 msg="allocate a new session-0013db51"
id=65308 trace_id=17310 func=__vf_ip_route_input_rcu line=1988 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=17310 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 2, drop"
