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

Question 2mediummultiple 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 it fails: 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 it fails: 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 it fails: 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 3hardmultiple 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 it fails: 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 it fails: 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 it fails: 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.

Study the full SD-WAN breakdown →

Question 4hardmultiple 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 it fails: 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 it fails: 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 it fails: 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.

Read the full VPN explanation →

Question 5mediumdrag order

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

Drag or tap steps into the slots.

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 it fails: 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 it fails: 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 it fails: 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 6mediummatching

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 it fails: 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 it fails: 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 7mediummultiple choice

You run 'diagnose sys session filter dport 443' and see the following output: proto=6 proto_state=01 duration=3600 expire=3599 What does this indicate?

Trap 1: The session is a UDP session

proto=6 indicates TCP, not UDP.

Trap 2: The session has been idle for 3600 seconds

duration is the total session lifetime, not idle time.

Trap 3: The session is fully established and will expire in 3599 seconds

State 01 indicates SYN_SENT, not established.

A
The TCP handshake is incomplete; the SYN-ACK has not been received
State 01 is SYN_SENT, meaning the SYN has been sent but no SYN-ACK received yet.
B
The session is a UDP session
Why it fails: proto=6 indicates TCP, not UDP.
C
The session has been idle for 3600 seconds
Why it fails: duration is the total session lifetime, not idle time.
D
The session is fully established and will expire in 3599 seconds
Why it fails: State 01 indicates SYN_SENT, not established.

Question 8easymultiple 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 it fails: 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 it fails: 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 it fails: 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.

Question 9mediummulti select

A FortiGate admin is troubleshooting a policy that should allow VoIP traffic. The admin suspects that the SIP ALG is interfering. Which TWO actions should the admin take to verify or resolve the issue?

Trap 1: Enable 'set sip-nat-trace' on the policy

Running 'set sip-nat-trace' is a diagnostic tool that enables additional logging of SIP NAT traversal events in the FortiGate's debug output. It does not change how the SIP ALG processes or modifies packets; it simply makes the NAT/ALG translation steps visible for troubleshooting. Since the problem is that the ALG is actively corrupting SIP signaling, enabling tracing only shows you what is wrong, not fix it.

Trap 2: Enable 'set ssl-ssh-profile' on the policy

The 'ssl-ssh-profile' setting is unrelated to SIP ALG behavior because it controls deep inspection for HTTPS, SSH, and other encrypted protocols. Enabling one would toggle certificate inspection or decrypt/encrypt operations on SSL/SSH traffic, not affect the SIP application layer gateway. If a SIP ALG is rewriting SIP messages, SSL/SSH profiles have no influence over that process and would not reduce the failure.

Trap 3: Increase the session TTL for SIP

Raising the session TTL for SIP only increases how long a dormant or in-progress session is kept in the FortiGate's session table before being removed. The SIP ALG continues to interfere as long as it processes those sessions; a longer TTL doesn't stop ALG header rewriting or pinholing behavior. This option addresses call duration limits, not the packet-level corruption caused by ALG, so it leaves the root cause untouched.

