FortiGate Firewall Policy Configuration with a Real-Life Example

Configuring a firewall policy on a FortiGate is one of the most essential tasks for a network engineer. A FortiGate operates as a stateful firewall. It blocks all traffic by default until you create an explicit rule to permit it. Mastering FortiGate firewall policy configuration ensures your enterprise network remains secure while allowing critical business applications to function smoothly.

In this guide, you will learn how to configure a practical, stateful FortiGate firewall policy. We will cover real-world business requirements, address object creation, step-by-step GUI and CLI setups, traffic flow mechanics, and diagnostic commands.

Real-Life Scenario

Acme Corporation is deploying a new FortiGate firewall at a branch office location. The local network uses VLAN 10 for internal corporate staff clients. The site connects directly to an Internet Service Provider (ISP) router on its WAN interface.

The security team requires a policy that fulfills the following strict rules:

• Corporate internal users on VLAN 10 must access web services (HTTPS) on the internet.
• Internal users must resolve domain names via public DNS servers (UDP port 53).
• All outbound connections must use Source Network Address Translation (SNAT) so internal private IP addresses stay hidden.
• All unsolicited inbound connections from the internet to the internal network must remain completely blocked.
• All permitted sessions must generate traffic logs for auditing purposes.

Lab Topology

The following diagram shows the logical topology used in this configuration example:

+-----------------------------+
|    Internal LAN Clients     |
|    Subnet: 192.168.10.0/24  |
+-----------------------------+
              |
              | (Interface: port2)
              | IP: 192.168.10.1/24
      +---------------+
      |   FortiGate   |
      | Firewall Appliance |
      +---------------+
              | IP: 198.51.100.2/24 (LAB/EXAMPLE)
              | (Interface: port1)
              |
      (Gateway: 198.51.100.1)
+-----------------------------+
|      Public Internet        |
+-----------------------------+

Example Addressing and Objects

The following values are used in our lab configuration. You must adapt these example address ranges and interface names to match your specific production network.

Prerequisites

Before creating the firewall policy, verify that your environment meets the following conditions:

• Interfaces port1 and port2 are up and assigned their respective IP addresses.
• A static default route exists on the FortiGate pointing 0.0.0.0/0 to the ISP gateway (198.51.100.1) via port1.
• Administrative access to the FortiGate GUI or CLI with read-write privileges.

Note: FortiOS menu paths and syntax can vary slightly depending on your installed FortiOS release (such as 7.0, 7.2, or 7.4), hardware platform, or active feature display settings.

Step-by-Step GUI Configuration

Follow these steps to create the address objects and the firewall policy using the FortiGate Graphical User Interface (GUI).

Step 1: Create the Source Address Object

Before referencing a local subnet in a firewall policy, create a dedicated firewall address object for clarity and reuse.

1. Navigate to Policy & Objects > Addresses.
2. Click Create New > Address.
3. Configure the following parameters:
   • Name: ADDR_LAN_192.168.10.0_24
   • Type: Subnet
   • IP/Netmask: 192.168.10.0/255.255.255.0
   • Interface: Any (or pin it specifically to port2)
4. Click OK to save the object.

Step 2: Create the Outbound Firewall Policy

Next, define the policy that controls traffic moving from the internal network to the external internet.

1. Navigate to Policy & Objects > Firewall Policy.
2. Click Create New.
3. Fill in the firewall policy fields as follows:
   • Name: Corporate_Outbound_Web_DNS
   • Incoming Interface: port2
   • Outgoing Interface: port1
   • Source: Select ADDR_LAN_192.168.10.0_24
   • Destination: Select all
   • Schedule: always
   • Service: Select HTTPS and DNS
   • Action: ACCEPT
4. Scroll down to the Firewall / NAT settings:
   • Toggle NAT to Enabled.
   • Select Use Outgoing Interface Address.
5. Under Logging Options:
   • Toggle Log Allowed Traffic to Enabled.
   • Select All Sessions (recommended during initial setup to verify traffic flows).
6. Click OK to enforce the policy.

CLI Configuration

