Hard Difficulty Questions

The session is a TCP session that has been active for 1 hour and will expire immediately

Why it fails: This option incorrectly interprets Expire=3599 as zero or near-zero, but the expire field is a countdown of seconds remaining, not a flag for immediate teardown. With 3599 seconds left, the session has about an hour of idle time before expiration. A session that expires immediately would show an expire value of 0 or a very small number, not 3599. The protocol is TCP (Proto=6), but the error lies in misreading the lifetime counter.

The session is a UDP session that has been idle for 3600 seconds

Why it fails: The session record clearly indicates Proto=6, which is TCP, so this cannot be a UDP session. UDP traffic is identified by IP protocol number 17, and UDP sessions generally use different idle timers than TCP sessions. The Duration and Expire values also reflect a long-lived connection, which would be atypical for UDP, especially on port 443 where UDP is used only for QUIC/HTTP/3, not the described state.

The session is an ICMP session with a short timeout

Why it fails: ICMP has its own IP protocol number (1) and does not use TCP port 443; this session is clearly TCP (Proto=6) with a destination port of 443. The session is also not short-lived — it has already been active for an hour (Duration=3600) and has another hour of timeout remaining (Expire=3599). Therefore, this is neither an ICMP session nor a short-timeout session.

The default route has a lower administrative distance than the PBR rule.

Why it fails: Administrative distance ranks routes within the routing table; policy routes are evaluated in the policy lookup before the routing table, so AD never overrides a matching PBR rule. AD comparison applies between competing static or dynamic routes. This would be correct if two ordinary routes to the same destination conflicted.

PBR is not supported on FortiGate.

Why it fails: FortiGate supports policy routes configured under Router > Static > Policy Routes, applied during policy lookup before destination-based routing. The claim is factually false, so it cannot explain the symptom. This would never be the answer; PBR is a documented FortiOS feature on supported models.

The PBR rule has a higher priority than the default route.

Why it fails: Higher priority means the PBR rule is evaluated earlier, which would steer traffic to ISP1, not leave it on ISP2. Priority ordering determines which policy route matches first. This would be correct if the question asked why PBR overrode the default route instead of being ignored.

diagnose user fsso poll user <username>

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

diagnose wad user list

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

diagnose test authserver ldap <server> <username>

Why it fails: This tests LDAP authentication, not FSSO status.

The session is using UDP protocol

Why it fails: The 'proto' field in the session listing displays the IP protocol number, and a value of 6 indicates TCP, not 17 (UDP). Because the session filter targets port 443, the output shows TCP sessions carrying TLS/HTTPS traffic; if this were UDP 443, used by QUIC/HTTP3, the proto value would be 17. The session's protocol is therefore TCP, making the UDP claim factually incorrect.

The session is blocked by the firewall policy

Why it fails: A firewall policy block prevents the creation of a session entry entirely — when a connection is denied, the FortiGate does not add it to the session table, so it would never appear in 'diagnose sys session' output. The presence of a session tuple in the table means the traffic was already permitted and is being tracked by the firewall. Thus, this observation cannot indicate a blocked session; it instead implies policy and inspection are active.

The session is in SYN-SENT state

Why it fails: The state shown in the session output uses symbolic or numeric flags, and '01' represents an established TCP connection, not SYN-SENT. A session in SYN-SENT would be a handshake stage with no bidirectional traffic, and Fortinet's session table typically retains only completed or ongoing sessions with full connection tracking. The displayed expiration and duration counters further confirm the session is actively established, not waiting for a SYN-ACK.

The session is blocked by the firewall

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

The session is using UDP protocol

Why it fails: proto=6 indicates TCP, not UDP.

The session is in a half-open state

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

The session is a UDP connection to port 443

Why it fails: The output's 'proto=6' field identifies this as a TCP session, not UDP. User Datagram Protocol is assigned protocol number 17, while TCP is protocol 6. Therefore the statement that it is a UDP connection is factually incorrect based on the protocol field shown in the session diagnostics.

