Scenario practice questions

An administrator configures FSSO (Fortinet Single Sign-On) with Active Directory polling. Users report that their web traffic is being blocked by the firewall even though they are logged into the domain. Which CLI command can the administrator use to verify the FSSO login status for a specific user?

Trap 1: diagnose user fsso poll user <username>

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

Trap 2: diagnose wad user list

This command shows web proxy users, not necessarily FSSO.

Trap 3: diagnose test authserver ldap <server> <username>

This tests LDAP authentication, not FSSO status.

A
diagnose user fsso poll user <username>
Why wrong: There is no such command. The correct command is 'diagnose debug authd fsso list'.
B
diagnose wad user list
Why wrong: This command shows web proxy users, not necessarily FSSO.
C
diagnose debug authd fsso list
Correct. This command lists all FSSO users with their IP addresses and group memberships.
D
diagnose test authserver ldap <server> <username>
Why wrong: This tests LDAP authentication, not FSSO status.

Question 2mediummultiple choice

A network administrator notices that HTTP traffic to a specific website is being blocked by the web filter profile, but the website is categorized as 'General – Personal' in FortiGuard, which is allowed. What could cause this block?

Trap 1: The web filter profile has an incorrect FortiGuard category override

A FortiGuard category override changes the action for an entire category, not for a single website. If the website's category is permitted by default and the override is not explicitly set to block, it cannot be responsible for blocking that URL. Moreover, any category-based override would affect all sites in that category, not a single specific website, which contradicts the symptom described.

Trap 2: The antivirus profile is blocking the website

Antivirus profiles in FortiOS inspect file content and block malware downloads, not individual websites by URL or domain. The AV engine cannot make an allow/block decision based on the requested hostname; it only acts after data reaches the FortiGate. If the site simply served HTML, the AV profile would have no basis to block the HTTP request itself, so this is not a plausible cause.

Trap 3: DNS filter is blocking the domain

A DNS filter blocks domains by intercepting DNS queries and dropping the resolution, so the client receives no IP address and the HTTP request never reaches the FortiGate's web filter. If the DNS filter were blocking the domain, the user would see a DNS resolution failure rather than a web-filter block page. The fact that the issue is observed in HTTP traffic to a specific site suggests that the request was successfully routed to the web filter, ruling out DNS filtering as the cause.

A
The web filter profile has an incorrect FortiGuard category override
Why wrong: A FortiGuard category override changes the action for an entire category, not for a single website. If the website's category is permitted by default and the override is not explicitly set to block, it cannot be responsible for blocking that URL. Moreover, any category-based override would affect all sites in that category, not a single specific website, which contradicts the symptom described.
B
The antivirus profile is blocking the website
Why wrong: Antivirus profiles in FortiOS inspect file content and block malware downloads, not individual websites by URL or domain. The AV engine cannot make an allow/block decision based on the requested hostname; it only acts after data reaches the FortiGate. If the site simply served HTML, the AV profile would have no basis to block the HTTP request itself, so this is not a plausible cause.
C
A URL filter entry is blocking the specific website
URL filter entries are local, rule-based patterns evaluated before FortiGuard category lookup. If a block entry matches the specific domain or URL, the session is dropped immediately, regardless of the category's default action. This is why a single website can be blocked while other sites in the same FortiGuard category remain accessible, as described in the scenario.
D
DNS filter is blocking the domain
Why wrong: A DNS filter blocks domains by intercepting DNS queries and dropping the resolution, so the client receives no IP address and the HTTP request never reaches the FortiGate's web filter. If the DNS filter were blocking the domain, the user would see a DNS resolution failure rather than a web-filter block page. The fact that the issue is observed in HTTP traffic to a specific site suggests that the request was successfully routed to the web filter, ruling out DNS filtering as the cause.

Read the full NAT/PAT explanation →

Question 3mediummultiple choice

A FortiGate administrator needs to create a firewall policy that allows traffic from the internal network (10.0.0.0/8) to a public web server (203.0.113.10) on port 443. The policy must also perform source NAT using the FortiGate's external IP (198.51.100.1). Which NAT configuration should be applied?

