Firewall Policy, Security Profiles, and Traffic Shaping
Firewall Policy
Policy evaluation and NAT
Firewall policies are evaluated top-down, first match wins, regardless of how specific the match is. A broad any → any accept rule placed above a specific block rule makes the block rule unreachable. FortiGate adds an implicit deny at the bottom of every policy table, and that implicit deny does not log by default - if you need to see what is being dropped, add an explicit deny policy with logging enabled. The policy lookup tool in the GUI shows exactly which policy matched and why.
A policy's incoming interface must be a specific interface or zone; "any" is not offered as an incoming interface. Source and destination addresses, users, services, schedules and security profiles are all matched elements. Policies are per-VDOM, so identical policy IDs can exist in different VDOMs.
NAT is enabled inside the policy. With NAT on and no IP pool, FortiGate translates the source to the egress interface address (hide NAT/overload). With an IP pool it uses the pool addresses or a port block. Destination NAT is handled by a VIP object: the policy destination must reference the VIP, not the internal server IP. If central (SNAT) NAT is configured, per-policy NAT settings are ignored - a frequent trap.
Worked example: users report a web server is unreachable. A VIP maps 203.0.113.10:80 → 10.0.0.10:80, but the policy's destination is 10.0.0.10. The packet arrives, the VIP translates the destination, and the policy lookup fails to match, so traffic hits the implicit deny. Fixing the policy destination to the VIP object restores service.
Security Profiles and Traffic Shaping
Profiles, inspection mode, and shaping
Security profiles are objects - antivirus, IPS, web filter, application control, DNS filter, file filter, email filter, SSL/SSH inspection - attached to an accepting firewall policy. A profile group bundles several profiles and attaches as one object. The policy's inspection mode matters: flow-based inspection is faster and inspects streams, while proxy-based inspection buffers and can apply more granular actions. Some features behave differently or are unavailable in one mode.
Traps to expect. Web filter actions include allow, block, monitor and warning: monitor only logs, it does not block. Application control depends on the IPS engine and signatures. SSL inspection comes in two flavors - certificate inspection reads the certificate/SNI to classify traffic, while deep (full) inspection re-signs traffic and requires the FortiGate CA certificate on clients; pinned applications may break, so exemption categories exist. Profile behavior also depends on the traffic's protocol and direction.
Traffic shaping controls egress bandwidth. A shared shaper divides one bandwidth limit across all sessions matching it; a per-IP shaper gives every source IP its own limit. Shapers are applied either in the firewall policy (with a priority) or through shaping policies that match users, applications or interfaces. Guaranteed bandwidth only helps when priority queuing arbitrates contention; the maximum bandwidth caps the traffic. Shaping acts on traffic leaving the interface, and a shaper can also be placed on the reverse direction to control return traffic.
Rule of thumb: shape on the policy whose traffic egresses the link you want to control, and use per-IP shapers when a handful of users would otherwise starve everyone on a shared shaper.