pjhtech Tools
FortiGate

FortiGate Local-In Policy: Management Access and Rule Order

Troubleshoot FortiGate management access using interface services, trusted hosts and local-in rule order, with a scoped CLI example.

If SSH or HTTPS to the FortiGate is blocked, enable that service on the receiving interface, include the intended administrator source in trusted hosts, and correct any matching local-in deny. A normal forwarding-policy allow does not grant access to the FortiGate itself.

Scope: FortiGate IPv4 local services, including management and VPN termination.

Fix the disabled service or excluded administrator source

For the affected interface, open Network → Interfaces → Edit → Administrative Access and check the required HTTPS, SSH or PING service. For the login account, open System → Administrators → Edit → Restrict login to trusted hosts and compare the allowed prefixes with the client source address seen by the FortiGate.

With VDOMs disabled, run show system interface port2 and show full-configuration firewall local-in-policy at the normal CLI prompt. With multiple VDOMs enabled, a global administrator reads the interface in global context first. Start at the top-level prompt and replace port2 with the affected interface:

Read-only • global administrator on a multi-VDOM FortiGate
config global
    show system interface port2
end

Read set vdom in that output, then enter that existing receiving VDOM to inspect its local-in rules:

Read-only • replace the placeholder with the interface’s VDOM
config vdom
    edit "<receiving-vdom>"
        show full-configuration firewall local-in-policy
    next
end

For the address and local-in changes below, enter the receiving VDOM with config vdom and edit "<receiving-vdom>". A VDOM-restricted administrator is already there. Leave that context with next and end after the changes.

In the interface output, allowaccess lists enabled services. In the local-in output, work from the first enabled rule down: compare intf, srcaddr, dstaddr, service, schedule and action. Enable a missing administrative service only on the intended management interface; add the observed management subnet to trusted hosts only if it should have access.

A local-in allow is below a matching deny

Local-in uses ordered matching. For an allowlist, put the specific allow before a deny for the same interface and service. A lone allow rule does not imply that all other sources are denied.

Example: deny PING from 192.0.2.10/32 to the FortiGate’s port2 address. Create the address below if that name is unused; otherwise verify its subnet before reusing it. Rule ID 900 must also be unused. Run this in the receiving VDOM.

Configuration change • example objects; ID 900 must be unused
config firewall address
    edit "example-test-host"
        set subnet 192.0.2.10 255.255.255.255
    next
end
config firewall local-in-policy
    edit 900
        set intf "port2"
        set srcaddr "example-test-host"
        set dstaddr "all"
        set service "PING"
        set schedule "always"
        set action deny
        set status enable
    next
end

If an earlier rule permits this same PING flow, move the example before that rule using config firewall local-in-policy, move 900 before <matching-rule-id>, then end. Read the list again to confirm the order before testing. Local-in ordering example. Keep an independent management session when restricting HTTPS/SSH, and test a fresh login: an established session can hide a broken new-session policy.

GUI location and undo

Where available, use Policy & Objects → Local-In Policy. GUI creation and editing were added in FortiOS 7.6.0; older builds require the CLI for those operations.

To undo the example, disable only the rule you created:

Undo • confirm rule 900 is the example rule
config firewall local-in-policy
    edit 900
        set status disable
    next
end

Retest the selected service from an allowed and denied source. If you changed order, restore that order as well.

References