Local-in policies

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

Administrative access traffic (HTTPS, PING, SSH, and others) can be controlled by allowing or denying the service in the interface settings. Trusted hosts can be configured under an administrator to restrict the hosts that can access the administrative service.

Local-in policies allow administrators to granularly define the source and destination addresses, interface, and services. Traffic destined for the FortiGate interface specified in the policy that meets the other criteria is subject to the policies action.

Local-in policies can be used to restrict administrative access or other services, such as VPN, that can be specified as services. You can define source addresses or address groups to restrict access from. For example, by using a geographic type address you can restrict a certain geographic set of IP addresses from accessing the FortiGate.

Local-in policies can only be created or edited in the CLI. You can view the existing local-in policies in the GUI by enabling it in System > Feature Visibility under the Additional Features section. This page does not list the custom local-in policies.

To configure a local-in policy using the CLI:

config firewall {local-in-policy | local-in-policy6}
    edit <policy_number>
        set intf <interface>
        set srcaddr <source_address> [source_address] ...
        set dstaddr <destination_address> [destination_address] ...
        set action {accept | deny}
        set service <service_name> [service_name] ...
        set schedule <schedule_name>
        set comments <string>
    next
end

For example, to prevent the source subnet 10.10.10.0/24 from pinging port1, but allow administrative access for PING on port1:

config firewall address
    edit "10.10.10.0"
        set subnet 10.10.10.0 255.255.255.0
    next
end
config firewall local-in-policy
    edit 1
        set intf "port1"
        set srcaddr "10.10.10.0"
        set dstaddr "all"
        set service "PING"
        set schedule "always"
    next
end

To test the configuration:

1. From the PC at 10.10.10.12, start a continuous ping to port1:

   ping 192.168.2.5 –t

2. On the FortiGate, enable debug flow:

   # diagnose debug flow filter addr 10.10.10.12
   # diagnose debug flow filter proto 1
   # diagnose debug enable
   # diagnose debug flow trace start 10
   

3. The output of the debug flow shows that traffic is dropped by local-in policy 1:

   # id=20085 trace_id=1 func=print_pkt_detail line=5746 msg="vd-root:0 received a packet(proto=1, 10.10.10.12:1->192.168.2.5:2048) from port1. type=8, code=0, id=1, seq=128."
   id=20085 trace_id=1 func=init_ip_session_common line=5918 msg="allocate a new session-0017c5ad"
   id=20085 trace_id=1 func=vf_ip_route_input_common line=2615 msg="find a route: flag=80000000 gw-192.168.2.5 via root"
   id=20085 trace_id=1 func=fw_local_in_handler line=474 msg="iprope_in_check() check failed on policy 1, drop"

Implicit deny rule

If a local-in-policy is not functioning correctly and traffic that should be blocked is being allowed through, the issue may be that the implicit deny local-in-policy has not been created. Unlike IPv4 policies, there is no default implicit deny policy. 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 the any interface.

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.

For example, to allow only the source subnet 172.16.200.0/24 to ping port1:

config firewall address
    edit "172.16.200.0"
        set subnet 172.16.200.0 255.255.255.0
    next
end
config firewall local-in-policy
    edit 2
        set intf "port1"
        set srcaddr "172.16.200.0"
        set dstaddr "all"
        set action accept
        set service "PING"
        set schedule "always"
    next
    edit 3
        set intf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set service "PING"
        set schedule "always"
    next
end

To test the configuration:

1. From the PC at 172.16.200.2, start a continuous ping to port1:

   ping 172.16.200.1 –t

2. On the FortiGate, enable debug flow:

   # diagnose debug flow filter proto 1
   # diagnose debug enable
   # diagnose debug flow trace start 10
   

3. The output of the debug flow shows that ping traffic coming from the 172.16.200.0 subnet is allowed:

   # id=65308 trace_id=25 func=print_pkt_detail line=5939 msg="vd-root:0 received a packet(proto=1, 172.16.200.2:5->172.16.200.1:2048) tun_id=0.0.0.0 from port1. type=8, code=0, id=5, seq=0."
   id=65308 trace_id=25 func=init_ip_session_common line=6121 msg="allocate a new session-00029409, tun_id=0.0.0.0"
   id=65308 trace_id=25 func=__vf_ip_route_input_rcu line=2012 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
   id=65308 trace_id=25 func=ip_session_confirm_final line=3189 msg="npu_state=0x0, hook=1"
   id=65308 trace_id=26 func=print_pkt_detail line=5939 msg="vd-root:0 received a packet(proto=1, 172.16.200.1:5->172.16.200.2:0) tun_id=0.0.0.0 from local. type=0, code=0, id=5, seq=0."
   id=65308 trace_id=26 func=resolve_ip_tuple_fast line=6027 msg="Find an existing session, id-00029409, reply direction"
   id=65308 trace_id=27 func=print_pkt_detail line=5939 msg="vd-root:0 received a packet(proto=1, 172.16.200.2:5->172.16.200.1:2048) tun_id=0.0.0.0 from port1. type=8, code=0, id=5, seq=1."
   id=65308 trace_id=27 func=resolve_ip_tuple_fast line=6027 msg="Find an existing session, id-00029409, original direction"
   id=65308 trace_id=28 func=print_pkt_detail line=5939 msg="vd-root:0 received a packet(proto=1, 172.16.200.1:5->172.16.200.2:0) tun_id=0.0.0.0 from local. type=0, code=0, id=5, seq=1."
   

4. From the PC at 172.20.120.13, start a continuous ping to port1:

   ping 172.16.200.1 -t

5. The output of the debug flow shows that ping traffic coming from subnets other than 172.16.200.0 is dropped by local-in policy 3:

   # id=65308 trace_id=21 func=print_pkt_detail line=5939 msg="vd-root:0 received a packet(proto=1, 172.20.120.13:1->172.16.200.1:2048) tun_id=0.0.0.0 from port2. type=8, code=0, id=1, seq=8."
   id=65308 trace_id=21 func=init_ip_session_common line=6121 msg="allocate a new session-0002929d, tun_id=0.0.0.0"
   id=65308 trace_id=21 func=__vf_ip_route_input_rcu line=2012 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
   id=65308 trace_id=21 func=__iprope_tree_check line=520 msg="gnum-100004, use int hash, slot=51, len=2"
   id=65308 trace_id=21 func=fw_local_in_handler line=545 msg="iprope_in_check() check failed on policy 3, drop"
   

Additional options

To disable or re-enable the local-in policy, use the set status {enable | disable} command.

To dedicate the interface as an HA management interface, use the set ha-mgmt-intf-only enable command.

Example:

config firewall local-in-policy
    edit 1
        set ha-mgmt-intf-only enable
        set intf port4
        set srcaddr all
        set dstaddr all
        set service ALL
        set schedule always
        set action accept
        set status enable
    next
end

If a user tries to set the HA reserved management interface during the local-in policy an error is generated. Use the set ha-mgmt-intf-only enable command to avoid the error.