Trap 1: Create an IP pool with the external IP and reference it in the…

An IP pool is a source NAT object that lets you translate the source address of outbound traffic to a specific IP or range other than the egress interface's own address. In this scenario, the FortiGate's outgoing interface already has the public IP 198.51.100.1, and no requirement exists to use a different or additional source IP, so creating an IP pool adds unnecessary complexity. Without a pool, enabling NAT on the policy will automatically use the interface IP, which fully satisfies the requirement.

Trap 2: Create a VIP for the web server and reference it in the firewall…

A Virtual IP (VIP) is used for destination NAT, translating an incoming packet's destination address from a public IP to a private internal server, such as a web server backend. It does not affect the source address of outbound packets, so it cannot perform the source NAT required in this policy. Since the scenario involves outbound traffic (implied by the need for source NAT), referencing a VIP would misapply a DNAT object and fail to achieve the intended translation.

Trap 3: Configure Central SNAT and a matching rule

Configuring Central SNAT would manage source NAT rules in a dedicated table, separate from the firewall policy itself. This approach fails the scenario because the question asks for the NAT configuration *applied to the policy*, implying policy-based NAT where the NAT action is defined directly within the firewall rule. Central SNAT is tempting as it performs source NAT, and it is the correct choice when an administrator prefers a centralised, ordered list of NAT rules, independent of individual firewall policies, for consistent management across multiple rules.

A
Create an IP pool with the external IP and reference it in the firewall policy
Why wrong: An IP pool is a source NAT object that lets you translate the source address of outbound traffic to a specific IP or range other than the egress interface's own address. In this scenario, the FortiGate's outgoing interface already has the public IP 198.51.100.1, and no requirement exists to use a different or additional source IP, so creating an IP pool adds unnecessary complexity. Without a pool, enabling NAT on the policy will automatically use the interface IP, which fully satisfies the requirement.
B
Enable NAT on the firewall policy without specifying an IP pool
When you enable NAT on a firewall policy and leave the IP pool field blank, FortiOS performs source NAT using the primary IP address of the egress interface—here, 198.51.100.1. This is the simplest and most common method for enabling internet access from a private network, as it requires no separate NAT objects or additional configuration. The NAT action is directly part of the policy, exactly matching the scenario's request to apply NAT to the policy itself.
C
Create a VIP for the web server and reference it in the firewall policy
Why wrong: A Virtual IP (VIP) is used for destination NAT, translating an incoming packet's destination address from a public IP to a private internal server, such as a web server backend. It does not affect the source address of outbound packets, so it cannot perform the source NAT required in this policy. Since the scenario involves outbound traffic (implied by the need for source NAT), referencing a VIP would misapply a DNAT object and fail to achieve the intended translation.
D
Configure Central SNAT and a matching rule
Why wrong: Configuring Central SNAT would manage source NAT rules in a dedicated table, separate from the firewall policy itself. This approach fails the scenario because the question asks for the NAT configuration *applied to the policy*, implying policy-based NAT where the NAT action is defined directly within the firewall rule. Central SNAT is tempting as it performs source NAT, and it is the correct choice when an administrator prefers a centralised, ordered list of NAT rules, independent of individual firewall policies, for consistent management across multiple rules.

Question 4hardmultiple choice

An organization has a FortiGate with two internet connections (WAN1 and WAN2). They want traffic to a specific web service (203.0.113.50 port 443) to always exit via WAN2. All other internet traffic should use WAN1. Which feature should be used to achieve this?

Trap 1: Central NAT policy to force the traffic out of WAN2

Central NAT only handles NAT, not routing decisions.

Trap 2: Static route with a higher priority for WAN2 to 203.0.113.0/24

A static route would affect all traffic to that subnet, but the requirement is for a specific service only.

Trap 3: SD-WAN with a strategy of 'Best Quality'

SD-WAN could achieve this, but the question asks for a feature; PBR is more direct.