The session will expire in 3600 seconds

Why it fails: The 'exp' (expire) field in FortiOS session output displays the remaining time until the session times out, and here it reads 3599 seconds, not 3600. The exact value may be one second less due to the time elapsed since the session was last refreshed. Thus the session will expire in 3599 seconds, not exactly 3600 as claimed.

The session has been established for 3600 seconds

Why it fails: The 'duration' field shows 3600 seconds since the session was first created, but that does not mean the connection is fully established. In this case, the TCP state is SYN_SENT (01), indicating only the initial SYN has been sent and no SYN-ACK received. A session that has been 'established' for 3600 seconds would typically be in state ESTABLISHED (02), so the statement misinterprets session age as established time.

Enable NAT on the policies to translate addresses between VLANs

Why it fails: 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 it fails: Transparent mode does not route; it bridges. So no routing needed.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Disable the anomaly and use a custom IPS signature

Why it fails: Disabling the anomaly removes the threshold-based detection that flags the 'tcp_syn_flood' anomaly, whereas the administrator specifically needs to reduce false positives while keeping detection active. A custom IPS signature detects known attack patterns, not volumetric anomalies, so it cannot adjust the sensitivity of the existing anomaly engine. This option is tempting because custom signatures are a standard method for fine-tuning detection of specific traffic patterns, and would be correct if the false positives stemmed from a particular application behaviour rather than a threshold sensitivity issue.

Decrease the threshold value

Why it fails: Decreasing the threshold value lowers the number of SYN packets per second that must be observed before the FortiGate flags a tcp_syn_flood anomaly. Since normal network activity often contains bursts of connection attempts, a lower threshold will more frequently treat legitimate traffic as an attack, increasing false positives. This is the opposite of the administrator's goal and would also increase CPU/alerting load, so it is not a workable remediation.

Set the action to 'pass'

Why it fails: Setting the anomaly action to 'pass' would make the FortiGate allow the anomaly-triggering traffic through without blocking, resetting, or quarantining the source. Although this would immediately stop the false positives from disrupting connectivity, it would also eliminate all protection against real SYN floods because the anomaly engine would only log events and never act on them. Since the administrator wants to preserve detection capability, this option sacrifices security rather than solving the threshold mismatch.

Enabling hardware acceleration for IPS processing.

Why it fails: Hardware acceleration offloads pattern matching to dedicated processors or the network processor unit, improving throughput and reducing latency under load. However, it does not alter the detection engine's classification logic or the signature parameters that determine a false positive. False positives are caused by traffic behavior and signature thresholds, not by the compute resources performing the inspection, so this is irrelevant to false-positive tuning.

Increasing the sensitivity of signatures to catch more attacks.

Why it fails: Raising sensitivity—such as lowering the threshold for anomaly detection or enabling stricter match flags—makes the IPS more permissive in what it flags as malicious. This inevitably increases the number of false positives because normal traffic variations are more likely to cross the lower bar. It is a coverage-vs-accuracy tradeoff and the opposite of a measure intended to reduce alert noise.

The remote FortiGate's Phase 1 proposal does not match

Why it fails: A Phase 1 proposal mismatch triggers an immediate NO_PROPOSAL_CHOSEN notify response from the remote FortiGate, which the initiator receives and logs as a negotiation failure. This is a deterministic, fast error, not a silent loss of traffic. The IKE debug would show the incoming notify message, and the tunnel would fail quickly rather than retransmitting until timeout. Therefore, a proposal mismatch cannot explain a timeout because the responder actively rejects the SA, so the negotiation terminates with a specific error, not silence.

The pre-shared key is incorrect

Why it fails: If the pre-shared key is incorrect, the remote FortiGate will still receive the IKE packet and attempt to authenticate the peer, but the calculated hash will not match. It then sends an IKE notify message indicating an authentication failure or hash mismatch, such as 'AUTHENTICATION_FAILED', which the initiator receives and logs. This is an explicit error response, not a timeout, because the responder is reachable and processing the negotiation. A PSK problem cannot cause a timeout since the peer replies with a failure notification rather than remaining silent.

