Firewall Policies and NAT practice questions

A network administrator configures a firewall policy to allow HTTP traffic from the internal network (10.0.0.0/8) to a web server (172.16.1.10). Users on the 10.0.0.0/8 network cannot access the web server, but other internal users can. The administrator checks the policy list and sees the policy is enabled and in the correct position. What is the most likely cause?

Trap 1: The policy is placed below a deny-all policy

On FortiGate, firewall policies are evaluated sequentially from the top of the policy list downward; the first matching policy is enforced. If a deny-all policy were positioned above, it would match first and drop the traffic before the allow policy could be reached, but the administrator has already verified that the policy order is correct. Moreover, a policy placed below a deny-all rule would typically generate a policy hit on the deny rule, not a routing error, so this is not the root cause here.

Trap 2: NAT is not configured on the policy

Network Address Translation (NAT) on a FortiGate policy is only required for traffic that must be source-translated, usually when moving between zones, such as internal to external. For internal-to-internal traffic traversing the FortiGate, the source and destination addresses are private and routable within the organization, so no translation is necessary. The absence of NAT would not cause packets to be dropped; the firewall would still forward the traffic if routes exist, because NAT is not a prerequisite for packet forwarding on internal paths.

Trap 3: The policy is disabled

A disabled firewall policy on FortiGate is not loaded into the policy lookup engine, so traffic that would normally match it instead falls through to the next matching policy or is blocked by the implicit deny rule. However, the administrator has already confirmed that the policy is in an enabled state, so this cannot be the cause. Additionally, a disabled policy would typically result in a total lack of session setup or a 'policy denied' message in the logs, rather than a specific routing failure.

A
The policy is placed below a deny-all policy
Why wrong: On FortiGate, firewall policies are evaluated sequentially from the top of the policy list downward; the first matching policy is enforced. If a deny-all policy were positioned above, it would match first and drop the traffic before the allow policy could be reached, but the administrator has already verified that the policy order is correct. Moreover, a policy placed below a deny-all rule would typically generate a policy hit on the deny rule, not a routing error, so this is not the root cause here.
B
NAT is not configured on the policy
Why wrong: Network Address Translation (NAT) on a FortiGate policy is only required for traffic that must be source-translated, usually when moving between zones, such as internal to external. For internal-to-internal traffic traversing the FortiGate, the source and destination addresses are private and routable within the organization, so no translation is necessary. The absence of NAT would not cause packets to be dropped; the firewall would still forward the traffic if routes exist, because NAT is not a prerequisite for packet forwarding on internal paths.
C
The firewall does not have a route to the 10.0.0.0/8 network
The firewall must perform a route lookup for the destination (10.0.0.0/8) after receiving the traffic on the ingress interface, and if no matching route or default route exists, the packet is dropped before the firewall policy is even evaluated. Even a policy that explicitly allows the traffic cannot compensate for a missing route, because routing and firewall policy checks are independent sequential steps in the FortiGate packet flow. The administrator's verification of policy order and status would not uncover this issue, making a missing route a plausible and common cause of the reported failure.
D
The policy is disabled
Why wrong: A disabled firewall policy on FortiGate is not loaded into the policy lookup engine, so traffic that would normally match it instead falls through to the next matching policy or is blocked by the implicit deny rule. However, the administrator has already confirmed that the policy is in an enabled state, so this cannot be the cause. Additionally, a disabled policy would typically result in a total lack of session setup or a 'policy denied' message in the logs, rather than a specific routing failure.

Read the full VPN explanation →

Question 2hardmultiple choice

An organization wants to authenticate VPN users using an LDAP server. They configure an LDAP server object and a user group. However, users are unable to authenticate. The administrator checks the logs and sees 'authentication failed' errors. What is the most common misconfiguration?

Trap 1: The user group is not configured with the correct members

The user group membership is used for authorization, not authentication. During LDAP authentication, the FortiGate verifies the user's credentials by binding to the directory with the user's DN and password; group membership is only evaluated after a successful bind to determine access policies. If the group is misconfigured, the user could still authenticate but fail to pass the policy check, so the symptom would be an authorization denial, not an authentication failure.

Trap 2: The LDAP server uses SSL/TLS but the FortiGate is not configured…

When the LDAP server is configured to require SSL/TLS, the FortiGate must have the corresponding LDAPS settings or a valid CA certificate to establish an encrypted channel. Without this, the TLS handshake fails before any LDAP bind operation occurs, producing a transport-level error such as 'TLS negotiation failed' or 'SSL error,' not an authentication failure. Thus, this misconfiguration is categorized as a connectivity/protocol issue, distinct from a credential rejection.

Trap 3: The LDAP server is not reachable from the FortiGate

If the LDAP server is unreachable, the FortiGate cannot establish a TCP connection or LDAP session at all. This results in a timeout or connection-refused error in the logs, not an authentication failure, because the credential verification never occurs. The FortiGate would log messages like 'LDAP server connection failed' or 'Unable to reach server,' which clearly differentiate a network issue from a credential issue.

A
The user group is not configured with the correct members
Why wrong: The user group membership is used for authorization, not authentication. During LDAP authentication, the FortiGate verifies the user's credentials by binding to the directory with the user's DN and password; group membership is only evaluated after a successful bind to determine access policies. If the group is misconfigured, the user could still authenticate but fail to pass the policy check, so the symptom would be an authorization denial, not an authentication failure.
B
The LDAP server uses SSL/TLS but the FortiGate is not configured for it
Why wrong: When the LDAP server is configured to require SSL/TLS, the FortiGate must have the corresponding LDAPS settings or a valid CA certificate to establish an encrypted channel. Without this, the TLS handshake fails before any LDAP bind operation occurs, producing a transport-level error such as 'TLS negotiation failed' or 'SSL error,' not an authentication failure. Thus, this misconfiguration is categorized as a connectivity/protocol issue, distinct from a credential rejection.
C
The LDAP server bind DN or password is incorrect
The bind DN (distinguished name) and password constitute the FortiGate's service account credentials for connecting to the LDAP directory. If either is incorrect, the LDAP server rejects the bind operation with an 'invalid credentials' error (LDAP result code 49). This prevents the FortiGate from performing any directory queries, so the authentication process fails immediately at the initial bind stage, which is exactly what the user would see as an authentication failure.
D
The LDAP server is not reachable from the FortiGate
Why wrong: If the LDAP server is unreachable, the FortiGate cannot establish a TCP connection or LDAP session at all. This results in a timeout or connection-refused error in the logs, not an authentication failure, because the credential verification never occurs. The FortiGate would log messages like 'LDAP server connection failed' or 'Unable to reach server,' which clearly differentiate a network issue from a credential issue.

Question 3easymultiple choice

A FortiGate administrator needs to allow SMTP traffic from the internal network to an external mail server. The internal network uses source NAT to the external interface IP. Which firewall policy configuration is correct?

Trap 1: Policy: source internal, destination external, service SMTP,…

With NAT disabled, the FortiGate forwards packets unchanged, preserving the private source IP. The external mail server will send responses to that non-routable address, and return packets will be discarded by ISP routers because private addresses are not routed on the internet. Even if the mail server tried to respond, the internal host would never receive the SYN-ACK, so the TCP handshake fails; disabling NAT is only viable when clients already have public IPs.

