FortiGate Local-In Policy: CLI and GUI by Version

Use local-in policy for traffic addressed to the FortiGate, such as management or VPN termination. A normal forwarding policy controls traffic passing through it. FortiOS 7.4.4 requires CLI creation and editing; FortiOS 7.6.0 added those operations to the GUI.

Applies to: FortiGate IPv4 local-in policy, FortiOS 7.4.4 and 7.6.0 documentation. A single management interface and a deliberately limited service; HA reserved management interfaces and IPv6 need separate review.

Validation: documentation-checked on 12 September 2026. No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.

Check which control owns the symptom

Record the incoming interface, destination address and service port. If the request targets a server behind a VIP, this is normally a forwarding/NAT investigation. If it targets the FortiGate interface, inspect interface administrative access, administrator trusted hosts and the ordered local-in rules. An accept rule does not start a disabled management service or override every other control.

Documentation checked	Configuration path
FortiOS 7.4.4	Create/edit local-in rules in the CLI. Feature Visibility can expose a GUI view; do not assume it shows custom policies.
FortiOS 7.6.0	Policy & Objects → Local-In Policy; separate IPv4 and IPv6 tabs allow creation and editing.

Sources: 7.4.4 local-in policy and 7.6.0 GUI support. Do not infer a later release’s menu or service behavior solely from the major version.

Preserve a separate management path

Use local console or an independent permitted management path. Save the matching rules, address objects and their order. Before denying any management service, establish a fresh second session from the intended administrator network.

Start with one non-administrative diagnostic service if you need to validate rule matching. In the synthetic example below, an existing address object example-test-host represents 192.0.2.10/32; port2 is the intended lab management interface. Policy ID 900 must be unused. This denies only that host’s PING on that interface; it is not a complete management lockdown.

Configuration change • FortiOS 7.4.4 • synthetic object, interface and unused ID

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

Inspect earlier matching rules before expecting this rule to win. The actual order matters, not the numeric size of the ID. For an allowlist, place the narrow allow before a deny scoped to the same interface and service. A lone allow rule does not create an implicit deny for everyone else. Avoid a service ALL deny until every required local service has been reviewed.

Verify new sessions and restore precisely

Test from the denied host and a permitted control host. Confirm the selected service behaves as intended, then open a new management session from the recovery network. For a later HTTPS/SSH restriction, test a fresh login; an already established session can conceal a broken rule. Test IPv6 separately if it is enabled: an IPv4 local-in rule is not an IPv6 boundary.

Rollback for the example: using the independent session, disable only rule 900 after confirming it is the rule just created. Retest PING and management. Delete the temporary rule and unused synthetic address object only after checking references. Restore the exact original order if you moved existing rules. No tunnel reset is required.

Rollback • disable only the confirmed temporary rule

config firewall local-in-policy
    edit 900
        set status disable
    next
end

Prepare reviewed address objects · Check VPN negotiation separately

Technical references

Found an issue? Send a correction with a reproducible example.