Hard Difficulty Questions

Set the Antivirus profile to 'Deep Inspection'

Why wrong: Antivirus profiles on FortiGate don't have a 'Deep Inspection' mode as such; they have 'Inspection Mode' options like 'Proxy-based' or 'Flow-based' but that's not the same as SSL deep inspection. The actual deep inspection feature is enabled on the firewall policy (or a separate SSL/SSH inspection profile) and applies to the protocol-level decryption. Antivirus profiles work with the decrypted traffic but don't control whether traffic is decrypted.

Upload the server's certificate to the FortiGate

Why wrong: In standard SSL deep inspection (not full certificate authentication), the FortiGate does not need the server's private key; it dynamically generates a new certificate signed by its own CA for each site. Uploading the server's certificate is not required because the FortiGate is not impersonating the server with the original certificate; it creates a new one on the fly. Even if you upload it, it would not help the firewall decrypt traffic without the private key, and the purpose is to inspect, not to use the original cert.

diagnose user fsso poll user <username>

Why wrong: There is no such command. The correct command is 'diagnose debug authd fsso list'.

diagnose wad user list

Why wrong: This command shows web proxy users, not necessarily FSSO.

diagnose test authserver ldap <server> <username>

Why wrong: This tests LDAP authentication, not FSSO status.

The secondary unit does not support policy routes

Why wrong: The claim that the secondary unit does not support policy routes is incorrect. FortiGate policy routing is a core feature available on every HA member regardless of its active or passive role. In an active-passive cluster, the standby unit runs the same FortiGate operating system and holds the same configuration, so when it assumes the primary role it can enforce policy routes identically to the previous primary.

The policy route configuration is not synchronized in HA

Why wrong: In a FortiGate HA cluster, configuration synchronization is continuous and comprehensive, so policy routes are definitely synced to the secondary unit. The failure is not due to missing configuration but to a runtime dependency that the synced configuration cannot satisfy on the new primary. If anything, the policy route exists in the config but cannot be applied because of interface availability.

The HA cluster requires a reboot after failover

Why wrong: HA failover in FortiGate is designed to be seamless and does not require any reboot of the cluster or the devices. The standby unit continuously receives heartbeat signals and is fully initialized with the current configuration and synchronized sessions; on failure, it simply transitions to active state. Rebooting would defeat the purpose of high availability and cause unnecessary downtime, so it is never a normal failover step.

The IPS signature database is corrupted

Why wrong: Anomaly detection in FortiOS does not rely on the IPS signature database; it uses protocol decoders and heuristics to identify abnormal traffic behaviors such as excessive sessions, port scans, or source IP spoofing. A corrupted signature database would typically produce signature load errors or prevent pattern-matching updates, but it would not generate specific anomaly list entries. Therefore, this output indicates a heuristic-based anomaly event, not a database integrity problem.

The FortiGate has a hardware failure

Why wrong: A hardware failure on a FortiGate would manifest as crashes, interface flaps, power supply faults, or CPU/memory hardware watchdog alarms, not as a list of detected network anomalies. The `diagnose ips anomaly list` command reports active IPS anomaly detection events, which are derived from traffic analysis and pattern heuristics, not from the hardware health of the device. Thus, the presence of anomaly entries is unrelated to physical hardware status.

The FortiGate is under a DDoS attack

Why wrong: A DDoS attack is typically distributed, involving many source IPs targeting a single victim, while the anomaly list entry described indicates a single source generating excessive outbound sessions. Although a volumetric attack might trigger some anomalies, the specific pattern of one host with many connections is more indicative of malware, not a distributed denial-of-service. The anomaly list focuses on per-source behavioral violations, not aggregate flood detection.

Enable NAT on the policies to translate addresses between VLANs

Why wrong: NAT is not typically used in transparent mode for inter-VLAN traffic; it would be layer 2 forwarding.

Configure static routes to route between VLANs

Why wrong: Transparent mode does not route; it bridges. So no routing needed.

The FortiGate was in HA mode and the peer did not upgrade

Why wrong: In HA, the upgrade process is different; the unit would typically not revert unless there was an issue with the image.

The admin did not reboot after the upgrade

