Local-in Policy in FortiGate: Secure design and management of local services

Local-in Policy in FortiGate: Secure design and management of local services

In FortiOS 7.6, Local-in Policy is used to control traffic that reaches FortiGate interfaces, such as HTTPS, SSH, PING, SNMP, IKE, SSL VPN and other services that respond on FortiGate. Therefore, if FortiGate sits at the network edge or if Administrative Access is enabled on interfaces, a proper Local-in Policy design is a core part of hardening.

1. What is Local-in Traffic?

Local-in Traffic refers to traffic whose destination is the FortiGate itself, not the network behind it. For example, traffic reaching FortiGate from external sources via HTTPS to an interface IP, a Ping to a firewall interface, SNMP polling from FortiGate, or an IKE negotiation for IPsec VPN—all are Local-in Traffic.

Note Security Profiles like IPS, Antivirus, and Web Filter apply to traffic that traverses through FortiGate. Local-in Policy applies to traffic that arrives at FortiGate interfaces and does not pass through the firewall.

2. Difference between Local-in Policy and a normal Firewall Policy

A normal Firewall Policy controls Transit traffic, i.e., traffic entering from one interface and leaving through another. Local-in Policy controls traffic whose destination is a FortiGate interface. This difference means a normal Firewall Policy may not be sufficient to block access to the GUI or SSH of FortiGate.

3. Which services are controlled by Local-in Policy?

Any service that responds on FortiGate can be included in Local-in Policy. Depending on the scenario, these services may be management, monitoring or VPN related.

4. Local-in Policy, Interface Administrative Access and Trusted Host differences

Protecting FortiGate access involves three layers: Interface Administrative Access, Administrator Trusted Host, and Local-in Policy. These layers complement each other rather than replace one another.

Note: If HTTPS or SSH is enabled on an external FortiGate interface, do not rely solely on a standard Firewall Policy. Traffic to the FortiGate IP should be controlled by Interface Administrative Access, Trusted Host and Local-in Policy.

5. Key FortiOS 7.6 enhancements for Local-in Policy

Fortinet highlights several features in FortiOS 7.6 that support secure design and precise debugging of Local-in Policy.

5.1 GUI support for Local-in Policy creation

FortiOS 7.6 allows creating and editing Local-in Policy via the GUI. The GUI supports separate Local-In Policy entries for IPv4 and IPv6.

Policy & Objects > Local-In Policy

5.2 Default Local-in Policy targeting malicious sources

FortiOS 7.6.1 adds a Default Local-in Policy that uses the Internet Service Database for sources such as Malicious-Malicious.Server, Tor-Exit.Node and Tor-Relay.Node. The rule blocks known malicious sources from FortiGate interfaces across all services and ports.

Note: This rule is added by default for Factory Default or a new VDOM. If FortiOS builds ISDB-based Local-in policies, this rule can be added manually.

5.3 Per-policy logging

Logging for Local-in Traffic can be configured more granularly per policy, aiding debugging and documentation of attempts to access the Management Plane.

5.4 Virtual Patching on Local-in Management Interface

Local-in Policy supports Virtual Patching to mitigate vulnerabilities targeting the FortiGate itself. It examines Vulnerability rules against Local-in traffic for the specified interface and drops matches.

5.5 Using Internet Service as Source

Using Internet Service as a Source in Local-in Policy is useful for blocking known malicious or Tor-related resources via ISDB.

6. Secure design approach for Local-in Policy

Design Local-in Policy with Management Plane Protection in mind. The goal is not a single rule, but precisely defining who, from which interface, can access which FortiGate service.

Principle 1: Allow restricted access first, then deny broadly

For services like HTTPS, SSH, SNMP and PING, start by allowing only trusted sources and then add a general Deny rule for all others. Relying only on an Allow rule without a final Deny may leave access inadvertently open depending on admin access and existing rules.

Principle 2: Think per interface

Internal interface risks are not the same as Internet-facing interfaces. On WAN, avoid open management access; if you must open it, limit the Source strictly. On internal management interfaces, restrict to admin subnets, jump servers or authorized monitoring systems.

Principle 3: Separate services

Create separate rules for HTTPS, SSH, PING, SNMP and VPN to keep logs clear and troubleshooting straightforward and to avoid enabling or disabling a wrong service during changes.

Principle 4: Local-in Policy is not a substitute for hardening

Combine Local-in Policy with other hardening steps such as disabling unnecessary services on interfaces, changing management port numbers when needed, using Trusted Host, enabling MFA for admins, restricting Administrator profiles, and keeping FortiOS up to date.

7. Practical scenarios

Scenario 1: Restrict GUI and SSH access to the admin network only

FortiGate on a management or internal interface answers to HTTPS and SSH, but only the admin subnet is allowed to connect. Other sources are Denied.

• Allowed Source: Admin Subnet or Jump Server
• Allowed Services: HTTPS and SSH
• Source action: Accept
• Other Source action: Deny
• Logging: enable for Deny

Scenario 2: Block Ping to the Internet-facing Interface

Blocking Ping to WAN helps reduce detection by scanners. Deny Ping from all sources or allow only from authorized monitoring sources.

Scenario 3: Limit SNMP to the monitoring server only