A
Disable the SIP ALG on the firewall policy
Disabling the SIP ALG on the firewall policy (if supported in your FortiOS version via policy-level ALG control) stops the application-layer gateway from inspecting and rewriting SIP/SDP headers for sessions matching that policy. This prevents ALG-induced modifications such as Via/Contact header rewrites or RTP port changes that can break media streams. It is the most targeted fix because it only affects the policy in question, leaving ALG protection available for other SIP traffic that may still need NAT/ALG processing.
B
Enable 'set sip-nat-trace' on the policy
Why it fails: Running 'set sip-nat-trace' is a diagnostic tool that enables additional logging of SIP NAT traversal events in the FortiGate's debug output. It does not change how the SIP ALG processes or modifies packets; it simply makes the NAT/ALG translation steps visible for troubleshooting. Since the problem is that the ALG is actively corrupting SIP signaling, enabling tracing only shows you what is wrong, not fix it.
C
Enable 'set ssl-ssh-profile' on the policy
Why it fails: The 'ssl-ssh-profile' setting is unrelated to SIP ALG behavior because it controls deep inspection for HTTPS, SSH, and other encrypted protocols. Enabling one would toggle certificate inspection or decrypt/encrypt operations on SSL/SSH traffic, not affect the SIP application layer gateway. If a SIP ALG is rewriting SIP messages, SSL/SSH profiles have no influence over that process and would not reduce the failure.
D
Increase the session TTL for SIP
Why it fails: Raising the session TTL for SIP only increases how long a dormant or in-progress session is kept in the FortiGate's session table before being removed. The SIP ALG continues to interfere as long as it processes those sessions; a longer TTL doesn't stop ALG header rewriting or pinholing behavior. This option addresses call duration limits, not the packet-level corruption caused by ALG, so it leaves the root cause untouched.
E
Create a service object for SIP and set 'alg-mode' to 'disable'
Creating a service object for SIP with 'set alg-mode disable' is a valid way to stop the FortiGate's ALG from processing SIP traffic globally for that service object. This method affects every firewall policy that uses this SIP service, making it less granular than disabling the ALG only on the specific policy. Still, it is correct because it directly prevents the ALG from modifying SIP packets, which resolves the signaling/media interference.

Question 10mediummultiple choice

A network administrator configures a firewall policy allowing HTTP traffic from the internal network (10.0.0.0/8) to the internet. After applying the policy, users report they can browse the web, but the FortiGate logs show that all sessions are using the 'implicit deny' policy ID 0. What is the most likely cause?

Trap 1: Central NAT is enabled and overriding the policy-based NAT

Central NAT does not affect policy matching; it only changes NAT behavior.

Trap 2: The policy has a schedule applied that is currently inactive

If the schedule were inactive, the traffic would be denied, not allowed.

Trap 3: The policy is placed after the implicit deny rule

The implicit deny is always last; policies cannot be placed after it.

A
The source interface on the policy is set to the WAN interface instead of the internal interface
If the source interface is wrong, the traffic will not match this policy. The administrator may have a different policy (or the implicit allow) allowing the traffic, but the logs show the implicit deny is being hit because the correct policy is not matched.
B
Central NAT is enabled and overriding the policy-based NAT
Why it fails: Central NAT does not affect policy matching; it only changes NAT behavior.
C
The policy has a schedule applied that is currently inactive
Why it fails: If the schedule were inactive, the traffic would be denied, not allowed.
D
The policy is placed after the implicit deny rule
Why it fails: The implicit deny is always last; policies cannot be placed after it.

Question 11mediummultiple choice

An administrator wants to ensure that traffic from the engineering department (subnet 192.168.10.0/24) to the internet uses a specific public IP address for source NAT. Additionally, traffic from the marketing department (192.168.20.0/24) should use a different public IP. Which method should be used?

Trap 1: Configure a single Central SNAT rule with multiple source subnets…

A single IP pool cannot assign different IPs per subnet.

Trap 2: Use VIP for source NAT

VIP is for destination NAT, not source NAT.

Trap 3: Use a single policy with a dynamic IP pool that randomly assigns IPs

Random assignment would not guarantee different IPs per subnet.

A
Configure a single Central SNAT rule with multiple source subnets and a single IP pool
Why it fails: A single IP pool cannot assign different IPs per subnet.
B
Create two firewall policies, each with its own IP pool, for the respective subnets
This allows granular control over which IP is used for each subnet.
C
Use VIP for source NAT
Why it fails: VIP is for destination NAT, not source NAT.
D
Use a single policy with a dynamic IP pool that randomly assigns IPs
Why it fails: Random assignment would not guarantee different IPs per subnet.

Question 12mediummultiple choice

A FortiGate has two firewall policies: Policy 1 (from port1 to port2, source all, destination 10.0.1.0/24, schedule always, action accept) and Policy 2 (from port1 to port2, source all, destination all, schedule 'Business Hours', action accept). A user attempts to connect from port1 to 10.0.1.5 at 8 PM on a Saturday. The traffic is denied. What is the most likely reason?