Why wrong: The upgrade process automatically reboots.

The admin forgot to save the configuration before upgrading

Why wrong: Configuration save is not required for firmware upgrade; the upgrade process itself saves config.

The FortiGate's physical port is not set to the same VLAN ID

Why wrong: The physical port is not assigned a VLAN ID; the VLAN interface is.

The FortiGate's administrative access is not enabled on the VLAN interface

Why wrong: Administrative access (ping) may be needed, but the primary issue is tagging.

The FortiGate's VLAN interface is not assigned to any VDOM

Why wrong: VDOM assignment is necessary but usually defaults to root; tagging is the immediate issue.

Add a static route for 192.168.1.0/24 with next-hop 203.0.113.1

Why wrong: Static routes do not affect NAT translation.

Set the administrative access to HTTPS on port1

Why wrong: Administrative access does not affect NAT.

Create a central NAT rule with source 192.168.1.0/24 and IP pool 203.0.113.2-203.0.113.10

Why wrong: This uses a pool, not the interface IP.

The heartbeat interface is configured as a dedicated management interface

Why wrong: Dedicating the heartbeat interface to management traffic is not the root cause of session drops during failover. The heartbeat link is responsible for cluster control messages and session synchronization payload between HA members; when it also carries management traffic, it can suffer congestion or increased latency, but that would impair the cluster's ability to sync state, not directly zero out the session table. Session loss on failover is specifically a consequence of disabled session pickup, not of sharing the heartbeat link.

The cluster is operating in NAT mode

Why wrong: Whether the cluster runs in NAT mode or transparent mode does not determine session persistence across failover. FortiOS HA supports session-pickup in both operating modes, so a properly synchronized NAT-mode cluster will maintain sessions identically to a transparent-mode cluster. Therefore, selecting NAT mode as the cause confuses a deployment parameter with the actual state-synchronization mechanism.

The cluster is using a virtual MAC address for the HA interface

Why wrong: Using a virtual MAC address for the HA interface is a standard failover optimization that prevents ARP table staleness by updating the switch's forwarding table immediately when the active unit changes. While this improves network-level convergence, it does not affect the session state information that lives in the FortiGate's session table. Sessions are lost only if that table wasn't mirrored to the new primary, so virtual MAC is irrelevant to session-drop behavior.

Both units must have the same firmware version and license

Why wrong: Firmware should match, but license differences do not prevent config sync.

The HA cluster must be configured with a virtual MAC address

Why wrong: Virtual MAC is optional and not required for config sync.

VDOM mode must be enabled on both units

Why wrong: VDOM mode is not required for HA config sync.

The firewall policy is disabled

Why wrong: If the firewall policy were disabled, it would be visually marked as disabled in the GUI or show 'disable' in the CLI configuration, and it would be completely excluded from the policy lookup process. However, the question describes a policy that is present and likely enabled but ineffective, which points to a matching/ordering problem rather than a disabled state. Even if policy ID 10 were enabled, it cannot influence traffic that already matched and was acted upon by policy ID 1. The admin would need to check the policy's enabled status, but the root cause here is not the disabled state but the evaluation order.

The service object for HTTPS is misconfigured in policy ID 10

Why wrong: A misconfigured HTTPS service object in policy ID 10 could cause that policy to fail to match inbound HTTPS traffic, but that would only matter if the traffic actually reached policy ID 10 for evaluation. In this scenario, policy ID 1 matches the traffic first and is applied, so the service object in policy ID 10 is never examined. Even if the service object were corrected, the traffic would still match policy ID 1 and policy ID 10 would continue to be bypassed. Thus, the misconfiguration is irrelevant to the current symptom because the policy is shadowed by a higher-priority rule.

The destination address is incorrect in policy ID 10

Why wrong: An incorrect destination address in policy ID 10 would prevent it from matching the intended traffic, but this issue would only be observed if the traffic were evaluated against policy ID 10. Since policy ID 1 is evaluated first and matches the incoming HTTP session, policy ID 10 is never reached, regardless of whether its destination address is correct or not. Even if the destination address were corrected, policy ID 10 would still not get a chance to handle the traffic because the lookup already terminated at policy ID 1. Therefore, the destination address misconfiguration is not the cause of the admin's observation; the ordering is the true culprit.