SNMP is typically used for monitoring FortiGate, but exposing SNMP to all sources can leak management data. Allow SNMP only from monitoring server IP.

Scenario 4: Limit IKE/IPsec to specific peers

If FortiGate acts as a VPN gateway, restrict negotiation traffic to trusted peer IPs to reduce unsolicited attempts.

Scenario 5: Use ISDB to block malicious sources

ISDB sources such as Tor or known malicious servers can be blocked by Local-in Policy before reaching FortiGate services.

8. GUI steps in FortiOS 7.6

To create Local-in Policy in FortiOS 7.6, use the path below.

Policy & Objects > Local-In Policy

General steps:

1. Create the Address Object for the allowed Source.
2. Open Local-In Policy section.
3. For IPv4 use the Local-In Policy tab and for IPv6 use the IPv6 Local-In Policy tab.
4. Select the desired Interface.
5. Specify Source, Destination, Schedule and Service.
6. Set Action to Accept or Deny.
7. Enable Logging for sensitive Rules.

Important: Before applying Deny rules on administrative access, ensure you have an alternate management path or console access. An error in Local-in Policy can cut admin access to FortiGate.

9. Practical CLI examples

9.1 Create Address Object for Admin Network

Assume the admin network is 10.10.10.0/24.

config firewall address edit "ADMINS_10.10.10.0_24" set subnet 10.10.10.0/24 next end

9.2 Allow HTTPS and SSH only from admin network

This rule allows only the admin network to connect to FortiGate on HTTPS and SSH on the specified interface.

config firewall local-in-policy edit 10 set intf "port1" set srcaddr "ADMINS_10.10.10.0_24" set dstaddr "all" set action accept set service "HTTPS" "SSH" set schedule "always" set logtraffic enable set comments "Allow admin access from trusted admin subnet" next end

9.3 Deny HTTPS and SSH for other sources

After the allowed rule, add a general Deny rule for other sources.

config firewall local-in-policy edit 20 set intf "port1" set srcaddr "all" set dstaddr "all" set action deny set service "HTTPS" "SSH" set schedule "always" set logtraffic enable set comments "Deny admin access from untrusted sources" next end

9.4 Allow Ping only from monitoring server

Only the monitoring server IP is allowed to Ping; other sources are Denied for Ping.

config firewall address edit "MONITORING_10.20.20.10" set subnet 10.20.20.10/32 next end

config firewall local-in-policy edit 30 set intf "port1" set srcaddr "MONITORING_10.20.20.10" set dstaddr "all" set action accept set service "PING" set schedule "always" set logtraffic enable set comments "Allow ping from monitoring server" next end

config firewall local-in-policy edit 31 set intf "port1" set srcaddr "all" set dstaddr "all" set action deny set service "PING" set schedule "always" set logtraffic enable set comments "Deny ping from other sources" next end

9.5 Add Default Local-in Policy for malicious ISDB sources

If ISDB is supported as a Source, you can add a rule similar to the following.

config firewall local-in-policy edit 1 set intf "any" set dstaddr "all" set internet-service-src enable set internet-service-src-name "Malicious-Malicious.Server" "Tor-Exit.Node" "Tor-Relay.Node" set service "ALL" set schedule "always" set action deny set logtraffic enable set comments "Block known malicious sources to FortiGate local services" next end

9.6 Enable logging per policy

To enable logging per policy, activate local-in-policy-log via global settings or per policy.

config log setting set local-in-policy-log enable end

config firewall local-in-policy edit 20 set logtraffic enable next end

9.7 Check policies via CLI

show firewall local-in-policy

show firewall local-in-policy6

10. Logging and troubleshooting Local-in Policy

One common pitfall is writing a Local-in Policy without sufficient logging. FortiOS 7.6 allows Local Traffic Logging to be Global or Per Policy. Per Policy generally provides a clearer view for security scenarios.

Log & Report > Log Settings > Global Settings > Local traffic logging > Per policy

CLI usage:

config log setting set local-in-policy-log enable end

Debug Flow

If traffic that should be blocked is passing, or allowed traffic is dropped, use Debug Flow. In Fortinet outputs, drop by Local-in Policy is usually shown with a message like the following:

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

Possible snippet:

fw_local_in_handler line=545 msg="iprope_in_check() check failed on policy 3, drop"

11. Best Practice for Local-in Policy

• On Internet-facing interfaces, disable or tightly restrict Administrative Access (HTTPS, SSH).
• If admin access from outside is unavoidable, restrict by Source using Local-in Policy and Trusted Host.
• Write separate rules for HTTPS, SSH, SNMP, PING and VPN.
• Place restricted Allow rules above, and general Deny rules below.
• Enable Deny logging for sensitive services.
• Limit SNMP to trusted monitoring server IPs only.
• Limit IPsec VPN to known peers where possible.
• Evaluate ISDB usage for blocking malicious sources.
• Always ensure a backup management path or console after changes.
• After FortiOS upgrades, re-check Local-in Policy, logging and interface access.

12. Local-in Policy implementation checklist

برای ارزیابی پایداری و امنیت زیرساخت، به راهنمای پشتیبانی شبکه مراجعه کنید.