Trap 1: Policy 1 only matches destination 10.0.1.10, and Policy 2's…

Incorrect. Policy 1 matches the entire subnet 10.0.1.0/24, not just 10.0.1.10.

Trap 2: The source address is not included in either policy

Incorrect. Both policies have source set to 'all', so the source address is included.

Trap 3: Policy 2 has an implicit deny action

Incorrect. Policy 2 has an action of 'accept', not 'implicit deny'.

A
Policy 1 only matches destination 10.0.1.10, and Policy 2's schedule is not active at this time
Why it fails: Incorrect. Policy 1 matches the entire subnet 10.0.1.0/24, not just 10.0.1.10.
B
The source address is not included in either policy
Why it fails: Incorrect. Both policies have source set to 'all', so the source address is included.
C
Policy 1 is placed below Policy 2 in the policy order, so Policy 2 is evaluated first
Correct. Policy 1 is below Policy 2, so Policy 2 is evaluated first. Its schedule is inactive, causing it to be skipped, leading to the eventual implicit deny if no other policy matches.
D
Policy 2 has an implicit deny action
Why it fails: Incorrect. Policy 2 has an action of 'accept', not 'implicit deny'.

Question 13mediummultiple choice

An administrator runs 'diagnose sys session filter dport 443' and sees the following output: proto=6 proto_state=01 duration=3600 expire=3599 What does this indicate about the session?

Trap 1: The session is a UDP session because the proto_state is 01

proto=6 indicates TCP, not UDP.

Trap 2: The session has been closed and is being removed from the session…

A closing session would have a different state, not SYN_SENT.

Trap 3: The session is fully established and has been active for 3600…

proto_state=01 indicates SYN_SENT, not established (which would be 02 or higher).

A
The session is in the process of being established and has not completed the TCP three-way handshake
proto_state=01 means the first SYN has been sent but no SYN-ACK received, indicating the handshake is incomplete.
B
The session is a UDP session because the proto_state is 01
Why it fails: proto=6 indicates TCP, not UDP.
C
The session has been closed and is being removed from the session table
Why it fails: A closing session would have a different state, not SYN_SENT.
D
The session is fully established and has been active for 3600 seconds
Why it fails: proto_state=01 indicates SYN_SENT, not established (which would be 02 or higher).

Read the full DNS explanation →

Question 14easymultiple choice

Which type of address object allows a FortiGate to perform DNS resolution to match traffic based on a domain name?

Trap 1: Subnet

A Subnet object represents a fixed IPv4 or IPv6 address range defined by an IP address and netmask, such as 192.0.2.0/24. It has no association with a domain name and cannot perform DNS resolution. Since the correct answer must be an address object that resolves a domain via DNS, Subnet is clearly not applicable.

Trap 2: Geography

A Geography address object matches traffic based on geographic location, specifically by mapping source or destination IP addresses to countries using the FortiGuard geolocation database. It does not use domain names at all, and no DNS resolution is involved. Therefore, Geography cannot perform the domain-based dynamic resolution described in the question.

A
Wildcard FQDN
A Wildcard FQDN object matches multiple domain names using a pattern such as *.example.com, and while it does rely on DNS, it is not the specific type used for a single, exact domain name. The question asks about resolving a single domain, which is strictly the FQDN object type. Wildcard FQDN is therefore incorrect here because it broadens the match beyond the exact hostname.
B
Subnet
Why it fails: A Subnet object represents a fixed IPv4 or IPv6 address range defined by an IP address and netmask, such as 192.0.2.0/24. It has no association with a domain name and cannot perform DNS resolution. Since the correct answer must be an address object that resolves a domain via DNS, Subnet is clearly not applicable.
C
FQDN
An FQDN address object stores a single fully qualified domain name, such as www.example.com, and the FortiGate resolves it to its current IP address(es) using configured DNS servers. It periodically re-resolves the name based on the DNS TTL to keep the address up to date. This is the exact type of address object that allows DNS-based resolution for a single domain in FortiOS.
D
Geography
Why it fails: A Geography address object matches traffic based on geographic location, specifically by mapping source or destination IP addresses to countries using the FortiGuard geolocation database. It does not use domain names at all, and no DNS resolution is involved. Therefore, Geography cannot perform the domain-based dynamic resolution described in the question.

