Firewall policy evaluation is the central decision point in FortiGate administration. A route can deliver a packet to the correct interface, but an appropriate policy must still match before that session is forwarded. Conversely, an allow rule can exist in the configuration without ever matching the traffic that its author intended. The FortiOS 7.6 Administrator exam asks candidates to configure policies, understand inspection modes and interpret policy traffic logs, so preparation should focus on explaining packet-specific decisions.
The useful question is not “Where is the allow button?” It is “Which session attributes does the FortiGate evaluate, which matching rule wins, and how would I verify the action taken?”
Identify the correct policy inputs
A normal forward firewall policy considers the relevant ingress and egress interfaces or zones, source and destination addresses, service definitions, schedules and other configured conditions. Identity-based rules can also depend on user authentication. A network change that moves an interface into a different zone or alters a routed destination can affect policy matching even if the policy’s address objects have not changed.
Fortinet’s FortiOS 7.6 firewall policy reference describes policy parameters and match behavior. The important practice is to trace the real packet: original source, original destination, protocol/port, arrival interface, determined outgoing interface and any identity context. A policy that permits TCP 443 from one subnet may not authorize another subnet or a custom service on a nonstandard port.
For example, a workstation in VLAN 20 cannot access an internal application after being moved from VLAN 10. One explanation is that the destination application’s rule explicitly includes VLAN 10’s source subnet but not VLAN 20. Another is that the new VLAN’s route sends traffic through a different security zone. Checking actual source and interface conditions distinguishes those cases without creating a broad all-networks allow policy.
Understand ordering, specificity, and VIP behavior
Firewall policies are evaluated according to FortiOS behavior and configured order. A more permissive rule placed before a specific intended restriction may prevent that restriction from being applied. Do not simply assume that the policy with the most familiar name wins. Read the evaluation order and identify which matching criteria could cause a different rule to apply to the observed session.
Destination NAT using virtual IP (VIP) objects introduces a less obvious detail: Fortinet documents different matching considerations when a policy references a VIP. An explicit deny preceding a published service may need the appropriate VIP-matching configuration to match the traffic expected. A simple generalization about all denies and allows can therefore be misleading. The official 7.6 policy reference explicitly discusses the match-vip behavior.
The explicit versus implicit denial distinction remains useful at a conceptual level. A deliberately created deny rule can carry a different operational purpose and logging choice from unmatched traffic rejected by the default policy. Neither should be described as proof of an upstream routing problem without associated evidence.
Keep policy authorization separate from routing
Routing determines where traffic can be forwarded; security policy decides whether the traffic is allowed under the configured conditions. Both are necessary. A missing route and an absent allow rule can produce the same user-visible complaint, but their traces differ. Before changing the policy list, verify what the routing table says for the destination. Before changing the route, verify whether the packet is already being denied by an identifiable rule.
A return path is also part of successful communication. The initial packet may leave the FortiGate under an allowed policy and still receive no usable response because the far side routes replies elsewhere. Packet capture and session evidence help determine whether return packets arrived at the expected interface. A correct policy cannot repair a destination application’s own host firewall or an upstream ACL blocking the reply.
NAT can change what addresses the next device sees, but a translated session is still subject to the FortiGate’s documented policy and route processing. When diagnosing, record both pre-translation and post-translation addresses instead of assuming all systems will display the original client address.
Choose an inspection mode deliberately
FortiGate supports flow-based and proxy-based inspection concepts. The feature set available and the detailed behavior can depend on the policy mode, hardware resources and FortiOS build. Flow-based inspection analyzes traffic during forwarding, while proxy-based paths can introduce proxy processing capabilities. They should not be treated as identical labels that merely control a report view.
When a security profile is attached to a firewall policy, its compatible inspection settings matter. A web-filter profile configured for a flow mode cannot always be applied in the same way to a proxy-mode policy. Fortinet’s 7.6 web-filter configuration documentation explicitly notes compatibility between profile feature set and policy inspection mode.
Operationally, select inspection based on the controls required, feature support, throughput and compatibility, not just on a generic claim that one mode is always more secure. Changes can affect TLS interception and application behavior; tests should focus on the actual protocols and protected applications in use.
Attach and verify the right security controls
Permitting traffic and inspecting it are separate decisions. An accepted policy can forward traffic without a web filter, antivirus scanner or IPS sensor if those controls were not configured for that path. Conversely, a correct profile may be attached to a rule that the traffic never matches. Both cases can create a false sense of protection.
For a specific test session, determine which policy ID actually matched, which inspection mode applied, which security profiles were active and which events were recorded. If an intrusion signature produces a block, the related security log should help distinguish it from the firewall’s ordinary policy decision. Changing the main allow rule may not address the content-inspection outcome.
Encrypted traffic adds another boundary: a profile that needs visibility into application content may not have it unless an appropriate, authorized inspection method is configured and the endpoint trusts the required certificates. This is why rule evaluation, SSL inspection and security-profile activation should be taught as a connected chain without collapsing them into one control.
Use logs to confirm policy results
A policy’s traffic log settings govern which session events FortiOS is configured to record. Analyze the action, source/destination, protocol, policy identity and timing of a relevant test rather than interpreting a dashboard count alone. Logs must also be delivered to a reachable storage or analysis destination if the investigation relies on an external system.
Imagine an engineer who sees an allow event for a remote service but the user still receives a timeout. The allow log proves a policy decision, not successful end-to-end application response. Inspect whether a reply was seen, whether NAT or routing changed the return path and whether the server itself is accepting the connection. This keeps firewall logging from becoming a false all-purpose answer to application incidents.
At the other extreme, absence of an event does not always mean the firewall never saw the packet. The relevant policy may not log, the filter may use the wrong address after NAT, or the event may not have reached the analyzer. Diagnose the logging path before treating an empty search as an authoritative packet-flow conclusion.
Avoid overly broad rules during troubleshooting
A common shortcut is to temporarily permit all traffic from an affected subnet. It may make a test succeed while exposing unnecessary services, masking a wrong route or bypassing profiles. If such an exception is truly required for an authorized diagnostic, scope it narrowly, time-limit it and document exactly what condition it is intended to test. The goal is to preserve network protection while identifying the actual mismatch.
Rule quality also depends on maintainability. Meaningful policy naming, address objects that represent actual network segments and clear logging make later investigations easier. A rule with unbounded source, destination and service conditions is difficult to reason about and can create unexpected overlap with more restrictive rules.
Policy reviews should ask whether the rule is reachable in the intended order and whether its business owner still requires it. This is an operational concern rather than a memorized exam fact, but it directly supports safe FortiGate administration.
Schedule and service objects can also conceal policy mismatches. A rule may allow a protocol on a particular port only during a permitted time window, while an application is actually using another protocol or destination port. Do not substitute an application-control category for the service field of the basic firewall policy: those controls answer different questions. When a session fails at a predictable hour or after an application’s port change, check the configured schedule, actual traffic tuple and policy match before declaring the firewall unstable.
Practice policy diagnosis with competing hypotheses
Case one: only a newly created subnet cannot reach a permitted HTTPS application. Compare incoming zone, source object and route selection. Case two: traffic reaches a public VIP but is unexpectedly denied for a particular source. Review VIP matching and deny placement. Case three: normal browsing works but an inspected application fails with a TLS warning. Check certificate trust and profile behavior rather than assuming that the IP allow rule was missed.
For each case, record the packet tuple, chosen route, expected policy, observed policy, NAT state and security event. Good preparation means being able to say exactly what output would disprove your first hypothesis. That skill translates beyond the exam: it reduces unsafe changes and produces explanations another administrator can independently verify.