The local FortiGate's external interface is down

Why it fails: When the local FortiGate's external interface is down, the kernel cannot route or transmit the IKE packets, so they are never sent onto the wire. The debug would immediately show a local error, such as a socket bind failure, route lookup failure, or 'no interface with a matching IP', instead of a timeout waiting for a remote response. Because the packet never leaves the FortiGate, there is no retransmission or timeout against a peer; the negotiation fails locally at the sending stage. Thus, this cause would not be observed as an IKE timeout and is therefore incorrect.

Use a publicly trusted CA certificate for the FortiGate

Why it fails: A publicly trusted CA cannot issue the on-demand certificates that deep inspection requires. When a client connects to any HTTPS site, the FortiGate must instantly generate a certificate for that specific domain, so it must act as its own CA. Using a public CA would require domain validation for every site before inspection, which is impractical and not supported. Therefore, this does not solve the root issue of establishing a trusted internal CA.

Disable deep inspection and use certificate inspection only

Why it fails: Certificate inspection only examines the server certificate header without decrypting the payload, so it cannot scan for malware or data leaks. Since no forged certificate is presented, clients would not see warnings, but this completely abandons the security visibility that deep inspection is meant to provide. The administrator configured deep inspection, so falling back to certificate inspection defeats the purpose and is not a valid solution.

Add the websites to the exemption list in the SSL/SSH profile

Why it fails: Adding websites to the exemption list in the SSL/SSH profile selectively disables deep inspection for those domains, typically because they use certificate pinning or require a real server certificate. This only suppresses warnings for the exempted sites; all other HTTPS traffic is still decrypted using the FortiGate's CA, so warnings persist. It is a targeted workaround, not a resolution for the widespread untrusted CA problem.

Replace the CA certificate with a self-signed one

Why it fails: Replacing the CA certificate with a self-signed certificate is ineffective because the FortiGate's CA is already self-signed and used to sign the dynamically generated certificates presented to clients. The error stems from the fact that the internal server's original certificate is not signed by the FortiGate CA, so the client does not see the trusted internal PKI chain. Simply swapping the CA does not address the trust relationship between the client and the internal certificate.

Use certificate inspection instead of deep inspection

Why it fails: Certificate inspection only evaluates metadata of the server certificate and forwards the original certificate untouched, so no re-signed certificate is presented to the client and no trust error occurs. However, because the traffic is not decrypted, the firewall cannot inspect the HTTP payload for malware, data exfiltration, or application-level rules. This bypasses the symptom but sacrifices the security benefits that deep inspection is intended to provide, making it an inadequate solution if full visibility is required.

Disable certificate validation in the deep inspection profile

Why it fails: Disabling certificate validation inside the deep inspection profile makes FortiGate skip checks such as expired certificates, hostname mismatch, and untrusted server chains during the handshake, which can suppress some server-side errors. Yet the client still receives a certificate re-signed by the FortiGate CA, so the client will reject it unless the FortiGate CA is installed in its trust store. Therefore, this option neither restores trust nor resolves the exact error, and it additionally weakens overall security posture by accepting invalid certificates.

Deep inspection can still see client certificates

Why it fails: Client certificates are exchanged inside the TLS handshake only after the encrypted channel is established, and certificate inspection passively observes the server certificate without terminating the TLS session. Therefore, any client certificate remains encrypted and invisible to the FortiGate; deep inspection would be required to intercept it, but the scenario here is certificate inspection, not deep inspection.

The antivirus profile can scan the HTTPS payload

Why it fails: With certificate inspection, the FortiGate never decrypts the HTTPS stream, so the Antivirus profile has no plaintext HTTP payload to scan. The AV engine can only match patterns after decryption, and without a TLS proxy that decrypts and re-encrypts for both endpoints, the encrypted data is simply opaque ciphertext that cannot be inspected.