Question 15mediummultiple choice

A FortiGate admin configures a VIP to map 203.0.113.10:80 to 10.0.1.10:8080. However, when external users connect to http://203.0.113.10, they receive a connection timeout. The firewall policy allows the traffic. What is the most likely cause?

Trap 1: The VIP is configured on the wrong interface

VIPs are typically bound to the incoming interface (WAN), so that should be correct.

Trap 2: The source NAT is not configured

Source NAT is not required for inbound traffic; destination NAT is what matters.

Trap 3: The internal server is not listening on port 8080

The server might be listening, but the timeout suggests no response; however, the policy issue is more likely.

A
The VIP is configured on the wrong interface
Why it fails: VIPs are typically bound to the incoming interface (WAN), so that should be correct.
B
The source NAT is not configured
Why it fails: Source NAT is not required for inbound traffic; destination NAT is what matters.
C
The firewall policy's destination is set to the real server IP (10.0.1.10) instead of the VIP object
The policy must use the VIP as the destination address for the destination NAT to work correctly. If it uses the real server IP, the traffic bypasses the VIP translation.
D
The internal server is not listening on port 8080
Why it fails: The server might be listening, but the timeout suggests no response; however, the policy issue is more likely.

Question 16hardmultiple choice

An admin configures a one-to-one IP Pool to map 10.0.1.0/28 to 203.0.113.16/28. A host with IP 10.0.1.5 initiates a connection to the internet. Which source IP will be used for the translated packet?

Trap 1: 203.0.113.20

The external address 203.0.113.20 equals the pool base of 203.0.113.16 plus a host offset of 4. In a one-to-one IP pool, the internal host's low-order bits within the /28 are preserved onto the external range; therefore offset 4 maps to internal 10.0.1.4, not 10.0.1.5. Picking .20 would translate for the wrong internal device, breaking the intended mapping.

Trap 2: 203.0.113.5

Choosing 203.0.113.5 incorrectly treats the public address as a direct replacement of the private host octet. The one-to-one mapping operates on the entire /28 subnet boundary: private host .5 must be located at the same positional offset from the start of the external range, which starts at .16. Since .5 falls outside the external pool's range .16–.31, it cannot be a valid NAT address for this configuration.

Trap 3: 203.0.113.16

203.0.113.16 is the first address of the external range, representing offset 0. In a /28, offset 0 corresponds to the network address of the internal subnet, 10.0.1.0, which is not a host-assignable address. Therefore .16 cannot represent internal .5; the correct offset would need to be 5, not 0.

A
203.0.113.20
Why it fails: The external address 203.0.113.20 equals the pool base of 203.0.113.16 plus a host offset of 4. In a one-to-one IP pool, the internal host's low-order bits within the /28 are preserved onto the external range; therefore offset 4 maps to internal 10.0.1.4, not 10.0.1.5. Picking .20 would translate for the wrong internal device, breaking the intended mapping.
B
203.0.113.21
Because the internal network is 10.0.1.0/28, host .5 has an offset of 5 from the network base. The external pool is 203.0.113.16/28, so the corresponding external address is 203.0.113.16 + 5 = 203.0.113.21. This offset-preservation is the core mechanic of one-to-one NAT, ensuring a fixed reversible mapping for inbound and outbound traffic.
C
203.0.113.5
Why it fails: Choosing 203.0.113.5 incorrectly treats the public address as a direct replacement of the private host octet. The one-to-one mapping operates on the entire /28 subnet boundary: private host .5 must be located at the same positional offset from the start of the external range, which starts at .16. Since .5 falls outside the external pool's range .16–.31, it cannot be a valid NAT address for this configuration.
D
203.0.113.16
Why it fails: 203.0.113.16 is the first address of the external range, representing offset 0. In a /28, offset 0 corresponds to the network address of the internal subnet, 10.0.1.0, which is not a host-assignable address. Therefore .16 cannot represent internal .5; the correct offset would need to be 5, not 0.