A
Central NAT policy to force the traffic out of WAN2
Why wrong: Central NAT only handles NAT, not routing decisions.
B
Static route with a higher priority for WAN2 to 203.0.113.0/24
Why wrong: A static route would affect all traffic to that subnet, but the requirement is for a specific service only.
C
SD-WAN with a strategy of 'Best Quality'
Why wrong: SD-WAN could achieve this, but the question asks for a feature; PBR is more direct.
D
Policy-based routing (PBR) configured with a policy matching the destination and service
PBR allows routing decisions based on firewall policy criteria.

Question 5hardmultiple choice

An admin configures a VIP to map a public IP to an internal server. The firewall policy uses the VIP as the destination. External users can access the server, but the server's logs show the source IP as the FortiGate's internal interface IP instead of the original client IP. Why is this happening?

Trap 1: The VIP is configured with port forwarding and the server is…

Port forwarding on the VIP controls destination address and port translation, leaving the source IP untouched. If the internal server expects a different port, the firewall would translate the destination port accordingly, but the source address would still reflect the original client or the FortiGate's egress IP depending on policy NAT. Thus, port mismatch explains connection failures, not the altered source IP observed by the server.

Trap 2: The VIP is using a different public IP than expected

This option contradicts the scenario's premise, since external users can successfully reach the server through the configured public IP. If the VIP were bound to a different public IP, the expected destination would not be reachable, and the traffic would never arrive at the server. Even if the VIP had an incorrect IP, it would not cause source address rewriting; source IP modification is governed solely by the firewall policy's NAT settings.

Trap 3: The server's routing is misconfigured and traffic is returning via…

Asymmetric routing occurs when reply traffic returns via a different path, which can cause state timeouts or dropped packets but does not alter the source IP recorded on incoming packets. If NAT were disabled, the server would still see the client's original IP even with misconfigured routing, because routing decisions don't modify the source address field. The observed source IP change is a direct result of policy NAT, not a routing anomaly.

A
The VIP is configured with port forwarding and the server is expecting a different port
Why wrong: Port forwarding on the VIP controls destination address and port translation, leaving the source IP untouched. If the internal server expects a different port, the firewall would translate the destination port accordingly, but the source address would still reflect the original client or the FortiGate's egress IP depending on policy NAT. Thus, port mismatch explains connection failures, not the altered source IP observed by the server.
B
The VIP is using a different public IP than expected
Why wrong: This option contradicts the scenario's premise, since external users can successfully reach the server through the configured public IP. If the VIP were bound to a different public IP, the expected destination would not be reachable, and the traffic would never arrive at the server. Even if the VIP had an incorrect IP, it would not cause source address rewriting; source IP modification is governed solely by the firewall policy's NAT settings.
C
The firewall policy has NAT enabled, which changes the source IP to the FortiGate's egress interface IP
When the firewall policy matching the VIP traffic has NAT enabled, FortiGate replaces the original source IP with the IP of the egress interface used to forward the packet. This source NAT (SNAT) hides the client's real address, so the internal server logs show the FortiGate's interface IP as the connection source. This is the standard behavior, explaining why the admin observes the FortiGate IP instead of the client's public IP.
D
The server's routing is misconfigured and traffic is returning via a different path
Why wrong: Asymmetric routing occurs when reply traffic returns via a different path, which can cause state timeouts or dropped packets but does not alter the source IP recorded on incoming packets. If NAT were disabled, the server would still see the client's original IP even with misconfigured routing, because routing decisions don't modify the source address field. The observed source IP change is a direct result of policy NAT, not a routing anomaly.

Read the full NAT/PAT explanation →

Question 6hardmultiple choice

An admin is configuring a policy-based NAT rule (central NAT) to translate internal users' source IPs to the external IP of the FortiGate interface. However, users complain that some applications fail. The admin notices that the NAT rule is using 'dynamic IP pool' with overload. What is the MOST likely cause of the application failures?

Trap 1: The IP pool is exhausted and no more translations are available

The IP pool being exhausted would cause all new outbound connection attempts to fail, not just those from a particular application, and it would affect any destination. Even with overload (PAT), the limiting factor is frequently the range of source ports, not the number of IP addresses; however, a single app like SIP or FTP would not be singled out by an exhausted pool. Hence, this is not a valid explanation for an application-specific NAT requirement.

