FotiGate Enable Policy Mode

原文：FotiGate Enable Policy Mode — theDXT (Daniel Keer)

The default setup of a Fortinet FortiGate is Profile mode. Here’s step-by-step how to change a FortiGate from Profile Mode to Policy Mode. Due to the significant change between the two mode you will need to rebuild all your rules.

What Profile mode and Policy mode actually mean

FortiOS ships with two different NGFW (Next Generation Firewall) operating modes, and choosing between them is one of the first architectural decisions you make on a new FortiGate. In Profile-based mode (the factory default on every new device), security inspection is applied to traffic by attaching security profiles — antivirus, IPS, web filter, application control, DNS filter, SSL inspection — to a firewall policy. The policy itself is defined by the classic five-tuple: incoming interface, outgoing interface, source, destination and service (port). One policy can carry several profiles at once, and you reuse the same profile objects across many policies.

In Policy-based mode (also called NGFW policy mode), the policy is the security decision. Instead of matching ports and attaching profiles, you create policies that match on application, URL category, user/group and other NGFW objects directly. Each policy is essentially a single security event: “allow this application for this group, block everything else.” Port numbers are no longer the matching criterion — the application signature is. This model suits organisations that want an explicit allow-list of applications and destinations, and it maps cleanly onto compliance frameworks that require positive authorisation for every allowed flow.

Neither mode is “better” in absolute terms. Profile mode gives you granular per-policy control and reuses objects efficiently. Policy mode gives you a single, readable, application-centric rulebase, at the cost of losing all the port-based flexibility and of requiring Central NAT.

Key differences at a glance

• Matching criteria — Profile mode: source, destination, service (port), interface, schedule. Policy mode: application, URL category, user/group, and other NGFW objects.
• Where profiles live — Profile mode: attached to each policy. Policy mode: there is no separate “attach profiles” step; the action of the policy carries the inspection.
• NAT — Profile mode supports policy NAT, where the SNAT is configured inside the destination address translation of the policy. Policy mode forces Central NAT: SNAT is defined once in a central SNAT map and referenced by the policies.
• Rule volume — Profile mode tends to produce fewer, broader rules. Policy mode typically produces more, narrower rules.
• Migration — There is no automated converter. Switching modes is effectively a rebuild, which is exactly why Fortinet presents a hard warning before you apply the change.

Notes

• All existing firewall rules will be lost.
• Any objects or interfaces will remain.
• You will need to use Central NAT.

That last point is the one people forget. Objects (addresses, IP pools, services, schedules, users, security profiles) and interface configuration survive the mode change. The rulebase does not. So the practical approach is to screenshot or export your current policies first, understand the intent behind each of them, and rebuild that intent in the new model rather than trying to transliterate rule for rule.

Before you start: preparation and backup

Because this change is destructive by design, treat it as a maintenance-window activity on a production firewall.

1. Back up the configuration. Go to System > Configuration > Backup and save an encrypted copy. From the CLI you can also do it directly:

   execute backup config tftp fgt-backup-before-policy-mode.conf 192.168.1.100
   execute backup full-config tftp fgt-full-before-policy-mode.conf 192.168.1.100

   The full-config variant includes the default values for every setting, which makes diffing far easier if you ever need to reverse the change.

2. Document the existing rulebase. Export or screenshot every policy, including interface pair, source, destination, service, NAT behaviour and attached profiles. You will be recreating this from scratch.
3. Check your NAT object model. Identify every policy that performs SNAT (either via policy NAT or via an IP pool) and note the pool it uses, so you can build the equivalent Central SNAT rules.
4. Note the existing address objects, IP pools and security profiles. These survive, so you do not need to recreate them — but you do need to know their exact names for the rebuild.
5. Confirm out-of-band access. Keep a console or management connection available in case you lock yourself out with the new rulebase.
6. Check the firmware version. Policy mode has been available for many versions, but the exact menu wording and available NGFW objects vary between FortiOS releases. Verify against the documentation for your version.

The Process

• Login to the FortiGate
• Click on System

• Click on Settings

• Under System Operation Settings set the NGFW Mode to Policy-based

• Click Apply

• Confirm that Changing to policy-base mode will remove all firewall policies and Central SNAT will be enabled.