Question 17easymultiple choice

Which of the following is the default action of a FortiGate firewall policy if no policy matches the traffic?

Trap 1: Log and drop

Logging requires explicit configuration; implicit deny does not log by default.

Trap 2: Redirect to authentication

FortiGate's implicit deny drops unmatched traffic silently; authentication redirect occurs only where an explicit policy or captive portal invokes it. The option confuses a configured feature with default behaviour, tempting because authentication policies are common in guest-access designs, yet they must be defined deliberately.

Trap 3: Accept

FortiGate applies an implicit deny that blocks unmatched traffic; acceptance never happens by default. The option reflects a permissive mental model, tempting because explicit accept policies are numerous in real configurations, yet each must be created deliberately to permit traffic.

A
Log and drop
Why it fails: Logging requires explicit configuration; implicit deny does not log by default.
B
Redirect to authentication
Why it fails: FortiGate's implicit deny drops unmatched traffic silently; authentication redirect occurs only where an explicit policy or captive portal invokes it. The option confuses a configured feature with default behaviour, tempting because authentication policies are common in guest-access designs, yet they must be defined deliberately.
C
Accept
Why it fails: FortiGate applies an implicit deny that blocks unmatched traffic; acceptance never happens by default. The option reflects a permissive mental model, tempting because explicit accept policies are numerous in real configurations, yet each must be created deliberately to permit traffic.
D
Deny
FortiGate applies an implicit deny at the end of policy evaluation, so unmatched traffic is dropped without logging by default. This satisfies the stem's requirement for the default action when no explicit policy matches, reflecting FortiOS's default-deny security posture rather than any permit-any fallback.

Question 18mediummulti select

A FortiGate admin wants to ensure that traffic from the internal network (192.168.1.0/24) to the internet uses a specific public IP (203.0.113.10) for source NAT, and that the same public IP is also used for inbound connections to an internal web server (10.0.1.10) on port 443. Which TWO configurations are required? (Choose two.)

Trap 1: Create a firewall policy with source NAT enabled and the IP Pool…

While a policy is needed, the question asks for configurations, not the policy itself. But the question says 'configurations required', and a policy is essential; however, the two most specific are the IP Pool and VIP objects. The policy is also required but is not listed as an option? Actually option D is a policy configuration. But the question says 'Choose two' and the correct ones are A and B. Option D is a policy action, not an object. But let's see: The admin needs to configure an IP Pool and a VIP. The policy will reference them. So A and B are the objects. Option D is also needed but not the primary objects. The question might consider D as correct? But the stem says 'Which TWO configurations are required?' The typical answer is IP Pool and VIP. I'll keep A and B as correct.

Trap 2: Configure Central SNAT with the same public IP

Central SNAT could be used, but an IP Pool is more specific and the question implies policy-based NAT. However, both can work; but the pair of needed items are IP Pool and VIP. Central SNAT would replace the IP Pool, but then the VIP is still needed. The question expects the traditional approach.

A
Configure an IP Pool with type Overload using 203.0.113.10
This provides source NAT for outbound traffic using the required public IP.
B
Configure a Virtual IP mapping 203.0.113.10:443 to 10.0.1.10:443
This provides destination NAT for inbound HTTPS traffic.
C
Create a firewall policy with source NAT enabled and the IP Pool selected
Why it fails: While a policy is needed, the question asks for configurations, not the policy itself. But the question says 'configurations required', and a policy is essential; however, the two most specific are the IP Pool and VIP objects. The policy is also required but is not listed as an option? Actually option D is a policy configuration. But the question says 'Choose two' and the correct ones are A and B. Option D is a policy action, not an object. But let's see: The admin needs to configure an IP Pool and a VIP. The policy will reference them. So A and B are the objects. Option D is also needed but not the primary objects. The question might consider D as correct? But the stem says 'Which TWO configurations are required?' The typical answer is IP Pool and VIP. I'll keep A and B as correct.
D
Configure Central SNAT with the same public IP
Why it fails: Central SNAT could be used, but an IP Pool is more specific and the question implies policy-based NAT. However, both can work; but the pair of needed items are IP Pool and VIP. Central SNAT would replace the IP Pool, but then the VIP is still needed. The question expects the traditional approach.

