Skip to content

Add a Firewall Policy

A firewall policy is the rule that decides whether a flow of traffic is allowed. FortiGate is deny-by-default: if no policy permits the traffic, it's dropped. Every flow between two interfaces (LAN → WAN, LAN → DMZ, etc.) needs a policy to pass.

Policies match on: incoming interface, outgoing interface, source address(es), destination address(es), service (port/protocol), schedule, and user. The first matching policy wins (top-down). Action is Accept (with or without NAT) or Deny.

Before You Start

  • The source and destination interfaces exist and are up.
  • Any custom address or service objects you'll reference are created (or use built-ins like all and ALL).
  • You know which direction traffic flows. Policies are unidirectional — a policy allowing LAN → WAN does NOT also allow WAN → LAN.

Steps

  1. Policy & Objects → Firewall Policy → + Create New.
  2. Fill in:
    • Name — meaningful, e.g. LAN-to-Internet or Block-Guest-from-LAN.
    • Incoming Interface — source interface (e.g. internal).
    • Outgoing Interface — destination interface (e.g. wan1).
    • Source — what addresses initiate the flow. all for any, or pick an Address object.
    • Destination — where they're going. all for any, or pick.
    • Schedulealways unless this is time-restricted.
    • Service — what services/protocols. ALL permits everything; narrower is safer (e.g. HTTP, HTTPS, DNS).
    • Action:
      • Accept — allow it.
      • Deny — drop it explicitly (used for blocking-rules above broader allows).
    • Inspection ModeFlow-based (default; faster) or Proxy-based (slower; supports more features like AV file inspection).
    • NAT (for Accept policies going to WAN): Enabled typical for LAN→WAN (so private IPs are SNAT'd to the WAN IP).
    • IP Pool ConfigurationUse Outgoing Interface Address (default) or pick an IP Pool.
    • Security Profiles — attach AV, IPS, Web Filter, etc. as needed (see Security Profiles).
    • Logging OptionsLog Allowed Traffic to All Sessions if you want full visibility (recommended for troubleshooting; disk-heavy on busy networks).
    • Comments — optional notes.
    • Enable this policyOn.
  3. Click OK.
  4. Drag the new policy into the right position in the list. Policies are evaluated top-down — narrow / specific rules go above broad / catch-all rules.

CLI Equivalent

config firewall policy
edit 0
    set name "LAN-to-Internet"
    set srcintf "internal"
    set dstintf "wan1"
    set srcaddr "all"
    set dstaddr "all"
    set action accept
    set schedule "always"
    set service "ALL"
    set nat enable
    set logtraffic all
next
end

Verify

# Show all policies and hit counts:
diagnose firewall iprope show 100004 | grep "rule "

# Or check the live hit count of a specific policy in GUI:
# Policy & Objects → Firewall Policy — bytes/packets columns update live.

Generate test traffic from the source. The policy hit counter should increment.

Common Issues

  • Traffic blocked despite the policy existing. A higher (more-specific) policy denies it first, OR the source/destination doesn't actually match. Test with diagnose debug flow to see exactly which policy matches a packet.
  • Policy 0 in logs. No policy matched — implicit deny fired. Add a policy or fix match criteria.
  • NAT didn't happen. NAT toggle is off on the policy, or you're going between two internal interfaces (NAT usually doesn't apply there).
  • All traffic blocked after adding a Deny policy. Deny policy too broad and above your Accepts. Reorder or tighten the Deny.