• You are now in Policy mode
• You can now rebuild all your rules.

The same change from the CLI

If you prefer the CLI — or you are automating the build — the NGFW mode is a single setting under system settings. Changing it has exactly the same effect as the GUI button: the rulebase is wiped and Central NAT is switched on.

config system settings
    set ngfw-mode policy-based
end

# Verify the change
get system settings | grep ngfw
show system settings

# The central SNAT table is now the NAT authority
show firewall central-snat-map

Set it back to profile-based to return to the default model — again, with the loss of the existing policy set.

Rebuilding the rulebase in Policy mode

Now the real work starts. In Policy mode, a firewall policy looks fundamentally different from what you are used to. The core objects are:

• Source and destination — interfaces, zones and address objects, exactly as before.
• Application — the NGFW application signature catalogue. This replaces the port-based service object as the primary matching criterion.
• URL category — for web traffic, the category object takes the place of a web filter profile.
• Users and groups — identity-based rules remain available and become far more useful, since the policy is now application-centric.
• Action — allow or deny, with the associated security inspection.

A practical rebuild order that keeps you from locking yourself out:

1. Rebuild the outbound “allow any to Internet” baseline policy first, with the applications your users actually need. Confirm DNS, NTP and FortiGuard connectivity are working before you go further.
2. Add a deny-any / implicit-deny catch-all so unexpected traffic is logged rather than silently dropped.
3. Recreate your Central SNAT rules for each internal subnet that needs to reach the Internet. Without these, outbound traffic will fail even though the policy allows it — this is the single most common mistake after the switch.
4. Add the inbound publishing rules (VIPs / port forwarding) for services that must be reachable from outside.
5. Recreate the inter-VLAN and DMZ policies, this time expressed as application sets rather than port ranges.
6. Re-enable logging and review the implicit deny counters daily for the first week.

Central NAT

In Profile mode you probably used policy NAT: the SNAT address sat inside the destination NAT object of the policy. In Policy mode that option is gone, and all source NAT is centralised. The mapping is now: which internal sources, going out which interface, get translated to which IP pool. Everything that needs Internet access needs an entry here. Typical example:

config firewall central-snat-map
    edit 1
        set srcintf "lan"
        set dstintf "wan1"
        set orig-addr "10.0.0.0/24"
        set dst-addr "all"
        set nat-ip "203.0.113.10"
    next
end

Verify the new mode is active

get system settings
show system settings

# Check that policies were indeed cleared and Central NAT is on
show firewall policy
show firewall central-snat-map

# Confirm sessions are being created as expected
diagnose sys session filter dst-port 443
diagnose sys session list

In the GUI, System > Settings should now show Policy-based under System Operation Settings, and the firewall policy page will present application and URL category columns instead of the profile columns you are used to.

Troubleshooting common problems

• Nothing can reach the Internet after the switch. Almost always a missing Central SNAT entry. Check show firewall central-snat-map and confirm every source subnet has a translation rule out of the correct egress interface.
• Applications are blocked even though the policy allows the traffic. In Policy mode the application signature is authoritative. If the application object does not cover the traffic (for example, traffic that is encrypted with an unknown certificate and therefore cannot be identified), it will not match. Review the implicit deny logs to see what the firewall thinks the traffic is.
• You locked yourself out. Connect on the console, disable the offending policy temporarily with config firewall policy → set status disable, or restore the pre-change backup.
• Rules look impossible to migrate. That is expected. Port-based rules have no direct application-based equivalent. Use the opportunity to define intent, not to transliterate syntax.
• You need to go back. Set ngfw-mode back to profile-based and restore your backup. The backup is your only realistic rollback path, because the original policy set was destroyed at the moment you clicked Apply.

Should you switch at all?

Switch to Policy mode if you want an application-centric, allow-list rulebase, if you rely heavily on user- and group-based policy, or if a compliance requirement demands explicit authorisation for every permitted flow. Stay in Profile mode if you have a large, mature rulebase built around ports and zones, if you depend on policy NAT, or if rebuilding and re-validating every rule is not something you can schedule a maintenance window for. The technical change takes a minute; the rulebase rebuild and the validation of user experience take the rest of the day.

That’s all it takes to enable policy mode on a Fortinet FortiGate.