Trap 2: The route to the destination is missing

A missing route to the destination would prevent the firewall from even sending a packet toward the target, resulting in a total connectivity failure for every session, not selective application breakage. NAT and routing are independent layers; a policy-based NAT rule cannot compensate for a routing blackhole. Therefore, this would not explain why only certain applications require a fixed port range.

Trap 3: The firewall policy does not have NAT enabled

In FortiOS central NAT mode, translation is controlled by separate NAT policy rules, and the 'NAT' toggle on the firewall policy is not used; it is irrelevant to the translation process. If the firewall policy does not have NAT enabled, it does not mean central NAT is disabled—the central NAT policy still applies. Therefore, this is not a reason to think policy-based NAT is needed; the NAT configuration is already independent.

A
The IP pool is exhausted and no more translations are available
Why wrong: The IP pool being exhausted would cause all new outbound connection attempts to fail, not just those from a particular application, and it would affect any destination. Even with overload (PAT), the limiting factor is frequently the range of source ports, not the number of IP addresses; however, a single app like SIP or FTP would not be singled out by an exhausted pool. Hence, this is not a valid explanation for an application-specific NAT requirement.
B
The route to the destination is missing
Why wrong: A missing route to the destination would prevent the firewall from even sending a packet toward the target, resulting in a total connectivity failure for every session, not selective application breakage. NAT and routing are independent layers; a policy-based NAT rule cannot compensate for a routing blackhole. Therefore, this would not explain why only certain applications require a fixed port range.
C
The applications are sensitive to NAT and require a fixed port range
Several application-layer protocols, including SIP and FTP, embed IP addresses and TCP/UDP port numbers inside the payload. When overload NAT (PAT) dynamically assigns a different source port for each translation, the embedded port may no longer match the actual translated port, causing the peer to reject the session. A policy-based central NAT rule can be configured with a fixed port range or static port mapping, ensuring that the translated source port always matches what the application advertises. This is why application sensitivity is the correct reason for setting up such a NAT rule.
D
The firewall policy does not have NAT enabled
Why wrong: In FortiOS central NAT mode, translation is controlled by separate NAT policy rules, and the 'NAT' toggle on the firewall policy is not used; it is irrelevant to the translation process. If the firewall policy does not have NAT enabled, it does not mean central NAT is disabled—the central NAT policy still applies. Therefore, this is not a reason to think policy-based NAT is needed; the NAT configuration is already independent.

Read the full VPN explanation →

Question 7easymultiple choice

Which IPsec VPN mode is typically used when the VPN peer has a dynamic public IP address?

Trap 1: Quick mode

Quick mode is Phase 2 of IKE, not an IKE version mode.

Trap 2: IKEv2

IKEv2 has no main vs aggressive mode distinction; it uses a different mechanism for dynamic IPs.

Trap 3: Main mode

Main mode requires the responder to have the initiator's IP predefined, not suitable for dynamic IPs.

A
Quick mode
Why wrong: Quick mode is Phase 2 of IKE, not an IKE version mode.
B
IKEv2
Why wrong: IKEv2 has no main vs aggressive mode distinction; it uses a different mechanism for dynamic IPs.
C
Aggressive mode
Correct. Aggressive mode is used for peers with dynamic IPs because it can authenticate without prior IP knowledge.
D
Main mode
Why wrong: Main mode requires the responder to have the initiator's IP predefined, not suitable for dynamic IPs.

Read the full VPN explanation →

Question 8mediummulti select

An administrator is configuring a dial-up IPsec VPN for remote users. Which TWO settings are required on the FortiGate for the dial-up server? (Choose two.)

Trap 1: Set 'aggressive mode' on Phase 1

Aggressive mode is often used but not strictly required; main mode with mode-cfg works.

Trap 2: Set 'auto-negotiate' to enable on Phase 2

Auto-negotiate is not a standard parameter.

Trap 3: Set 'pfs' to enable on Phase 2

PFS is optional and not required for dial-up.