Create static routes for each VLAN subnet

Why wrong: No routing is performed in transparent mode.

Disable antivirus inspection on the policy

Why wrong: Antivirus can be used in transparent mode.

Assign IP addresses to the internal interfaces

Why wrong: In transparent mode, interfaces are not routable; they are part of the bridge.

The session is blocked by the firewall

Why wrong: The output shows an active session, not blocked.

The session is using UDP protocol

Why wrong: proto=6 indicates TCP, not UDP.

The session is in a half-open state

Why wrong: proto_state=01 typically indicates an established session, not half-open.

The FortiGate decrypts the traffic but does not re-sign, causing mismatch errors.

Why wrong: Certificate-inspection does not decrypt traffic.

The FortiGate blocks the connection because certificate-inspection cannot handle deep inspection profiles.

Why wrong: Certificate-inspection works with SSL profiles, but the error is not caused by this mismatch.

The user will see a warning about the certificate but will be able to proceed after accepting it.

Why wrong: With certificate-inspection, FortiGate does not re-sign certificates; it only validates them.

Both translations will be applied, causing an error

Why wrong: Policy-based NAT and Central SNAT do not stack. FortiGate selects a single source translation at session establishment; once a policy-based NAT rule matches the traffic, that translation is committed to the session table and the Central NAT lookup is never performed. The device does not generate an error from having both configured — the dispute is resolved by evaluation order rather than by applying both translations.

Central SNAT because it is a global setting

Why wrong: A 'global' Central NAT rule only fills the gap left when no policy-based NAT rule applies. Policy-based NAT is more specific because it is tied to an exact source/destination/service match in a firewall policy, so it takes precedence over the blanket Central SNAT rule. Central SNAT will be used only if the traffic is not matched by any policy-based NAT rule.

The FortiGate will use the translation from the policy with the highest ID

Why wrong: Policy ID is irrelevant when comparing policy-based NAT to Central NAT because the two NAT mechanisms are evaluated in separate phases. FortiGate first checks policy-based NAT rules for a match, and only if none match does it consult the Central SNAT table. Among multiple matching policy-based NAT rules, policy ID order might decide, but it cannot change the precedence between policy-based NAT and central NAT.

The central SNAT rule is disabled

Why wrong: The central SNAT rule being disabled is not the root cause because precedence is determined by the NAT type configured on the policy, not by the enabled state of a central SNAT object. Even if the central SNAT rule were enabled, a policy with policy-based NAT (e.g., an IP pool assigned directly in the policy) will still take effect first. Disabling the central rule would only matter if no policy-based NAT existed, but here the policy explicitly defines its own NAT behavior.

The policy is using fixed port range

Why wrong: A fixed port range does not influence which NAT mechanism is chosen; it only restricts the range of source ports used when an IP pool is applied for allocation. The policy either selects policy-based NAT or relies on central SNAT regardless of how ports are managed. In this scenario, the fixed port range is simply a property of the policy's NAT settings and does not cause central SNAT to be ignored—the presence of an explicit per-policy NAT configuration is what overrides the central rule.

The IP pool is out of addresses

Why wrong: Exhaustion of IP pool addresses would cause new sessions to fail address allocation, typically generating error logs or dropped packets, not silently reverting to the interface IP. Such a failure would occur after the policy has already selected the pool, meaning central SNAT never comes into play. Since the policy explicitly uses the pool, running out of addresses does not trigger a fallback to central SNAT or the interface IP; it simply breaks connectivity.

The user's IP address must be in the destination address range of the policy

Why wrong: The user's IP must match the SOURCE address of the policy, not the destination. In an FSSO policy, the firewall identifies the user by their source IP address, which is mapped to a logged-in user via the FSSO collector. The destination address defines the server or network being accessed, so the user's IP is never compared to the destination range.

The user must be authenticated to the FortiGate locally

Why wrong: FSSO is explicitly designed to leverage Windows Active Directory authentication; the user's credentials are validated by the domain controller when they log in to the domain. The FortiGate does not perform local authentication or ask for a password; it simply trusts the mapping supplied by the FSSO collector. Local authentication would require a different user store and is not part of FSSO.

