FortiGate Policy Configuration: Step-by-Step Guide (2026)

FortiGate policy configuration is how you define which traffic may pass from which interface to which destination on which service—and which security profiles apply. Short answer: do it in this chain—zones/interfaces → address and service objects → top-down policy order → NAT → UTM/NGFW profiles → logging. Starting with any-any allow breaks both security and auditability; start with a default-deny skeleton.

This guide is written for:

• Network and security teams deploying and operating FortiGate
• Admins migrating policies from another firewall
• IT managers producing ISO 27001 access-control evidence
• Decision makers standardizing edge, VPN, and segmentation policy

Quick Summary

• FortiGate policy match uses ingress interface + protocol + source/destination address + ports/services.
• Policies are evaluated top-down; the first match wins.
• Build zones and default-deny first; then allow applications one by one.
• Design NAT (SNAT/VIP) with the policy; NAT mistakes often look like “no internet.”
• IPS/AV/web/app profiles consume Threat Protection capacity; confirm licensing.
• Enable logging on every allow rule for operational and audit evidence.

Table of Contents

• What Is FortiGate Policy Configuration?
• Prerequisites: Zones, Objects, and Routes
• Step-by-Step Policy Creation
• NAT, VIP, and Egress Traffic
• Security Profiles and SSL Inspection
• Policy Order and Best Practices
• Validation and Troubleshooting
• Most Common Mistakes
• Related Articles
• Checklist
• Next Step with LeonX
• Frequently Asked Questions
• Sources

Image: Wikimedia Commons - Barracuda Webfilter 210 (example enterprise security appliance form factor).

What Is FortiGate Policy Configuration?

A FortiGate firewall policy is the control plane that allows or denies stateful sessions. Per Fortinet documentation, matching uses interface, protocol, source/destination address, and related ports. For product definition, see What Is a FortiGate Firewall?; for packet flow, see How Does a Fortinet Firewall Work?.

Short definition:

FortiGate policy configuration is designing and applying top-down allow/deny rules that control traffic by zone/interface, address, service, NAT, and security profiles.

To align with ISO 27001 access control, also use FortiGate Access Control for ISO 27001.

Prerequisites: Zones, Objects, and Routes

Before writing policies, build this skeleton:

For VLAN segmentation, see FortiGate VLAN Configuration. For SSL VPN resource access, see SSL VPN Setup.

Pro Tip: Name objects by role + purpose (LAN-Users, SVC-HTTPS, WAN-Internet). Names like Address1 / Policy12 become unreadable in 6 months.

Step-by-Step Policy Creation

This flow is common to GUI (Policy & Objects > Firewall Policy) and CLI:

1. Select Incoming / Outgoing interface (or zone).
2. Set Source address (and user/group if needed).
3. Set Destination address/object.
4. Narrow Service (HTTP/HTTPS, DNS, custom ports).
5. Set Action to Accept or Deny.
6. Enable NAT when required (outbound SNAT on most edges).
7. Attach Security profiles (IPS, AV, Web Filter, App Control).
8. Enable Log Allowed Traffic.
9. Place the policy in the correct order (specific rules above).
10. Save and validate with sessions/tests.

Example outbound skeleton (logic):

FortiGate has an implicit deny; an explicit deny + log still improves operational visibility.

NAT, VIP, and Egress Traffic

Outbound internet typically uses SNAT on the policy (outgoing interface address or IP pool). Inbound publishing needs VIP/DNAT plus a separate inbound policy.

For NAT outages, use FortiGate NAT Troubleshooting and No Internet Access. In site-to-site designs, keep policy selectors aligned with IPsec: Site-to-Site VPN.

Security Profiles and SSL Inspection

Profiles attached to policies create NGFW protection; without FortiGuard licensing, expected effect will not arrive. See Fortinet License Types.

Watch-outs:

• Enabling IPS/AV consumes Threat Protection capacity; see Model Selection.
• Web Filter mis-categorization can break business apps—start with monitor/log where possible.
• Unplanned SSL inspection causes certificate and application breakage; see SSL Inspection.

Policy Order and Best Practices

1. Most specific rules on top (single host / single service).
2. Broad allows at the bottom—or nowhere.
3. Restrict admin access with separate policy + management network.
4. Tag temporary rules with ticket/date; review after 30 days.
5. Hunt shadowed policies that never match.
6. Avoid mass allows outside a change window.

For ISO 27001 network controls, see ISO 27001 Network Security: Firewall and VPN.

Validation and Troubleshooting

After saving a policy:

1. Test from a client (DNS, HTTPS, custom port).
2. Find the policy ID in Forward Traffic logs.
3. Confirm matched policy, NAT, and state in the session table.
4. Use diagnose / packet capture for interface direction if needed.
5. In HA, validate both nodes after config sync: HA Installation.

If the policy looks right but traffic fails, check in order: route → interface → service → NAT → profile/inspection.

Most Common Mistakes

• Starting with temporary any-any allow
• Ignoring order (broad rule on top)
• Leaving Service = ALL
• Expecting internet without SNAT
• Allow rules with logging off (no audit evidence)
• Enabling SSL inspection for all traffic at once

Related Articles

• What Is a FortiGate Firewall?
• How Does a Fortinet Firewall Work?
• FortiGate Access Control for ISO 27001
• FortiGate NAT Troubleshooting
• FortiGate VLAN Configuration
• FortiGate SSL Inspection
• Fortinet License Types Explained
• ISO 27001 Network Security: Firewall and VPN

Checklist

• Zone model (WAN/LAN/DMZ/Guest) defined
• Address and service objects named clearly
• Default-deny skeleton in place; no any-any
• Outbound SNAT / inbound VIP needs clarified
• UTM profiles licensed and capacity-appropriate
• Logging enabled on allow rules
• Policy order set specific → general
• Policy ID validated via session/log

Next Step with LeonX

FortiGate policy configuration sets the real security level of the firewall. Bad order or open policies create outage and audit risk. LeonX builds zone, policy, and UTM standards under Hardware and Software Solutions, especially Router, Switch and Firewall Deployment Service and Network Security, Firewall and IPS/IDS Solutions. For discovery, continue through Contact.

Frequently Asked Questions

What is FortiGate policy configuration?

It is configuring the rule set that decides which traffic may pass by interface/zone, source, destination, and service—and how NAT and security profiles are applied.

Why does policy order matter?

Rules are evaluated top-down; the first match wins. A broad allow above specific deny/allow rules shadows everything below it.

How do I apply default deny?

Separate zones, write only required allows, and make unwanted traffic visible with deny + log. Do not leave everything open because an implicit deny exists.

Is NAT configured on the policy or separately?

Outbound SNAT is usually enabled on the firewall policy. Inbound uses a VIP/DNAT object plus an inbound policy together.

Policy looks correct but traffic fails—where first?

Check route, ingress interface, service/port, NAT, then profile/inspection effects. The policy ID in logs is the fastest clue.

Sources

• Fortinet Document Library - Firewall policy
• Fortinet Document Library - Using a session table
• Fortinet Document Library - Network address translation (NAT)
• Fortinet Document Library - Security profiles
• Wikimedia Commons - Barracuda Webfilter 210