For administrative efficiency or script deployments, you can execute the configuration using the Command Line Interface (CLI). Enter the following commands into your FortiGate CLI session:

config firewall address
    edit "ADDR_LAN_192.168.10.0_24"
        set subnet 192.168.10.0 255.255.255.0
    next
end

config firewall policy
    edit 1
        set name "Corporate_Outbound_Web_DNS"
        set srcintf "port2"
        set dstintf "port1"
        set action accept
        set srcaddr "ADDR_LAN_192.168.10.0_24"
        set dstaddr "all"
        set schedule "always"
        set service "HTTPS" "DNS"
        set nat enable
        set logtraffic all
    next
end

This CLI sequence builds the exact address object and firewall policy configured in the GUI section. It restricts client access specifically to HTTPS and DNS protocols while enabling Source NAT and full session logging.

How the Traffic Flows

Understanding how FortiOS processes packets is crucial for effective troubleshooting. When a corporate PC on VLAN 10 initiates a web request to a external web server, the FortiGate handles the traffic through a sequence of steps:

1. Ingress Processing: The frame arrives on interface port2. The FortiGate verifies that the interface is up and processes the IPv4 packet.
2. Routing Table Lookup (Ingress): FortiOS checks its routing table to determine the outgoing interface for the destination IP address. It matches the default route (0.0.0.0/0) pointing out interface port1.
3. Firewall Policy Matching: FortiOS evaluates active policies from top to bottom. It matches the packet based on:
   • Ingress Interface (port2)
   • Egress Interface (port1)
   • Source IP Address (192.168.10.X matches ADDR_LAN_192.168.10.0_24)
   • Destination IP Address (Matches all)
   • Destination Port / Protocol (Matches service HTTPS or DNS)
4. NAT Translation: Because NAT is enabled, FortiOS rewrites the source IP address in the packet header from the client’s internal address (e.g., 192.168.10.50) to the WAN interface address (198.51.100.2).
5. Session Table Entry Creation: The FortiGate writes a new connection entry into its stateful session table, tracking source, destination, port numbers, NAT mappings, and policy ID.
6. Egress Processing: The modified packet is transmitted out port1 toward the ISP gateway.
7. Return Traffic Handling: When the external web server responds to 198.51.100.2, the packet matches the active stateful session table entry. FortiOS automatically rewrites the destination IP back to 192.168.10.50 and forwards it to port2. Return traffic does not undergo a second firewall policy lookup.

Verification

After applying the configuration, confirm that your policy processes sessions correctly using these standard CLI verification commands.

1. Check Active System Interfaces

Verify that your local and internet interfaces carry valid IP addresses and link state:

get system interface physical

2. Confirm Routing Table Lookup

Ensure the default gateway route is present in the active forwarding information base (FIB):

get router info routing-table all

Look for an active static route entry such as:

S*      0.0.0.0/0 [10/0] via 198.51.100.1, port1

3. Verify Stateful Session Creation

To confirm that user traffic actively hits your rule, establish a connection from an internal host and inspect the firewall session table. Apply a session filter first to prevent output overload.

diagnose sys session filter src 192.168.10.50
diagnose sys session list

The output displays the active stateful tracking entry, indicating policy ID, NAT translations, and socket details:

session info: proto=6 proto_state=01 duration=12 expire=358 timeout=3600 flags=00000000 dev=3/4 gwy=198.51.100.1/4
statseg=0 slot=0
192.168.10.50:52130 -> 198.51.100.100:443 [198.51.100.2:52130 -> 198.51.100.100:443]
policy_dir=0 policy_id=1 auth_info=0 chk_pt_flags=0 submit_type=0

Troubleshooting

If users on VLAN 10 cannot access external web services, follow a structured, step-by-step troubleshooting workflow.

Troubleshooting Sequence: Interface/Link → Routing → Policy Match → NAT Translation → Session State → Packet Flow Debug.

Step 1: Verify Physical Link and Host IP Settings

Confirm the workstation on VLAN 10 has acquired a valid IP address (192.168.10.X), subnet mask, and default gateway set to 192.168.10.1.

Step 2: Confirm Routing to External Destinations