The Phase 2 proposal uses AES256 but the remote client only supports AES128

Why wrong: If the Phase 2 proposal were mismatched, the IPsec SA negotiation would fail and the tunnel would not come up at all. Since the tunnel is established and the problem is that user traffic is not passing, the proposals must have been successfully negotiated with matching cipher and integrity algorithms. Therefore, a mismatch in AES key lengths cannot be the cause of post-negotiation traffic loss.

The FortiGate's routing table does not have a route to the remote user's subnet

Why wrong: In a dial-up VPN scenario, the remote user's IP address is dynamically assigned, so the FortiGate typically relies on a static route pointing toward the dial-up tunnel interface or a per-user host route learned from IKE. If the FortiGate lacked such a route, return packets from the destination network could not be sent back, but the symptom of no sessions suggests the initial forward packets are being dropped before any session creation. Missing routes usually manifest as asymmetric routing or ICMP unreachable messages, not a clean absence of sessions when a policy drop is the culprit.

The remote user's FortiClient is blocking split tunneling

Why wrong: Split tunneling controls which destination networks the FortiClient routes directly vs. through the IPsec tunnel; blocking it would force all client traffic into the tunnel, not prevent it from doing so. If split tunneling were disabled, we would expect to see more sessions and traffic hitting the FortiGate's tunnel interface, yet the session table shows no traffic at all. The absence of any sessions indicates the packets are not reaching the FortiGate or are being explicitly dropped by policy rather than being influenced by client-side routing decisions.

The inter-VDOM link is down

Why wrong: If the inter-VDOM link were down, the FortiGate would not be able to forward any frames between VDOMs, so even the initial forward traffic from VDOM A would fail. Since the administrator indicates that forward traffic is working, the link must be operationally up. Inter-VDOM link status is a Layer 1/2 connectivity issue, not a policy or stateful firewall issue, and it cannot selectively block only return packets.

The session helper is not configured for the application

Why wrong: Session helpers are protocol-specific plugins that dynamically open data channels for protocols like FTP or SIP, not generic TCP/UDP flows. The FortiGate tracks established sessions using the 5-tuple, and any return packet matching an existing session is allowed regardless of helpers. Without a helper, the control session still functions; the observed drop of return traffic is caused by the lack of an explicit allow policy in VDOM B, not by missing helper configuration.

A firewall policy is missing in VDOM B to allow return traffic

Why wrong: Inter-VDOM communication in FortiOS requires independent security policies in both VDOMs: VDOM A needs a policy to send packets across the inter-VDOM link, and VDOM B needs a policy to accept those packets and to allow the corresponding return traffic. Without a matching policy in VDOM B, the FortiGate evaluates the return packets and finds no permit rule, dropping them and causing one-way or partial session establishment. This is a common misconfiguration when administrators focus on the initiating VDOM and forget the peer VDOM's policy table.

The member ports are set to different speeds

Why wrong: The FortiGate allows member ports with different link speeds in the same aggregate interface, and the bundle will operate at the speed of the slowest member. This configuration affects throughput but does not prevent the aggregate from coming up, because the physical link is still active and LACP negotiation can still complete. Therefore, a speed mismatch between members is not the reason the interface is down.

The aggregate interface IP address is in the same subnet as the management interface

Why wrong: Assigning an IP address to the aggregate interface that overlaps the subnet of the management interface creates a routing and ARP conflict, not a link-state problem. The aggregate interface can still reach the up state and forward traffic based on the routing table, but traffic destined to addresses in the overlapping subnet may be sent to the wrong interface. Consequently, this does not explain why the aggregate link is down.

The FortiGate needs a reboot after creating an aggregate interface

Why wrong: FortiGate applies aggregate interface configuration at runtime, so creating an aggregate and adding member ports does not require a reboot. The physical links and the aggregate bundle initialize immediately when the configuration changes are committed, regardless of whether the switch peer is correctly configured. Rebooting the FortiGate would not help and could actually mask the real issue of missing switch-side aggregation.