Trap 2: Policy: source internal, destination external, service SMTP (port…

The built-in SMTP service object in FortiOS corresponds to TCP port 25, which is the standard SMTP mail transfer port between mail servers. Port 587 is specifically for SMTP message submission, often requiring authentication, and is not the same as plain SMTP delivery. Choosing port 587 would not satisfy a requirement to allow "SMTP traffic" unless the administrator explicitly intends to permit only client submissions, which the question stem does not indicate.

Trap 3: Policy: source internal, destination external, service SMTP (UDP),…

SMTP is a TCP-based protocol because it requires reliable, ordered delivery of commands and message data; there is no standard UDP variant. Selecting a UDP service object incorrectly would allow the FortiGate to forward UDP datagrams to port 25, but real SMTP clients and servers will not communicate over UDP, so legitimate email delivery would still fail. Additionally, the FortiOS service object for SMTP is defined as TCP/25, not UDP.

A
Policy: source internal, destination external, service SMTP, enable NAT
Enable NAT on the policy so the FortiGate performs source NAT (hide/PAT), translating the internal source IP (e.g., 10.0.0.10) to the interface's public IP address. This makes the SMTP connection appear to originate from a routable public address, and the stateful session table ensures replies from the external mail server are returned to the correct internal host. Without this translation, the outbound SYN would carry a private source address that ISPs drop.
B
Policy: source internal, destination external, service SMTP, disable NAT
Why wrong: With NAT disabled, the FortiGate forwards packets unchanged, preserving the private source IP. The external mail server will send responses to that non-routable address, and return packets will be discarded by ISP routers because private addresses are not routed on the internet. Even if the mail server tried to respond, the internal host would never receive the SYN-ACK, so the TCP handshake fails; disabling NAT is only viable when clients already have public IPs.
C
Policy: source internal, destination external, service SMTP (port 587), enable NAT
Why wrong: The built-in SMTP service object in FortiOS corresponds to TCP port 25, which is the standard SMTP mail transfer port between mail servers. Port 587 is specifically for SMTP message submission, often requiring authentication, and is not the same as plain SMTP delivery. Choosing port 587 would not satisfy a requirement to allow "SMTP traffic" unless the administrator explicitly intends to permit only client submissions, which the question stem does not indicate.
D
Policy: source internal, destination external, service SMTP (UDP), enable NAT
Why wrong: SMTP is a TCP-based protocol because it requires reliable, ordered delivery of commands and message data; there is no standard UDP variant. Selecting a UDP service object incorrectly would allow the FortiGate to forward UDP datagrams to port 25, but real SMTP clients and servers will not communicate over UDP, so legitimate email delivery would still fail. Additionally, the FortiOS service object for SMTP is defined as TCP/25, not UDP.

Question 4mediummultiple choice

Refer to the exhibit. A FortiGate has this policy configured. Traffic from 10.0.1.0/24 to 192.168.1.10 on HTTP is being logged as allowed. However, users report that they cannot access the web server. What is the most likely issue?

Exhibit

config firewall policy
    edit 1
        set name "Allow-HTTP"
        set srcintf "internal"
        set dstintf "dmz"
        set srcaddr "10.0.1.0/24"
        set dstaddr "192.168.1.10"
        set action accept
        set schedule "always"
        set service "HTTP"
        set logtraffic all
    next
end

Trap 1: NAT is not enabled on the policy

NAT on a FortiGate policy performs source address translation to the FortiGate's egress interface IP. When NAT is not enabled, the original private source IP is preserved in the packet, so the remote server replies directly to that private address. That RFC 1918 destination is not routable on the public internet, causing the return traffic to be dropped and the session to time out despite the policy permitting the connection.

Trap 2: The policy is placed below a deny policy

FortiGate security policies are evaluated in top-down order, and only the first match is enforced. If a deny policy were placed above this allow policy and matched the same source/destination/service, it would block the traffic before the allow policy could ever be evaluated. Since the traffic logs show that the session was allowed, the policy must be the first matching entry, so having a deny policy above it is not the actual cause.

Trap 3: The policy is disabled

A disabled policy is completely removed from the policy lookup and will never match any traffic, regardless of how well it matches the session. If this policy were disabled, it would have zero hit counts and no log entries would be generated for it. The fact that the exhibit shows allowed traffic associated with this policy confirms it is enabled and actively being used in the firewall policy evaluation.

A
NAT is not enabled on the policy
Why wrong: NAT on a FortiGate policy performs source address translation to the FortiGate's egress interface IP. When NAT is not enabled, the original private source IP is preserved in the packet, so the remote server replies directly to that private address. That RFC 1918 destination is not routable on the public internet, causing the return traffic to be dropped and the session to time out despite the policy permitting the connection.
B
The policy is placed below a deny policy
Why wrong: FortiGate security policies are evaluated in top-down order, and only the first match is enforced. If a deny policy were placed above this allow policy and matched the same source/destination/service, it would block the traffic before the allow policy could ever be evaluated. Since the traffic logs show that the session was allowed, the policy must be the first matching entry, so having a deny policy above it is not the actual cause.
C
The service is set to HTTP but the server uses HTTPS
The service object in a FortiGate policy defines the destination ports that must match for the policy to apply. If the service were HTTP (port 80) but the server truly used HTTPS (port 443), the client's traffic would be destined to port 443 and would never match this HTTP-only policy. The log showing allowed HTTP traffic proves the session was successfully established on port 80, indicating the server is listening for HTTP on that port.
D
The policy is disabled
Why wrong: A disabled policy is completely removed from the policy lookup and will never match any traffic, regardless of how well it matches the session. If this policy were disabled, it would have zero hit counts and no log entries would be generated for it. The fact that the exhibit shows allowed traffic associated with this policy confirms it is enabled and actively being used in the firewall policy evaluation.

Question 5hardmultiple choice

Refer to the exhibit. An administrator runs 'diagnose firewall auth list' and sees two authenticated users. The firewall policy requires authentication for HTTP traffic from 10.0.0.0/24 to 192.168.1.10. User 'jsmith' has been idle for 20 minutes, but the authentication session is still active. The idle timeout is set to 30 minutes. What will happen after 30 minutes of inactivity?

Exhibit

FGT # diagnose firewall auth list
1: authid=1 type=ldap user=jsmith src=10.0.0.5 dst=192.168.1.10 proto=6 port=80 duration=1200 timeout=3600
2: authid=2 type=ldap user=ajones src=10.0.0.6 dst=192.168.1.10 proto=6 port=80 duration=600 timeout=3600

Trap 1: The authentication session will remain active because the firewall…

Authentication sessions and firewall sessions are independent constructs in FortiOS. The authentication entry has its own idle timer, which is not refreshed by ongoing firewall traffic. Even if a firewall session remains valid, once the authentication idle timeout elapses, the user's authenticated IP is removed from the user database and subsequent connection attempts require a new authentication.

Trap 2: The user will be automatically re-authenticated without prompting

FortiOS does not support silent re-authentication or a keep-alive mechanism that re-validates expired credentials without user interaction. When the authentication entry expires, the next HTTP or HTTPS connection from that IP is intercepted by the captive portal or authentication policy and the user must explicitly enter a username and password. Any claim of automatic re-authentication without a prompt is incorrect.

Trap 3: The firewall session will be torn down immediately

The authentication idle timer only controls the lifetime of the user-authenticated IP mapping, not the state of existing firewall sessions. Firewall sessions continue to live until they hit their own session idle timeout or are explicitly closed by the client sending FIN/RST. Therefore, the correct behavior is not the immediate teardown of all flows; rather, only future session setup is blocked until the user re-authenticates.

A
The authentication session will remain active because the firewall session is still valid
Why wrong: Authentication sessions and firewall sessions are independent constructs in FortiOS. The authentication entry has its own idle timer, which is not refreshed by ongoing firewall traffic. Even if a firewall session remains valid, once the authentication idle timeout elapses, the user's authenticated IP is removed from the user database and subsequent connection attempts require a new authentication.
B
The user will be automatically re-authenticated without prompting
Why wrong: FortiOS does not support silent re-authentication or a keep-alive mechanism that re-validates expired credentials without user interaction. When the authentication entry expires, the next HTTP or HTTPS connection from that IP is intercepted by the captive portal or authentication policy and the user must explicitly enter a username and password. Any claim of automatic re-authentication without a prompt is incorrect.
C
The firewall session will be torn down immediately
Why wrong: The authentication idle timer only controls the lifetime of the user-authenticated IP mapping, not the state of existing firewall sessions. Firewall sessions continue to live until they hit their own session idle timeout or are explicitly closed by the client sending FIN/RST. Therefore, the correct behavior is not the immediate teardown of all flows; rather, only future session setup is blocked until the user re-authenticates.
D
The authentication session will expire, and the user must re-authenticate for new traffic
When the authentication idle timeout expires, the kernel removes the authenticated user entry, but does not drop existing firewall sessions. The first new connection request after this expiry will be treated as unauthenticated, forcing the user to submit valid credentials again through the captive portal or firewall authentication page. This re-authentication is required only for new traffic; old, existing flows may still pass until they time out.

Question 6easymultiple choice

An administrator wants to create a firewall policy that blocks all traffic from a specific IP address (10.0.0.99) to the internet, but allows all other traffic. Which policy configuration is correct?

Trap 1: Create an allow policy for source 'all' and then a deny policy for…

Placing an allow policy for source 'all' before the deny policy is fatal because FortiGate uses first-match logic. The allow policy matches every source, including 10.0.0.99, so traffic from that host is permitted immediately and the deny policy for 10.0.0.99 is never evaluated. A deny rule must always be positioned above any allow rule that could otherwise match the same traffic to produce the intended block.

Trap 2: Use a local-in policy to block the IP

Local-in policies are designed for traffic destined to the FortiGate's own IP addresses, such as management sessions, not for traffic transiting through the firewall. Using a local-in policy to block 10.0.0.99 would only prevent that IP from reaching the FortiGate interfaces themselves, not from reaching internet destinations via the data plane. Forwarded traffic is controlled exclusively by regular firewall policies, so this approach is ineffective for the stated goal.

Trap 3: Create a policy that denies all traffic from 10.0.0.99 to any…

Creating a deny policy that covers all traffic from 10.0.0.99 to any destination is overbroad because it blocks not only internet access but also internal LAN-to-LAN communications and other legitimate transit traffic. In FortiGate, a policy lacking a specific destination interface applies to all forwarded traffic, potentially breaking internal connectivity. The correct deny policy should specify destination 'all' on the WAN interface (or a specific WAN address) to limit the block to outbound internet traffic only.

A
Create a deny policy for source 10.0.0.99 to destination 'all' on the WAN interface, then an allow policy for all other traffic
FortiGate firewall policies are evaluated top-down, and the first match is applied. Placing a deny policy that matches source 10.0.0.99, destination 'all', on the WAN interface above a permissive allow policy ensures the host's internet traffic is blocked while all other traffic falls through to the allow rule. This is correct because the deny rule's specificity combined with its higher position makes it effective, and the allow policy remains broad for remaining sources.
B
Create an allow policy for source 'all' and then a deny policy for 10.0.0.99
Why wrong: Placing an allow policy for source 'all' before the deny policy is fatal because FortiGate uses first-match logic. The allow policy matches every source, including 10.0.0.99, so traffic from that host is permitted immediately and the deny policy for 10.0.0.99 is never evaluated. A deny rule must always be positioned above any allow rule that could otherwise match the same traffic to produce the intended block.
C
Use a local-in policy to block the IP
Why wrong: Local-in policies are designed for traffic destined to the FortiGate's own IP addresses, such as management sessions, not for traffic transiting through the firewall. Using a local-in policy to block 10.0.0.99 would only prevent that IP from reaching the FortiGate interfaces themselves, not from reaching internet destinations via the data plane. Forwarded traffic is controlled exclusively by regular firewall policies, so this approach is ineffective for the stated goal.
D
Create a policy that denies all traffic from 10.0.0.99 to any destination
Why wrong: Creating a deny policy that covers all traffic from 10.0.0.99 to any destination is overbroad because it blocks not only internet access but also internal LAN-to-LAN communications and other legitimate transit traffic. In FortiGate, a policy lacking a specific destination interface applies to all forwarded traffic, potentially breaking internal connectivity. The correct deny policy should specify destination 'all' on the WAN interface (or a specific WAN address) to limit the block to outbound internet traffic only.

Question 7mediummulti select

Which TWO statements about firewall policy authentication are correct?

Trap 1: Authentication cannot be used with FSSO

FSSO (Fortinet Single Sign-On) is actually a supported authentication method for firewall policies. It collects user login information from Windows Active Directory (or other directory services) and synchronizes it with FortiGate, allowing user identity to be used in policy authentication. Therefore, authentication can indeed be used with FSSO, making this statement incorrect.

Trap 2: Authentication is only supported for inbound traffic

FortiGate does not restrict policy-based authentication to inbound traffic only. Outbound traffic, such as users accessing the internet, can also be subject to authentication, typically in proxy-based or NAT policies. This allows administrators to enforce user identity verification for both directions, so the claim that authentication is only supported inbound is false.

Trap 3: Authentication is performed after the traffic is allowed by the…

When a firewall policy has authentication enabled, FortiGate first intercepts the user's connection and prompts for credentials, typically via a web-based challenge, before allowing traffic based on the policy. Successful authentication is a prerequisite for the policy's allow action; only after the user is verified does traffic flow. Thus, authentication is performed before, not after, the policy allows traffic.

A
Authentication cannot be used with FSSO
Why wrong: FSSO (Fortinet Single Sign-On) is actually a supported authentication method for firewall policies. It collects user login information from Windows Active Directory (or other directory services) and synchronizes it with FortiGate, allowing user identity to be used in policy authentication. Therefore, authentication can indeed be used with FSSO, making this statement incorrect.
B
Authentication is only supported for inbound traffic
Why wrong: FortiGate does not restrict policy-based authentication to inbound traffic only. Outbound traffic, such as users accessing the internet, can also be subject to authentication, typically in proxy-based or NAT policies. This allows administrators to enforce user identity verification for both directions, so the claim that authentication is only supported inbound is false.
C
Authentication can be configured on a per-policy basis
Authentication settings are integrated directly into firewall policy configuration, allowing each individual policy to independently require user authentication. This per-policy toggle gives administrators flexibility to apply authentication only to specific source/destination pairs or services, while leaving other policies unauthenticated. It is accurate to state that authentication can be configured on a per-policy basis.
D
Authentication can be based on local, LDAP, or RADIUS databases
FortiGate supports multiple back-end authentication sources, including local accounts defined on the FortiGate itself, LDAP servers such as Active Directory, and RADIUS servers. When setting up policy authentication, an administrator selects which of these server types to use, and FortiGate validates user credentials against that defined database. This makes the statement about local, LDAP, or RADIUS databases correct.
E
Authentication is performed after the traffic is allowed by the policy
Why wrong: When a firewall policy has authentication enabled, FortiGate first intercepts the user's connection and prompts for credentials, typically via a web-based challenge, before allowing traffic based on the policy. Successful authentication is a prerequisite for the policy's allow action; only after the user is verified does traffic flow. Thus, authentication is performed before, not after, the policy allows traffic.

Question 8hardmulti select

Which THREE conditions must be met for a firewall policy with FSSO authentication to work correctly?

Trap 1: The user's IP address must be in the destination address range of…

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.

Trap 2: The user must be authenticated to the FortiGate locally

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.

A
The FortiGate must be able to communicate with the domain controller
FSSO relies on the FortiGate or Collector Agent receiving user login events from the domain controller. Without network connectivity to the DC, the FortiGate cannot learn which user logged in or which groups that user belongs to, so the policy cannot match the user. This communication is typically via LDAP or a proprietary FSSO polling/eventing protocol, and any firewall rule blocking it will break FSSO.
B
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.
C
The user must be a member of a group that is referenced in the firewall policy
The FSSO policy references a specific AD group, and the user's membership in that group is what authorizes traffic. When the DC reports a login event, it includes the user's group memberships, and FortiOS compares those to the group configured in the policy. If the user is not a member of any referenced group, no FSSO policy matches, and the traffic is dropped or evaluated against other policies.
D
The FSSO collector agent must be running and properly configured
The Collector Agent is the component that listens to domain controller security logs or polls for logon events and then pushes the IP-to-user mapping to the FortiGate. If it is not running or misconfigured, the FortiGate receives no login information, so user-based policies cannot be enforced. The agent must have the correct domain credentials and be able to reach both the DC and the FortiGate.
E
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.

Question 9hardmultiple choice

Refer to the exhibit. An administrator configures the policies as shown. Traffic from 10.0.0.0/8 to the internet on HTTP is denied. What is the most likely reason?

Exhibit

config firewall policy
    edit 0
        set name "Deny-All"
        set srcintf "any"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
    edit 1
        set name "Allow-HTTP"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "10.0.0.0/8"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "HTTP"
        set logtraffic all
    next
end

Trap 1: The Allow-HTTP policy uses service HTTP but the traffic uses HTTPS

The Allow-HTTP policy specifying service HTTP is actually correct for this scenario because the traffic in question is HTTP, not HTTPS. FortiOS service objects define both protocol and port, so HTTP (TCP 80) matches the HTTP traffic. If the traffic were HTTPS, this would cause a mismatch, but that contradicts the given premise. Therefore, the service configuration is not the issue.

Trap 2: The Allow-HTTP policy has the wrong source interface

The source interface is the FortiGate ingress interface for the traffic, and the exhibit shows the HTTP traffic arrives on the correct internal interface that is configured as the source of the Allow-HTTP policy. If the source interface were wrong, the policy would not even be considered for matching, but here the traffic does match the source requirement. The actual problem is that an earlier policy denies the traffic before this match can occur.

Trap 3: The Allow-HTTP policy is disabled

A disabled policy in FortiOS appears greyed out and is skipped entirely during policy matching. The exhibit shows the Allow-HTTP policy is enabled with no disabled icon, so it is active and capable of matching traffic. Even if it were disabled, simply enabling it would not resolve the issue because the Deny-All policy still sits above it and would continue to drop the traffic. Hence, the disabled state is not the cause.

A
The Allow-HTTP policy uses service HTTP but the traffic uses HTTPS
Why wrong: The Allow-HTTP policy specifying service HTTP is actually correct for this scenario because the traffic in question is HTTP, not HTTPS. FortiOS service objects define both protocol and port, so HTTP (TCP 80) matches the HTTP traffic. If the traffic were HTTPS, this would cause a mismatch, but that contradicts the given premise. Therefore, the service configuration is not the issue.
B
The Deny-All policy is placed above the Allow-HTTP policy
In FortiOS, policy evaluation is top-down and first-match; the first policy whose source/destination/service matches the traffic is applied. The Deny-All policy has a lower sequence number (e.g., policy ID 0) and appears above the Allow-HTTP policy, so it matches all traffic and denies the HTTP session before the allow policy is ever evaluated. Specificity does not override order, so the deny-all wins.
C
The Allow-HTTP policy has the wrong source interface
Why wrong: The source interface is the FortiGate ingress interface for the traffic, and the exhibit shows the HTTP traffic arrives on the correct internal interface that is configured as the source of the Allow-HTTP policy. If the source interface were wrong, the policy would not even be considered for matching, but here the traffic does match the source requirement. The actual problem is that an earlier policy denies the traffic before this match can occur.
D
The Allow-HTTP policy is disabled
Why wrong: A disabled policy in FortiOS appears greyed out and is skipped entirely during policy matching. The exhibit shows the Allow-HTTP policy is enabled with no disabled icon, so it is active and capable of matching traffic. Even if it were disabled, simply enabling it would not resolve the issue because the Deny-All policy still sits above it and would continue to drop the traffic. Hence, the disabled state is not the cause.

Question 10easymultiple choice

A FortiGate administrator wants to restrict access to a sensitive server (10.0.0.100) such that only users who authenticate via LDAP can access it. Which firewall policy configuration is required?

Trap 1: Policy: source any, destination 10.0.0.100, service any, action…

This policy simply permits all traffic to 10.0.0.100 without any identity check. Since authentication is not enabled, FortiGate will not prompt for credentials or check group membership, so any user—authenticated or not—can reach the sensitive destination. Restricting access requires enabling authentication and binding the policy to a specific LDAP user group.

Trap 2: Policy: source any, destination 10.0.0.100, service any, action…

Although authentication is enabled and set to LDAP, the policy lacks a group reference, making it incomplete in FortiOS. For identity-based policies, the firewall requires at least one user group to evaluate authorization; without it, the policy cannot determine which users are allowed and will not enforce LDAP-based restrictions. You must specify an LDAP group, such as 'LDAP-Users', to complete the configuration.

Trap 3: Policy: source any, destination 10.0.0.100, service any, action…

FSSO relies on a different mechanism—collecting domain logon events from Windows servers—rather than forcing LDAP authentication at the firewall. Enabling FSSO on this policy does not verify credentials against LDAP nor does it specify a group like 'LDAP-Users', so it fails to fulfill the requirement for LDAP-based access restriction. Additionally, FSSO is typically used for transparent single sign-on and doesn't provide the same per-policy authentication with a defined group.

A
Policy: source any, destination 10.0.0.100, service any, action accept
Why wrong: This policy simply permits all traffic to 10.0.0.100 without any identity check. Since authentication is not enabled, FortiGate will not prompt for credentials or check group membership, so any user—authenticated or not—can reach the sensitive destination. Restricting access requires enabling authentication and binding the policy to a specific LDAP user group.
B
Policy: source any, destination 10.0.0.100, service any, action accept, enable authentication, set auth-type LDAP
Why wrong: Although authentication is enabled and set to LDAP, the policy lacks a group reference, making it incomplete in FortiOS. For identity-based policies, the firewall requires at least one user group to evaluate authorization; without it, the policy cannot determine which users are allowed and will not enforce LDAP-based restrictions. You must specify an LDAP group, such as 'LDAP-Users', to complete the configuration.
C
Policy: source any, destination 10.0.0.100, service any, action accept, enable authentication, set auth-type LDAP, set groups "LDAP-Users"
This is the correct configuration because it enables authentication, selects LDAP as the authentication type, and explicitly restricts access to members of the LDAP-Users group. In FortiOS, an identity-based policy with a specified group enforces both authentication (credentials verified against LDAP) and authorization (group membership checked). After a user authenticates successfully and is a member of LDAP-Users, the accept action permits traffic to 10.0.0.100.
D
Policy: source any, destination 10.0.0.100, service any, action accept, enable FSSO authentication
Why wrong: FSSO relies on a different mechanism—collecting domain logon events from Windows servers—rather than forcing LDAP authentication at the firewall. Enabling FSSO on this policy does not verify credentials against LDAP nor does it specify a group like 'LDAP-Users', so it fails to fulfill the requirement for LDAP-based access restriction. Additionally, FSSO is typically used for transparent single sign-on and doesn't provide the same per-policy authentication with a defined group.

Study the full SD-WAN breakdown →

Question 11hardmultiple choice

A company has a FortiGate 100F with two ISPs (ISP1 and ISP2) for load balancing. They use SD-WAN to direct traffic. The firewall has a policy that allows HTTP and HTTPS traffic from internal users (10.0.0.0/8) to the internet. The policy uses FSSO authentication with an Active Directory domain controller. Recently, users on the 10.0.1.0/24 subnet report that they are prompted for authentication repeatedly, even though they are domain-joined and logged in. Users on other subnets do not have this issue. The administrator checks the FSSO configuration and sees that the collector agent is running and the FortiGate is receiving login events. The FortiGate's policy is configured with source address 10.0.0.0/8 and FSSO group 'Domain Users'. The administrator also notices that the FortiGate's SD-WAN rules are configured to use ISP1 for traffic from 10.0.0.0/8 except for traffic from 10.0.1.0/24, which uses ISP2. The FortiGate's FSSO collector agent is configured to listen on the IP address 192.168.1.1, which is the IP of the interface connected to ISP1. What is the most likely cause of the authentication issue?

Trap 1: The FSSO group 'Domain Users' does not include the affected users

The FSSO group 'Domain Users' includes all authenticated domain users, and membership is not network-specific. If a user in that group were omitted, authentication would fail consistently across all subnets, not just 10.0.1.0/24. The symptom is isolated to one subnet, which points to a routing or reachability problem rather than a group membership issue.

Trap 2: The SD-WAN rule for 10.0.1.0/24 is misconfigured and drops…

SD-WAN rules in FortiOS are designed to steer traffic based on load-balancing or least-cost criteria, not to drop authentication traffic. A misconfigured rule might send packets via an unintended interface, but it would not explicitly block or discard FSSO authentication frames. Since the FortiGate can still receive login events for other subnets, the SD-WAN rule itself is not preventing authentication; the underlying cause is the unreachability of the collector agent's listening IP.

Trap 3: The domain controller is not reachable from the FortiGate

The administrator confirmed that login events are received for other subnets, which proves the domain controller is reachable from the FortiGate. If the domain controller were unreachable, no FSSO events would arrive for any subnet, causing a global authentication failure. The subnet-specific nature of the issue indicates that the DC can communicate, but return traffic from the 10.0.1.0/24 subnet is being routed incorrectly through SD-WAN, preventing the collector agent from seeing those events.

A
The FSSO group 'Domain Users' does not include the affected users
Why wrong: The FSSO group 'Domain Users' includes all authenticated domain users, and membership is not network-specific. If a user in that group were omitted, authentication would fail consistently across all subnets, not just 10.0.1.0/24. The symptom is isolated to one subnet, which points to a routing or reachability problem rather than a group membership issue.
B
The SD-WAN rule for 10.0.1.0/24 is misconfigured and drops authentication traffic
Why wrong: SD-WAN rules in FortiOS are designed to steer traffic based on load-balancing or least-cost criteria, not to drop authentication traffic. A misconfigured rule might send packets via an unintended interface, but it would not explicitly block or discard FSSO authentication frames. Since the FortiGate can still receive login events for other subnets, the SD-WAN rule itself is not preventing authentication; the underlying cause is the unreachability of the collector agent's listening IP.
C
The domain controller is not reachable from the FortiGate
Why wrong: The administrator confirmed that login events are received for other subnets, which proves the domain controller is reachable from the FortiGate. If the domain controller were unreachable, no FSSO events would arrive for any subnet, causing a global authentication failure. The subnet-specific nature of the issue indicates that the DC can communicate, but return traffic from the 10.0.1.0/24 subnet is being routed incorrectly through SD-WAN, preventing the collector agent from seeing those events.
D
The FSSO collector agent is listening on an IP that is not reachable from the 10.0.1.0/24 subnet due to SD-WAN routing
The FortiGate FSSO collector agent listens on a specific IP address, and in this scenario that IP is bound to the ISP1 interface. Due to the SD-WAN configuration, traffic originating from the 10.0.1.0/24 subnet is routed via ISP2, so the domain controller's attempts to send login events to the collector agent's ISP1 IP are unreachable. This asymmetric routing causes the collector agent to miss authentication events for only that subnet, explaining why users on 10.0.1.0/24 cannot authenticate even though other subnets work.

Question 12mediummultiple choice

Given the exhibit, a user in the internal network tries to SSH to a public server (203.0.113.10). What will happen and why?

Exhibit

Refer to the exhibit.

config firewall policy
    edit 1
        set name "Allow-Internet"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable
        set logtraffic all
    next
    edit 2
        set name "Block-SSH"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set schedule "always"
        set service "SSH"
        set logtraffic all
    next
end

Trap 1: The SSH connection will succeed because policy 2 is evaluated first.

This statement is incorrect because FortiGate does not evaluate policies in reverse order or based on priority. Policies are always checked from the top of the list to the bottom, and the first policy that matches the source, destination, and service determines the action. Policy 1 appears above policy 2, so it is evaluated first. Had policy 2 been evaluated first, the result would be a block, not a success, making the claimed outcome doubly wrong.

Trap 2: The SSH connection will be blocked because policy 2 explicitly…

Although policy 2 does explicitly deny SSH, its position in the policy list prevents it from ever being evaluated for this traffic. FortiGate uses a first-match model: once a policy matches all criteria, the processing stops and the configured action (allow or deny) is executed. Since policy 1 is listed before policy 2 and matches the SSH connection with service ALL, the deny in policy 2 is irrelevant. The connection succeeds because the allow rule preempts the later deny rule.

Trap 3: The SSH connection will be blocked because policy 1 does not…

This reasoning misunderstands the meaning of the service 'ALL' in FortiGate policy configuration. The ALL service is a wildcard that includes every possible service, including SSH, HTTP, HTTPS, ICMP, and all TCP/UDP ports. Policy 1 does not need to list SSH explicitly because ALL already encompasses it. The connection is not blocked due to a missing service; it is allowed precisely because policy 1's broad service definition matches SSH, and the policy order lets that match occur first.

A
The SSH connection will succeed because policy 1 allows all services before policy 2 is evaluated.
In FortiGate, firewall policies are evaluated sequentially from the top of the policy list downward. Because policy 1 matches all traffic from the internal interface to wan1 with service set to ALL, it includes SSH (TCP port 22). Since this allow policy is encountered first, it takes effect and the SSH session is permitted. Policy 2, even though it explicitly denies SSH, is never reached because the first match already decided the traffic's fate.
B
The SSH connection will succeed because policy 2 is evaluated first.
Why wrong: This statement is incorrect because FortiGate does not evaluate policies in reverse order or based on priority. Policies are always checked from the top of the list to the bottom, and the first policy that matches the source, destination, and service determines the action. Policy 1 appears above policy 2, so it is evaluated first. Had policy 2 been evaluated first, the result would be a block, not a success, making the claimed outcome doubly wrong.
C
The SSH connection will be blocked because policy 2 explicitly denies SSH.
Why wrong: Although policy 2 does explicitly deny SSH, its position in the policy list prevents it from ever being evaluated for this traffic. FortiGate uses a first-match model: once a policy matches all criteria, the processing stops and the configured action (allow or deny) is executed. Since policy 1 is listed before policy 2 and matches the SSH connection with service ALL, the deny in policy 2 is irrelevant. The connection succeeds because the allow rule preempts the later deny rule.
D
The SSH connection will be blocked because policy 1 does not include SSH service specifically.
Why wrong: This reasoning misunderstands the meaning of the service 'ALL' in FortiGate policy configuration. The ALL service is a wildcard that includes every possible service, including SSH, HTTP, HTTPS, ICMP, and all TCP/UDP ports. Policy 1 does not need to list SSH explicitly because ALL already encompasses it. The connection is not blocked due to a missing service; it is allowed precisely because policy 1's broad service definition matches SSH, and the policy order lets that match occur first.

Question 13mediumdrag order

Drag and drop the steps to create a firewall policy allowing HTTP traffic from internal to DMZ into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: 1

This option incorrectly prioritizes address objects before the interface pair. In FortiOS, the policy must first establish the incoming and outgoing interfaces, because traffic matching is performed within that interface context and address objects are scoped to the relevant VDOM/zone. Selecting addresses first can lead to choosing objects from the wrong network domain, and the firewall cannot determine which traffic path the policy applies to. The GUI enforces interface selection first precisely because source and destination addresses are only meaningful after the zones are known.

Trap 2: 1

Selecting the HTTP service before defining interfaces and addresses is logically backwards: the service object only specifies the application protocol (TCP/80), but the policy must first identify the traffic path (the interface pair) and the communicating hosts (source/destination addresses) to know which sessions this service filter applies to. In FortiOS, a policy without interface and address context cannot be meaningfully configured, and the standard workflow is to build the traffic selector from the outer network context inward — interfaces, then addresses, then services. This option also confuses the GUI's Services section, which remains unavailable until the source and destination fields are populated.

Trap 3: 1

The action field determines whether matching traffic is accepted or denied, but it has no effect until the match conditions are defined. In FortiOS, setting 'Accept' and enabling logging before specifying interfaces, addresses, and service commits to the result before describing the traffic that will be evaluated, which makes policy review and troubleshooting harder. The configuration workflow for firewall policies always places the action at the end because it is the outcome of the match criteria, not a prerequisite for defining them.

A
1. Select source and destination interfaces, 2. Select source and destination addresses, 3. Select service (HTTP), 4. Set action to accept and enable logging
This order follows the standard firewall policy creation workflow: first define the traffic flow by selecting interfaces, then specify the communicating hosts with addresses, then choose the service, and finally set the action and logging.
B
1. Select source and destination addresses, 2. Select source and destination interfaces, 3. Select service (HTTP), 4. Set action to accept and enable logging
Why wrong: This option incorrectly prioritizes address objects before the interface pair. In FortiOS, the policy must first establish the incoming and outgoing interfaces, because traffic matching is performed within that interface context and address objects are scoped to the relevant VDOM/zone. Selecting addresses first can lead to choosing objects from the wrong network domain, and the firewall cannot determine which traffic path the policy applies to. The GUI enforces interface selection first precisely because source and destination addresses are only meaningful after the zones are known.
C
1. Select service (HTTP), 2. Select source and destination interfaces, 3. Select source and destination addresses, 4. Set action to accept and enable logging
Why wrong: Selecting the HTTP service before defining interfaces and addresses is logically backwards: the service object only specifies the application protocol (TCP/80), but the policy must first identify the traffic path (the interface pair) and the communicating hosts (source/destination addresses) to know which sessions this service filter applies to. In FortiOS, a policy without interface and address context cannot be meaningfully configured, and the standard workflow is to build the traffic selector from the outer network context inward — interfaces, then addresses, then services. This option also confuses the GUI's Services section, which remains unavailable until the source and destination fields are populated.
D
1. Set action to accept and enable logging, 2. Select source and destination interfaces, 3. Select source and destination addresses, 4. Select service (HTTP)
Why wrong: The action field determines whether matching traffic is accepted or denied, but it has no effect until the match conditions are defined. In FortiOS, setting 'Accept' and enabling logging before specifying interfaces, addresses, and service commits to the result before describing the traffic that will be evaluated, which makes policy review and troubleshooting harder. The configuration workflow for firewall policies always places the action at the end because it is the outcome of the match criteria, not a prerequisite for defining them.

Read the full VPN explanation →

Question 14mediumdrag order

Drag and drop the steps to configure SSL VPN on FortiGate into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Step 1: Create user group, Step 2: Configure SSL VPN settings, Step…

This order is invalid because the SSL VPN settings page contains a drop-down list that selects the portal to be used, so the portal must already exist before you create the settings. If you try to configure settings first, the portal list will be empty or will reference a default portal, and your custom portal will not be linked correctly. Moreover, changing the portal later may require re-editing the settings, creating extra administrative effort and a higher risk of misconfiguration.

Trap 2: Step 1: Create user group, Step 2: Configure SSL VPN portal, Step…

Placing the firewall policy before the SSL VPN settings is a dependency error because the policy references the SSL VPN virtual interface (e.g., ssl.tun) and the IP pool defined in those settings. Without the settings in place, the interface may not be available for selection, and the policy could be written against a non-existent or default interface, leading to traffic not being matched or being incorrectly matched. The settings must be finalized first so that the policy objects resolve correctly at run time.

Trap 3: Step 1: Enable SSL VPN service, Step 2: Create user group, Step 3:…

Enabling the SSL VPN service at the beginning is premature because the service daemon will start with no user group, portal, or network settings, which can cause it to fail to start or, worse, to listen with insecure defaults and allow access to unauthenticated users. In FortiGate, the 'Enable SSL-VPN' toggle is actually part of the SSL VPN settings screen, so turning it on before configuring the rest is not only out of order but also impossible to separate from the settings step in the GUI. The service should be enabled last, after all dependent configuration is verified.

A
Step 1: Create user group, Step 2: Configure SSL VPN portal, Step 3: Configure SSL VPN settings, Step 4: Configure firewall policy, Step 5: Enable SSL VPN service
This sequence is correct because each step creates an object that the next step must reference. The user group defines which users may authenticate; the SSL VPN portal specifies the access options they will see; the SSL VPN settings bind that portal to the tunnel interface and IP pool; the firewall policy then decides which routes and services are permitted; and finally the service is enabled so the daemon starts with a fully validated configuration. This avoids any runtime errors or temporary exposure.
B
Step 1: Create user group, Step 2: Configure SSL VPN settings, Step 3: Configure SSL VPN portal, Step 4: Configure firewall policy, Step 5: Enable SSL VPN service
Why wrong: This order is invalid because the SSL VPN settings page contains a drop-down list that selects the portal to be used, so the portal must already exist before you create the settings. If you try to configure settings first, the portal list will be empty or will reference a default portal, and your custom portal will not be linked correctly. Moreover, changing the portal later may require re-editing the settings, creating extra administrative effort and a higher risk of misconfiguration.
C
Step 1: Create user group, Step 2: Configure SSL VPN portal, Step 3: Configure firewall policy, Step 4: Configure SSL VPN settings, Step 5: Enable SSL VPN service
Why wrong: Placing the firewall policy before the SSL VPN settings is a dependency error because the policy references the SSL VPN virtual interface (e.g., ssl.tun) and the IP pool defined in those settings. Without the settings in place, the interface may not be available for selection, and the policy could be written against a non-existent or default interface, leading to traffic not being matched or being incorrectly matched. The settings must be finalized first so that the policy objects resolve correctly at run time.
D
Step 1: Enable SSL VPN service, Step 2: Create user group, Step 3: Configure SSL VPN portal, Step 4: Configure SSL VPN settings, Step 5: Configure firewall policy
Why wrong: Enabling the SSL VPN service at the beginning is premature because the service daemon will start with no user group, portal, or network settings, which can cause it to fail to start or, worse, to listen with insecure defaults and allow access to unauthenticated users. In FortiGate, the 'Enable SSL-VPN' toggle is actually part of the SSL VPN settings screen, so turning it on before configuring the rest is not only out of order but also impossible to separate from the settings step in the GUI. The service should be enabled last, after all dependent configuration is verified.

Question 15mediummatching

Match each Fortinet product to its primary role.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Next-generation firewall

Security information and event management

Centralized logging and analytics

Centralized management and policy orchestration

Advanced threat detection and analysis

Trap 1: FortiGate: Centralized management and orchestration.

Assigning centralized management to FortiGate conflates the data plane with the management plane. FortiGate's primary role is enforcing security policies as an NGFW, such as performing stateful inspection and IPS; while a FortiGate has a local GUI/CLI for its own configuration, it lacks the multi-device orchestration and centralized policy distribution that FortiManager provides.

Trap 2: FortiManager: Advanced threat detection through behavioral analysis.

This answer misidentifies FortiManager, which is not a detection engine. FortiManager provides centralized monitoring and configuration management, but it does not execute or observe files; behavioral analysis for advanced threats is exclusively the domain of FortiSandbox, which isolates and runs suspicious code to identify malicious actions.

A
FortiGate: Provides next-generation firewall and security gateway capabilities.
FortiGate is the enforcement point in the Fortinet Security Fabric, providing next-generation firewall capabilities including deep packet inspection, application control, intrusion prevention, and SSL/TLS inspection. It terminates VPNs and applies security policies at line rate, making it the primary security gateway for both north-south and east-west traffic.
B
FortiManager: Centralized management and orchestration of Fortinet devices.
FortiManager is the centralized management plane, offering a single-pane-of-glass view for configuration, policy provisioning, and firmware updates across many FortiGate devices. It uses Administrative Domains (ADOMs) to segment network management and supports device groups for bulk changes, but it does not process live traffic or detect threats itself.
C
FortiAnalyzer: Logging, reporting, and analytics for security events.
FortiAnalyzer acts as a centralized log repository, collecting logs from FortiGate and other Fortinet products to enable forensic analysis, compliance reporting, and event correlation. It also provides preconfigured and custom reports, as well as data visualization for security operations, without performing inline protection or behavioral sandboxing.
D
FortiSandbox: Advanced threat detection through behavioral analysis.
FortiSandbox is a dedicated threat-detection appliance that detonates suspect files in a virtualized environment, observing their behavior to identify zero-day and evasive malware. It integrates with FortiGate via the Fabric Connector or security rating to quarantine advanced threats, but it is not involved in policy enforcement or management.
E
FortiGate: Centralized management and orchestration.
Why wrong: Assigning centralized management to FortiGate conflates the data plane with the management plane. FortiGate's primary role is enforcing security policies as an NGFW, such as performing stateful inspection and IPS; while a FortiGate has a local GUI/CLI for its own configuration, it lacks the multi-device orchestration and centralized policy distribution that FortiManager provides.
F
FortiManager: Advanced threat detection through behavioral analysis.
Why wrong: This answer misidentifies FortiManager, which is not a detection engine. FortiManager provides centralized monitoring and configuration management, but it does not execute or observe files; behavioral analysis for advanced threats is exclusively the domain of FortiSandbox, which isolates and runs suspicious code to identify malicious actions.

Question 16mediummatching

Match each FortiGate logging destination to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Stored on the FortiGate's internal memory or disk

Centralized log collector and analyzer

Standard protocol to send logs to external servers

Cloud-based log storage and management

Used for monitoring device status and performance

Trap 1: Syslog: Logs are sent to FortiAnalyzer for logging and analysis.

This confuses the syslog protocol with FortiAnalyzer's role. Syslog is a transport mechanism that sends logs to any compliant external server, whereas FortiAnalyzer is a dedicated management and reporting platform that typically uses its own optimized protocol, not syslog, when receiving logs directly from FortiGate. Sending logs to FortiAnalyzer via syslog is possible but it's not "syslog" — the destination would still be FortiAnalyzer. The statement incorrectly defines syslog as sending to a specific vendor product, which is why it is wrong.

Trap 2: Local memory: Logs are sent to an external server.

This is incorrect because local memory is, by definition, local to the FortiGate — either the internal flash, hard disk, or RAM — and no network transmission is involved. Sending logs to an external server describes remote logging such as syslog, FortiAnalyzer, or FortiCloud, which are network destinations. Local memory logging is used for diagnostic purposes when remote logging is unavailable, but logs are never shipped off-box.

A
Local memory: Logs are stored on the FortiGate's hard disk or memory.
When logging to local memory, FortiOS writes log messages to the device's onboard storage, either the local disk (on models with a hard drive or SSD) or to RAM in low-end models. This is the default fallback when no remote log server or FortiAnalyzer is configured, and logs are subject to the device's storage capacity and overwrite behavior. It is the fastest to configure but provides no off-box redundancy, so logs are lost if the device fails or is rebooted (especially RAM logs).
B
Syslog: Logs are sent to an external syslog server.
Syslog logging uses the standard UDP or TCP protocol (default port 514, or 6514 for TLS) to forward FortiGate logs in real time to a third-party server such as Kiwi Syslog, rsyslog, or Splunk. The external server receives raw or parsed messages, enabling centralized archiving and correlation with other network devices. Because it uses a common standard, it integrates easily, but there is no built-in decryption or indexing for custom reporting.
C
FortiAnalyzer: Logs are sent to FortiAnalyzer for centralized logging, analysis, and reporting.
FortiAnalyzer is a dedicated Fortinet appliance or VM that receives logs over the proprietary FortiLog protocol (or secured tunnels) and provides centralized storage, indexing, real-time event correlation, and prebuilt reports. It also supports intelligence-driven features such as FortiGuard threat detection and can forward logs to syslog or FortiCloud. This is the preferred destination for multi-device environments because it filters and aggregates logs from FortiGate and other Fortinet devices.
D
FortiCloud: Logs are sent to FortiCloud for cloud-based logging.
FortiCloud is Fortinet's cloud platform offering subscription-based log storage, where FortiGate securely streams logs over HTTPS to Fortinet's cloud infrastructure. This removes the need for on-premises storage and is suitable for distributed or small deployments, but it requires a valid FortiCloud account and has retention limits based on the subscription tier. Logs can be viewed via the FortiCloud dashboard, though deep analysis and ad-hoc querying are more limited than FortiAnalyzer.
E
Syslog: Logs are sent to FortiAnalyzer for logging and analysis.
Why wrong: This confuses the syslog protocol with FortiAnalyzer's role. Syslog is a transport mechanism that sends logs to any compliant external server, whereas FortiAnalyzer is a dedicated management and reporting platform that typically uses its own optimized protocol, not syslog, when receiving logs directly from FortiGate. Sending logs to FortiAnalyzer via syslog is possible but it's not "syslog" — the destination would still be FortiAnalyzer. The statement incorrectly defines syslog as sending to a specific vendor product, which is why it is wrong.
F
Local memory: Logs are sent to an external server.
Why wrong: This is incorrect because local memory is, by definition, local to the FortiGate — either the internal flash, hard disk, or RAM — and no network transmission is involved. Sending logs to an external server describes remote logging such as syslog, FortiAnalyzer, or FortiCloud, which are network destinations. Local memory logging is used for diagnostic purposes when remote logging is unavailable, but logs are never shipped off-box.

Question 17mediummultiple choice

A network admin has configured a firewall policy allowing HTTPS traffic from the internal network to a DMZ web server. Users report that the web pages load slowly. The admin checks the policy and notices traffic shaping is not applied. What is the BEST action to ensure fair bandwidth distribution for HTTPS traffic?

Trap 1: Increase the bandwidth of the internet link

Increasing the bandwidth of the internet link only adds more capacity; it does not allocate or shape traffic between different service types. Unless per-policy shapers are in place, bulk transfers or heavy downloads can still consume all available bandwidth, making HTTPS and interactive traffic suffer. This approach treats the symptom (congestion) rather than the root cause (lack of fair distribution), and it does not guarantee any bandwidth for critical applications.

Trap 2: Configure policy-based routing for HTTPS traffic

Policy-based routing (PBR) changes the forwarding path or next hop for selected traffic based on source, destination, or other attributes. It does not apply rate limits or modify bandwidth allocations; even if HTTPS is sent via a different route, it can still experience the same congestion on the outbound interface. PBR is for path selection and load balancing, not for controlling how much bandwidth a policy can consume.

Trap 3: Enable QoS on the outgoing interface

Enabling QoS on the outgoing interface configures egress bandwidth settings and priorities, but it only provides class-based queuing and prioritization without applying per-policy committed or maximum bandwidth limits. While it can give HTTPS a higher priority, it does not cap or guarantee throughput for specific firewall policies, so lower-priority bulk traffic can still consume the remaining bandwidth and potentially starve other classes. Interface QoS also only operates at the interface level, lacking the granularity to enforce traffic shaping policy per match in a firewall rule.

A
Create a traffic shaping policy and apply it to the firewall policy
In FortiGate, bandwidth control is enforced through traffic shaping policies that are directly referenced by a firewall policy. You can assign a shared or per-IP traffic shaper with guaranteed and maximum bandwidth values, plus a priority level, so matching HTTPS sessions get explicit bandwidth limits and fair distribution. This is the only option that applies per-policy rate limiting, allowing the administrator to cap and prioritize traffic without affecting other policies.
B
Increase the bandwidth of the internet link
Why wrong: Increasing the bandwidth of the internet link only adds more capacity; it does not allocate or shape traffic between different service types. Unless per-policy shapers are in place, bulk transfers or heavy downloads can still consume all available bandwidth, making HTTPS and interactive traffic suffer. This approach treats the symptom (congestion) rather than the root cause (lack of fair distribution), and it does not guarantee any bandwidth for critical applications.
C
Configure policy-based routing for HTTPS traffic
Why wrong: Policy-based routing (PBR) changes the forwarding path or next hop for selected traffic based on source, destination, or other attributes. It does not apply rate limits or modify bandwidth allocations; even if HTTPS is sent via a different route, it can still experience the same congestion on the outbound interface. PBR is for path selection and load balancing, not for controlling how much bandwidth a policy can consume.
D
Enable QoS on the outgoing interface
Why wrong: Enabling QoS on the outgoing interface configures egress bandwidth settings and priorities, but it only provides class-based queuing and prioritization without applying per-policy committed or maximum bandwidth limits. While it can give HTTPS a higher priority, it does not cap or guarantee throughput for specific firewall policies, so lower-priority bulk traffic can still consume the remaining bandwidth and potentially starve other classes. Interface QoS also only operates at the interface level, lacking the granularity to enforce traffic shaping policy per match in a firewall rule.

Question 18mediummultiple choice

A FortiGate admin wants to create a firewall policy that allows traffic from the internal network to the internet. The source is a subnet 192.168.1.0/24, and the destination is 'all'. The admin wants to apply NAT to hide internal IPs. Which NAT configuration is BEST suited for this scenario?

Trap 1: Configure a VIP for source NAT

A Virtual IP (VIP) is designed for destination NAT: it translates an incoming packet's destination address from a public IP to a private server address. It does not alter the source address of outbound traffic, so configuring a VIP for source NAT would have no effect on hiding internal IPs. Since the goal is to hide internal sources on egress, a VIP is the wrong tool.

Trap 2: Use policy-based routing to send traffic through a NAT device

Policy-based routing (PBR) selects a next-hop or outgoing interface based on packet attributes, but it performs no address translation whatsoever. Directing traffic to an external NAT device would require that device to actually perform the translation, and the FortiGate itself would still need a separate NAT configuration. This approach adds network complexity and does not solve the requirement of hiding internal IPs on the FortiGate, so it is incorrect.

Trap 3: Create a one-to-one IP pool and apply it to the policy

A one-to-one IP pool reserves a unique public IP address for each internal source IP, meaning every internal host is mapped to a distinct external address. This approach does hide the original private IP, but it consumes a public IP per concurrent host and does not provide the 'many-to-one' address hiding that is typically intended. For simply hiding all internal IPs behind a single egress address, a one-to-one pool is wasteful and unnecessarily restrictive.

A
Configure a VIP for source NAT
Why wrong: A Virtual IP (VIP) is designed for destination NAT: it translates an incoming packet's destination address from a public IP to a private server address. It does not alter the source address of outbound traffic, so configuring a VIP for source NAT would have no effect on hiding internal IPs. Since the goal is to hide internal sources on egress, a VIP is the wrong tool.
B
Use policy-based routing to send traffic through a NAT device
Why wrong: Policy-based routing (PBR) selects a next-hop or outgoing interface based on packet attributes, but it performs no address translation whatsoever. Directing traffic to an external NAT device would require that device to actually perform the translation, and the FortiGate itself would still need a separate NAT configuration. This approach adds network complexity and does not solve the requirement of hiding internal IPs on the FortiGate, so it is incorrect.
C
Enable 'NAT' on the firewall policy and use the outgoing interface address
Enabling the NAT option on a firewall policy is the standard policy-based source NAT method. When NAT is enabled and no IP pool is selected, the FortiGate automatically uses the IP address of the outgoing interface as the translated source address for all matching sessions. This many-to-one hiding mechanism is the simplest and most common way to conceal all internal private IPs behind a single public address.
D
Create a one-to-one IP pool and apply it to the policy
Why wrong: A one-to-one IP pool reserves a unique public IP address for each internal source IP, meaning every internal host is mapped to a distinct external address. This approach does hide the original private IP, but it consumes a public IP per concurrent host and does not provide the 'many-to-one' address hiding that is typically intended. For simply hiding all internal IPs behind a single egress address, a one-to-one pool is wasteful and unnecessarily restrictive.

Question 19hardmultiple choice

An admin notices that a firewall policy allowing inbound HTTPS to a server is not matching traffic. The policy has source set to 'all', destination to the server's IP, and service to HTTPS. The admin checks the policy list and sees that policy ID 1 matches the traffic. What is the MOST likely reason the intended policy (ID 10) is not matching?

Trap 1: The firewall policy is disabled

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.

Trap 2: The service object for HTTPS is misconfigured in policy ID 10

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.

Trap 3: The destination address is incorrect in policy ID 10

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.

A
Policy ID 1 has a higher priority and matches before policy ID 10
FortiGate security policies are evaluated sequentially from the top of the policy table, and the first policy that matches all criteria (source, destination, service, schedule, etc.) is applied, terminating the lookup. Policy ID 1 has a lower numeric ID, which places it above policy ID 10 in the default ordering, so it is evaluated first. Because policy ID 1 already matches the inbound traffic, policy ID 10 is never reached, even if its configuration is perfectly valid. This is a classic policy shadowing issue where a broader or earlier policy overrides a more specific later one.
B
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.
C
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.
D
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.

Question 20easymultiple choice

Which of the following is a valid address object type in FortiGate that can be used to match traffic based on the domain name of the destination?

Trap 1: Wildcard FQDN

Wildcard FQDN is a distinct address object type in FortiGate, but it is intended for matching multiple domain names via wildcard patterns (e.g., *.example.com). In contrast, the FQDN type is the basic and correct choice for representing a single, specific domain name. Therefore, while Wildcard FQDN is technically valid in the broader firewall configuration, it does not answer the question, which asks for the type that matches a single domain. Thus, it is not the correct answer here.

Trap 2: Subnet

Subnet is an address object type that defines a range of IP addresses using network prefix notation (e.g., 192.168.1.0/24). It is purely IP-based and has no mechanism for resolving domain names to IP addresses. Since the question concerns a domain-related address object, Subnet is incorrect because it cannot represent or match a fully qualified domain name. It is used for IP address classification, not for domain-based traffic matching.

Trap 3: Geography

Geography is an address object type that groups IP addresses by country or region, using geolocation databases to match traffic based on geographic origin. It does not involve domain names at all; instead, it classifies by IP location. Since the question asks about a domain-related address object, Geography is incorrect because it operates on country-level IP mapping rather than individual domain resolution. It is useful for geo-blocking but not for matching a specific FQDN.

A
Wildcard FQDN
Why wrong: Wildcard FQDN is a distinct address object type in FortiGate, but it is intended for matching multiple domain names via wildcard patterns (e.g., *.example.com). In contrast, the FQDN type is the basic and correct choice for representing a single, specific domain name. Therefore, while Wildcard FQDN is technically valid in the broader firewall configuration, it does not answer the question, which asks for the type that matches a single domain. Thus, it is not the correct answer here.
B
Subnet
Why wrong: Subnet is an address object type that defines a range of IP addresses using network prefix notation (e.g., 192.168.1.0/24). It is purely IP-based and has no mechanism for resolving domain names to IP addresses. Since the question concerns a domain-related address object, Subnet is incorrect because it cannot represent or match a fully qualified domain name. It is used for IP address classification, not for domain-based traffic matching.
C
FQDN
FQDN (Fully Qualified Domain Name) is a valid address object type in FortiGate that represents a single specific domain name, such as www.example.com. When used in a firewall policy, FortiGate resolves the domain to its current IP address(es) and matches traffic accordingly, making it ideal for servers with dynamic IPs. This distinguishes it from other types, as it directly corresponds to the question's requirement for a domain-based address object. Thus, FQDN is the correct answer.
D
Geography
Why wrong: Geography is an address object type that groups IP addresses by country or region, using geolocation databases to match traffic based on geographic origin. It does not involve domain names at all; instead, it classifies by IP location. Since the question asks about a domain-related address object, Geography is incorrect because it operates on country-level IP mapping rather than individual domain resolution. It is useful for geo-blocking but not for matching a specific FQDN.