Question 19hardmultiple choice

An administrator configures a VIP for inbound HTTP traffic to an internal server (192.168.1.10:80). External users can reach the server via the VIP, but internal users on the same subnet as the server cannot access the server using its public IP. What is the most likely cause?

Trap 1: The internal users do not have a route to the VIP's public IP

Internal users normally have a default route that points to the FortiGate, so they can reach the VIP's public IP address at the routing level. Even if a specific route existed, the FortiGate would still receive the packet and perform destination NAT; the failure to loop the translated packet back to the internal client is what causes the issue. Therefore, the absence of a route is not the reason internal users cannot access the VIP.

Trap 2: The firewall policy for internal-to-DMZ traffic has NAT disabled

Disabling NAT in the internal-to-DMZ policy affects source NAT (SNAT) for sessions initiated from internal users to the DMZ server, but it does not disable the destination NAT performed by the VIP object. For hairpin traffic, the FortiGate still applies the VIP's destination translation regardless of the policy's NAT setting. The real problem is that the FortiGate does not support source NAT reflection unless NAT reflection is explicitly enabled on the VIP.

Trap 3: The VIP is configured on the wrong interface

A VIP can be bound to multiple interfaces, and even if it is configured on the WAN interface, traffic from internal users arrives on an internal interface; the FortiGate still matches the VIP based on the destination IP address. The interface binding of the VIP does not prevent internal users from sending packets to the public IP, because the FortiGate intercepts them. The failure occurs during the return-path translation, which is governed by NAT reflection settings, not by the interface assignment.

A
The internal users do not have a route to the VIP's public IP
Why it fails: Internal users normally have a default route that points to the FortiGate, so they can reach the VIP's public IP address at the routing level. Even if a specific route existed, the FortiGate would still receive the packet and perform destination NAT; the failure to loop the translated packet back to the internal client is what causes the issue. Therefore, the absence of a route is not the reason internal users cannot access the VIP.
B
The firewall policy for internal-to-DMZ traffic has NAT disabled
Why it fails: Disabling NAT in the internal-to-DMZ policy affects source NAT (SNAT) for sessions initiated from internal users to the DMZ server, but it does not disable the destination NAT performed by the VIP object. For hairpin traffic, the FortiGate still applies the VIP's destination translation regardless of the policy's NAT setting. The real problem is that the FortiGate does not support source NAT reflection unless NAT reflection is explicitly enabled on the VIP.
C
The VIP is configured on the wrong interface
Why it fails: A VIP can be bound to multiple interfaces, and even if it is configured on the WAN interface, traffic from internal users arrives on an internal interface; the FortiGate still matches the VIP based on the destination IP address. The interface binding of the VIP does not prevent internal users from sending packets to the public IP, because the FortiGate intercepts them. The failure occurs during the return-path translation, which is governed by NAT reflection settings, not by the interface assignment.
D
NAT reflection (hairpin NAT) is not enabled
NAT reflection (hairpin NAT) is required when internal users access a VIP using its public IP address from the internal network. Without it, the FortiGate translates the destination to the DMZ server's private IP but does not translate the source IP back to the internal network, causing the server to reply to the FortiGate's internal interface, which breaks the session. Enabling NAT reflection on the VIP or using Central NAT with NAT reflection allows the FortiGate to properly hairpin the traffic back to the internal client.

Question 20hardmultiple choice