The current FortiGate 7.6 blueprint is easiest to understand as a packet-and-management path. The platform must be configured and healthy. Routing decides where traffic goes. Firewall policy decides whether it is allowed and which inspection/security profiles apply. Authentication can add user identity. Content inspection analyzes the permitted flow. VPN can encrypt traffic between sites. Logs, packet capture and debug flow explain what actually happened.
The current FortiGate 7.6 Administrator weighting is 20–25% Deployment/System Configuration, 20–25% Firewall Policies and Authentication, 25–30% Content Inspection, 10–15% Routing and 10–15% VPNs.
Platform health sits below every packet decision
Licensing, firmware, configuration backup, administrative access, CPU/memory, interfaces and system state need to be healthy before policy troubleshooting is meaningful.
A firewall under conserve mode or with an interface/link issue can create symptoms far above the system layer.
Logs and packet diagnostics provide the evidence layer
FortiGate logs, FortiAnalyzer, packet sniffing and debug flow help determine whether traffic arrived, which policy matched and where processing stopped.
Evidence should guide changes instead of repeatedly editing policies until traffic happens to work.
Routing selects the path before policy action matters
Static routes, default paths, route priorities and SD-WAN decide where packets are sent. A missing route can make a correct firewall policy irrelevant.
SD-WAN introduces performance-aware link selection and quality status across multiple WAN paths.
Firewall policies create the security decision point
Policies match source, destination, service and other context. They can also apply logging, NAT and inspection profiles.
The map should keep policy order and matching separate from security-profile behavior: first determine whether the right rule is selected.
NAT changes how traffic is represented across boundaries
SNAT changes the source identity of outbound traffic; DNAT with VIPs exposes internal resources under translated destination addresses.
Routing, policy and NAT must agree. A translation can be correct while a route or policy still blocks the session.
Authentication can add user identity to policy
LDAP, RADIUS, active/passive authentication and FSSO let policy decisions reflect users rather than only IP addresses.
Authentication troubleshooting should distinguish directory reachability, credentials, collector state, user mapping and firewall policy.
Content inspection analyzes permitted traffic
SSL inspection, web filtering, application control, antivirus and IPS sit on the traffic path after the firewall accepts the session.
This is why an allowed connection can still be blocked later by a security profile.
Inspection mode changes how some security features work
Flow-based and proxy-based inspection process traffic differently and can influence available settings or behavior. The administrator should choose the mode according to the security need and performance/feature trade-off.
Certificate trust is especially important for full encrypted inspection.
VPN adds an encrypted path over routed networks
IPsec peers, selectors, authentication and redundancy create secure site connectivity, but the tunnel still depends on routing and policy.
VPN logs and packet diagnostics should be interpreted with the same layered map used for ordinary sessions.
HA protects appliance availability
FGCP clustering synchronizes state and enables failover when a firewall member fails. Management interfaces and firmware-upgrade behavior add operational considerations.
The map should show DHCP on the infrastructure edge because FortiGate can provide client addressing while also routing and securing that traffic. A DHCP failure can prevent clients from obtaining usable network configuration before any firewall policy is evaluated.
Administrator access belongs on the management plane, separate from user traffic. HTTPS/SSH administrative paths, trusted hosts, roles/profiles and interface access settings can fail while firewall forwarding remains healthy. The first troubleshooting question is which plane is affected.
FortiGuard licensing should connect content inspection and updates. Web categories, antivirus, IPS and other security services can depend on subscriptions and signature/category updates. An expired or unreachable service can change protection behavior even when firewall policy remains unchanged.
HA should also be connected to routing and interfaces. Cluster members need consistent interface configuration and heartbeat communication, while upstream/downstream network design must allow traffic to reach the active member after failover.
Debug flow belongs after route and policy hypothesis, not as the first tool for every incident. It can show FortiGate’s packet decision, while packet sniffer proves what enters/leaves interfaces. Combining both is stronger than reading one output without topology context.
Authentication should be mapped before content inspection because user identity can determine which policy matches. If FSSO or remote authentication fails, traffic may fall to a different rule or be blocked before web/AV/IPS profiles are reached.
VIP-based DNAT belongs on the inbound-publication path. External clients reach a public/translated destination; FortiGate maps it to an internal server and applies policy. Troubleshooting should verify external route, VIP match, policy, server return path and local service state.
SSL inspection should wrap web/application security because encrypted traffic hides URLs, certificates and application payloads. Certificate inspection reveals limited metadata, while full inspection enables deeper security profiles at the cost of trust/decryption complexity.
Web filtering, Application Control, Antivirus and IPS should be drawn as separate security profiles with independent reasons to block traffic. When a session fails, logs should identify which profile acted rather than prompting the administrator to disable all inspection.
SD-WAN health checks belong on the observability side of routing. Link performance can change path preference before a link is completely down. This explains why users may see traffic move between WANs even though both interfaces remain administratively up.
VPN selectors should connect local/remote protected networks with route and policy. A tunnel can negotiate successfully while interesting traffic does not match the selectors. The administrator should distinguish tunnel-state evidence from data-plane evidence.
Cloud FortiGate and CNF should be placed as deployment variants around the same FortiOS security model. Cloud provider routing, interfaces and lifecycle differ, but firewall policy, inspection, logs and core FortiOS concepts remain recognizable.
FortiSASE belongs on the remote-user edge of the map. Instead of sending every user through a physical branch firewall, security services can be delivered from cloud points of presence. The core exam expects purpose and onboarding context rather than deep SASE architecture design.
Use the completed map on one failure: a remote user reaches the internet but a business site is blocked. Check SASE/FortiGate path, identity/policy, SSL inspection certificate, web category, application profile and logs. The map turns one vague symptom into ordered hypotheses.
For final review, mark each layer with its evidence: system/resource status, route/SD-WAN tables, policy hit/log, authentication monitor, SSL/web/app/AV/IPS log, VPN status/log and packet/debug capture. Knowing where evidence lives is as important as knowing where configuration lives.
Backup and firmware should be drawn on the change-control branch. A configuration backup provides rollback context, while firmware changes alter the platform itself. Upgrade verification should include policy, routing, VPN, HA and security-profile behavior after the appliance returns.
Logs should also be mapped by type. Traffic logs explain sessions and policy matches; event/system logs explain administrative or platform state; security logs explain web, application, antivirus or IPS actions. Choosing the correct log type reduces investigation time.
Conserve mode belongs on the resource-protection path because low memory can change normal session or inspection behavior. If many unrelated traffic flows fail during resource pressure, system health should be checked before rewriting multiple security policies.
LDAP/RADIUS and FSSO should be shown as different identity sources feeding policy. Interactive authentication verifies a user at access time; FSSO can learn identity from domain activity. The correct troubleshooting evidence differs accordingly.
FortiAnalyzer sits beside FortiGate logging rather than in the packet path. It enhances storage, search, reporting and centralized visibility. A FortiAnalyzer failure does not automatically mean firewall traffic forwarding is down, which is another example of separating planes.
HA failover should be drawn with session state and network convergence. A new active member can be healthy while upstream ARP/routing or unsynchronized sessions still affect users. End-to-end verification matters after the role change.
Use the map to distinguish “allowed but not working” scenarios. If policy permits traffic, the next suspects can be NAT, route, authentication mapping, security profile, VPN, remote application or return path. This layered thinking is the main value of the objective map.
The map should include firmware and configuration backup as recovery controls. A backup preserves known-good device state, while firmware changes affect platform behavior. Administrators should validate route, policy, VPN, HA and inspection after upgrades rather than assuming a successful reboot means full service.
Administrative authentication should sit apart from firewall-user authentication. A user signing into FortiGate management and a user being identified for a firewall policy are different trust paths, even if both eventually rely on LDAP or other identity services.
FortiGuard service reachability should connect licensing with inspection. Web categories, antivirus and IPS depend on current service information or signatures. Security-profile troubleshooting should therefore check both local profile settings and the platform’s ability to obtain/update relevant data.
Use the finished map to review blast radius. One user failing authentication suggests identity mapping; one published server failing suggests VIP/DNAT or return path; many sites blocked suggests web filtering/licensing; many flows failing during high memory suggests system resource pressure. Scope guides the first evidence source.
Finally, separate configuration intent from observed behavior. A route, policy, VIP, authentication rule or security profile can exist correctly in the GUI while traffic follows a different path because another rule, resource condition or dependency takes precedence. The exam’s troubleshooting emphasis rewards candidates who verify runtime evidence before editing configuration.
For final review, trace one packet through interface → route/SD-WAN → policy/NAT → authentication → inspection → VPN as applicable → logs. That is the working map behind the current Fortinet certification exam.