Test connectivity from the FortiGate itself to an external upstream IP address to rule out upstream carrier problems:

execute ping 198.51.100.1

Step 3: Run the FortiGate Packet Trace Debug

If routing is functional but user traffic is dropped, use the FortiOS packet flow trace tool. This tool shows exactly why a packet is permitted, dropped, or translated in real-time.

CAUTION: Diagnostic debug tools display live traffic information on screen and consume CPU cycles. Always set explicit filters before enabling trace tools, and turn off debugs when finished.

diagnose debug reset
diagnose debug flow filter saddr 192.168.10.50
diagnose debug flow filter daddr 198.51.100.100
diagnose debug flow show console enable
diagnose debug flow trace start 10
diagnose debug enable

Observe the console output while initiating a session from the client machine. Look for lines detailing the matching policy ID or drop reasons:

id=20013 trace_id=1 msg="allocate a new session-0000a1b2"
id=20013 trace_id=1 msg="find a route: flag=00000000 gw-198.51.100.1 via port1"
id=20013 trace_id=1 msg="Allowed by Policy-1:"
id=20013 trace_id=1 msg="SNAT 192.168.10.50->198.51.100.2:52130"

If the debug output reads "Implicit Deny", your packet failed to match the configured policy parameters (check source IP, service protocol, or interface assignments).

Step 4: Clean Up Debugging Output

Always disable active debug processing immediately after capturing your test results:

diagnose debug disable
diagnose debug reset

Common Mistakes

When engineering firewall policies on FortiGate platforms, administrators often run into several common misconfigurations:

• Forgetting Source NAT (SNAT): Outbound internet access policies require NAT when using private source IP addressing (RFC 1918). Without SNAT, internet routers drop response packets because private subnets are non-routable on the public internet.
• Incorrect Policy Ordering: FortiGate processes rules strictly from top to bottom. Placing a broad “Deny” rule above a specific “Allow” rule causes FortiGate to block the traffic before reaching your intended policy.
• Mismatched Interface Objects: Setting the wrong Incoming Interface (e.g., matching port3 instead of port2) stops traffic from matching the policy.
• Blocking Mandatory Core Services: Users often allow HTTP/HTTPS but forget DNS (UDP port 53). Web browsers fail to load websites without working name resolution.
• Central NAT Confusion: If your FortiGate uses Central NAT mode instead of Policy-based NAT, setting set nat enable directly inside individual firewall policies will not work. You must define dedicated Central SNAT rules under Policy & Objects > Central SNAT.

Production Considerations

While basic firewall policy configuration opens paths for network communication, enterprise production environments demand additional layer-7 controls and visibility.

Security Profiles (UTM Inspection)

Allowing raw TCP port 443 grants network connectivity, but it does not protect hosts from downloading malware. Attach Unified Threat Management (UTM) Security Profiles directly to outbound rules:

• Antivirus: Scans web downloads for malicious signatures in real time.
• Web Filtering: Blocks access to known malicious, phishing, or inappropriate web categories.
• Application Control: Identifies and controls evasive apps operating over standard web ports.

SSL Inspection

Modern internet traffic is almost entirely encrypted with HTTPS. Without SSL/TLS inspection, deep security profiles cannot inspect payload contents for hidden malware threats. Configure Certificate Inspection at minimum, or deploy full Deep SSL Inspection alongside corporate CA trust certificates on client devices.

Log Management

Logging every session (set logtraffic all) generates substantial log output. In high-throughput enterprise environments, change this setting to utm-only (Security Events) once initial testing is complete. This reduces CPU load and conserves storage on local disks or external FortiAnalyzer appliances.

Summary

A properly structured FortiGate firewall policy configuration bridges internal user networks with external services safely. By combining accurate interface bindings, precise address objects, selective service rules, and stateful Source NAT translation, you create an explicit outbound path while protecting internal networks from unsolicited external access.

Always verify active session tracking with diagnose sys session list and utilize packet trace filtering (diagnose debug flow) whenever troubleshooting session flows. Incorporating these standard configuration practices builds a robust security foundation across your enterprise FortiGate firewall fleet.