IPS can still inspect the application layer of HTTPS traffic

Why it fails: IPS engines must inspect the decoded application-layer protocol stream to match exploit signatures, but certificate inspection leaves the HTTPS payload fully encrypted between client and server. In this mode the IPS can see only TLS metadata and the server certificate, so it cannot identify attack patterns embedded in encrypted HTTP request or response bodies.

The server's HTTPS service is not running

Why it fails: Because HTTP users can successfully reach the server, the server is up and the network path from the firewall to the server is functional. An HTTPS service failure would prevent the server from responding, but the traffic would still be forwarded and appear in server logs; here the issue is that the packets are being blocked at the firewall, indicating a policy or NAT problem rather than a server-side issue.

VIPs cannot share the same public IP address

Why it fails: FortiGate supports multiple VIPs that share the same public IP address as long as their public ports or protocols differ. For example, a VIP for HTTP on port 80 and another for HTTPS on port 443 can both map to different internal servers on the same public IP. Thus, sharing a public IP is not a misconfiguration and cannot cause HTTPS to fail.

The HTTPS VIP is configured with the wrong internal port

Why it fails: If the HTTPS VIP's mapped internal port were wrong, such as mapping public 443 to internal 8080 while the server listens on 443, traffic would still pass through the firewall and reach the server, where the connection would be reset or refused. This would generate an active session and a different failure pattern (e.g., handshake timeout) compared to HTTPS being completely unreachable, which indicates the policy is dropping the traffic before any connection is attempted.

Add the client's assigned IP to a local user group

Why it fails: Local user groups are designed for authentication and authorization, not for traffic matching in firewall policies. The client's dynamically assigned tunnel IP is not a group membership attribute, and FortiGate does not evaluate group membership when performing interface-based policy checks. While group membership can affect SSL VPN portal or realm selection, it has no bearing on the policy's source interface matching for post-authentication traffic.

Configure a static route on the FortiGate for the client's tunnel IP

Why it fails: A static route for the client's tunnel IP is unnecessary because the FortiGate automatically installs a host route to each SSL VPN client's assigned IP via the ssl.root interface when the tunnel comes up. This dynamic route is managed by the SSL VPN daemon and already directs return traffic correctly. Adding a static route would either conflict with the existing dynamic route or be redundant, and it does not resolve a firewall policy interface mismatch.

Enable split tunneling on the SSL VPN portal

Why it fails: Split tunneling controls which destination networks the client sends through the encrypted tunnel versus directly out its local internet connection. This setting modifies the client-side routing table, not the FortiGate's policy matching, and it does not affect the incoming interface on which tunneled traffic arrives. Even when split tunneling is enabled, the traffic that is tunneled still arrives on the ssl.root interface and still requires the firewall policy to have that interface configured as the source.

The regular expression is case-sensitive and credit card numbers are lowercase

Why it fails: Credit card numbers are composed entirely of numeric digits, so regular expression case sensitivity is irrelevant. A regex like \d{13,16} will match regardless of letter case, and no valid credit card contains lowercase or uppercase letters. Therefore, a case sensitivity setting cannot explain the complete failure to trigger DLP detection in this scenario.

The DLP sensor is configured to 'monitor' only

Why it fails: In 'monitor' mode, the FortiGate still performs full DLP inspection and logs each match, though it does not quarantine or block the email. If the DLP sensor had actually matched credit card numbers, those matches would appear in the DLP logs. Since no triggering at all is observed, the monitor-vs-block setting is not the root cause; the issue lies elsewhere.

The DLP profile is applied to the inbound policy only

Why it fails: Applying the DLP profile to the inbound policy only means it inspects emails arriving from external senders, which would still detect credit card numbers in plaintext SMTP traffic. However, when the email is sent over TLS, the inbound inspection still sees only encrypted content, so the direction of the policy does not help. This option incorrectly points to direction as the cause, while the real problem is the lack of decryption.