A
Set 'mode-cfg' to enable on Phase 1
Mode-config is used to assign IP addresses to clients.
B
Set 'peer type' to 'any' on Phase 1
Allows any remote peer to initiate the tunnel.
C
Set 'aggressive mode' on Phase 1
Why wrong: Aggressive mode is often used but not strictly required; main mode with mode-cfg works.
D
Set 'auto-negotiate' to enable on Phase 2
Why wrong: Auto-negotiate is not a standard parameter.
E
Set 'pfs' to enable on Phase 2
Why wrong: PFS is optional and not required for dial-up.

Question 9mediummultiple choice

An administrator runs 'diagnose debug application fnbamd -1' on a FortiGate to troubleshoot authentication issues. The output shows that the FortiGate successfully contacts the LDAP server but the user authentication fails. What does this indicate?

Trap 1: The LDAP server is unreachable

The fnbamd debug log explicitly records "successful contact" with the LDAP server, meaning the FortiGate resolved the server name, reached it over the network, and received a response—likely a connection acknowledgment or an LDAP greeting. If the server were unreachable, the debug output would instead show repeated connection timeouts, 'no response', or a failure to establish a socket, not a successful contact followed by an authentication attempt. Thus, the option is directly contradicted by the evidence in the log.

Trap 2: The LDAP bind user password is incorrect

When the LDAP bind user (the service account FortiGate uses to search the directory) has an incorrect password, the initial bind phase fails immediately, preventing any subsequent query or user authentication. The debug output shows that FortiGate not only contacted the server but also proceeded to attempt user authentication, which proves the service account bind succeeded and the server accepted those credentials. A bad bind password would produce an error much earlier in the sequence, before any specific user's credentials are validated.

Trap 3: The LDAP schema does not match what FortiGate expects

An LDAP schema mismatch typically surfaces as failures to map directory attributes (for example, missing sAMAccountName, memberOf, or group objects), generating errors like 'attribute not found' or 'cannot retrieve user groups', rather than a clean 'authentication failed' response. The debug output shows the server accepted the user DN and password attempt, which indicates the server could locate the user object and evaluate the credentials; a schema problem would not affect the basic LDAP bind operation that verifies the password. Therefore, schema mismatch does not explain a specific user authentication failure after successful contact.

A
The user's password is incorrect or the user account is locked
In the fnbamd debug output, "successful contact" confirms that the FortiGate established a TCP session and communicated with the LDAP server; the failure happens during the final bind step where the end user's distinguished name (DN) and password are verified. An LDAP 'invalidCredentials' or 'accountDisabled' result at this stage is the server's definitive rejection of that specific user's password or account state, not a communication problem. Therefore, the correct interpretation is that the user's password is wrong or the user account is locked out, disabled, or expired.
B
The LDAP server is unreachable
Why wrong: The fnbamd debug log explicitly records "successful contact" with the LDAP server, meaning the FortiGate resolved the server name, reached it over the network, and received a response—likely a connection acknowledgment or an LDAP greeting. If the server were unreachable, the debug output would instead show repeated connection timeouts, 'no response', or a failure to establish a socket, not a successful contact followed by an authentication attempt. Thus, the option is directly contradicted by the evidence in the log.
C
The LDAP bind user password is incorrect
Why wrong: When the LDAP bind user (the service account FortiGate uses to search the directory) has an incorrect password, the initial bind phase fails immediately, preventing any subsequent query or user authentication. The debug output shows that FortiGate not only contacted the server but also proceeded to attempt user authentication, which proves the service account bind succeeded and the server accepted those credentials. A bad bind password would produce an error much earlier in the sequence, before any specific user's credentials are validated.
D
The LDAP schema does not match what FortiGate expects
Why wrong: An LDAP schema mismatch typically surfaces as failures to map directory attributes (for example, missing sAMAccountName, memberOf, or group objects), generating errors like 'attribute not found' or 'cannot retrieve user groups', rather than a clean 'authentication failed' response. The debug output shows the server accepted the user DN and password attempt, which indicates the server could locate the user object and evaluate the credentials; a schema problem would not affect the basic LDAP bind operation that verifies the password. Therefore, schema mismatch does not explain a specific user authentication failure after successful contact.