43 of 193 questions · Page 3/3 · Firewall Policies and NAT · Answers revealed
Drag and drop the steps to create a firewall policy allowing HTTP traffic from internal to DMZ into the correct order.
Drag or tap steps into the slots.
Why this order
Firewall policies require defining interfaces, source/destination addresses, and services before enabling.
Which statement best describes the implicit deny policy at the end of a FortiGate policy list?
The implicit deny is always present as the last effective rule in the FortiGate policy list, regardless of how many explicit policies are configured. Any traffic that does not match an explicit allow policy is dropped by this default rule, ensuring that all unmatched packets are blocked. This is a mandatory security control that cannot be removed or repositioned, providing a safe default deny posture.
Why this answer
The implicit deny policy is a built-in, last-resort rule at the bottom of the FortiGate policy list that silently drops any traffic not matching an explicit allow policy. It cannot be moved, disabled, or deleted because it is a fundamental security mechanism ensuring that only explicitly permitted traffic is allowed through the firewall.
Exam trap
The trap here is that candidates often think the implicit deny can be configured or removed like an explicit policy, but FortiGate enforces it as an unchangeable, always-present rule that cannot be logged or repositioned.
How to eliminate wrong answers
Option A is wrong because the implicit deny policy does not log denied traffic by default; logging must be explicitly configured on an explicit deny policy. Option B is wrong because the implicit deny policy is fixed at the very end of the policy list and cannot be repositioned. Option C is wrong because the implicit deny policy is a permanent, non-removable safeguard that cannot be disabled or deleted by the administrator.
A FortiGate administrator needs to ensure that all internal users (10.0.0.0/8) accessing the internet use a single public IP address 203.0.113.10 for source NAT. Which NAT configuration should be used?
A Central SNAT rule with a Dynamic IP Pool in overload mode references a configured pool of public addresses and applies source network address translation independently of firewall policies. Overload (PAT) creates a unique mapping of internal IP:port to the selected public IP:port, allowing many internal users to share a single public address. This is the appropriate method when the required public IP is not the interface IP and must be shared by all internal clients.
Why this answer
Central SNAT with a Dynamic IP Pool using overload (Port Address Translation) allows all internal users in 10.0.0.0/8 to share a single public IP (203.0.113.10) by dynamically mapping multiple private source IPs and ports to unique source ports on the public IP. This is the standard method for many-to-one NAT, ensuring all outbound internet traffic appears from the same public address.
Exam trap
The trap here is that candidates often confuse enabling NAT on the interface policy (Option B) with using a specific IP pool, not realizing that interface NAT uses the interface's own IP and cannot force a different public address without an explicit IP pool.
How to eliminate wrong answers
Option B is wrong because enabling NAT on the outgoing interface policy without an IP pool uses the interface's own IP address (typically the WAN IP) for source NAT, not a specific public IP like 203.0.113.10, and may not guarantee a single IP if the interface has multiple addresses. Option C is wrong because a policy-based NAT rule with fixed port range would restrict the number of concurrent sessions to the size of the port range, causing connection failures under load, and is not designed for many-to-one overload NAT. Option D is wrong because a VIP with port forwarding is used for inbound destination NAT (port mapping to internal servers), not for outbound source NAT from internal users to the internet.
A FortiGate administrator needs to allow all internal users (10.0.0.0/8) to access a web server in the DMZ (192.168.1.100) using HTTPS. The administrator wants to apply a web filter profile to block malicious URLs while allowing legitimate traffic. Which of the following is the correct policy configuration?
This policy precisely matches the requirement: the HTTPS service object maps to TCP port 443, allowing encrypted web sessions from internal users to the DMZ, while action=ACCEPT forwards the traffic. The web filter profile is applied after the traffic is accepted, enabling URL and content inspection of the HTTPS sessions, provided that SSL inspection (deep or certificate-based) is already configured on the FortiGate. This is the only option that both permits the required traffic and enforces the intended security control.
Why this answer
The policy must match the HTTPS service (TCP/443) to allow encrypted web traffic to the DMZ web server, and the web filter profile is applied to inspect the HTTPS traffic for malicious URLs. The default web filter profile can block malicious URLs while allowing legitimate HTTPS traffic, provided SSL inspection is configured to enable content filtering.
Exam trap
The trap here is that candidates often confuse the service requirement (HTTPS vs HTTP) or assume that applying a web filter profile to HTTPS traffic works without SSL inspection, leading them to select option B or A, or they mistakenly think a DENY action with a web filter profile can still allow traffic.
How to eliminate wrong answers
Option A is wrong because it uses service=ALL, which would allow all protocols (including non-web traffic) unnecessarily, violating the principle of least privilege and potentially exposing the DMZ to unwanted traffic. Option B is wrong because it specifies service=HTTP (TCP/80), but the requirement is to access the web server using HTTPS (TCP/443), so HTTP would not match the traffic and the policy would not be applied. Option D is wrong because action=DENY would block all HTTPS traffic to the web server, preventing access entirely, which contradicts the requirement to allow legitimate traffic.
A FortiGate with multiple WAN interfaces uses policy-based routing (PBR) to route traffic from a specific subnet out of a particular interface. The admin also has a firewall policy allowing that subnet to the internet. However, the traffic is not being routed as expected. What could be the issue?
Policy routes are matched against the source and destination addresses specified in the rule; if either address does not overlap the actual traffic's addresses, the PBR lookup will not produce a match. As a result, the traffic falls through to the regular routing table and may be sent out a different WAN interface. This is the most direct and common reason a PBR rule is silently ignored.
Why this answer
Policy-based routing (PBR) is evaluated before firewall policies. If the PBR rule specifies an incorrect source or destination address, traffic from the intended subnet will not match the PBR rule and will fall through to the default routing table, potentially exiting via a different interface. The firewall policy alone cannot override the routing decision; the PBR rule must correctly identify the traffic to steer it to the desired egress interface.
Exam trap
The trap here is that candidates often assume firewall policy order or missing service definitions are the root cause, when in fact PBR's address matching is the precise mechanism that must be correctly configured for traffic to be routed as intended.
How to eliminate wrong answers
Option A is wrong because firewall policies are evaluated after PBR rules; the order of firewall policies relative to PBR rules does not affect routing decisions. Option B is wrong because PBR rules do not require a protocol or service definition—they can match based solely on source/destination addresses; omitting these fields does not prevent the rule from applying. Option D is wrong because transparent mode does not affect PBR functionality; PBR operates at Layer 3 and is available in both NAT/Route and transparent modes, though transparent mode typically bridges traffic rather than routing it.
A FortiGate admin configures a firewall policy to allow outbound HTTP traffic and applies a web filter profile. The admin notices that some users can access a known malicious URL while others are blocked. All users are in the same source subnet (10.0.1.0/24). What is the MOST likely cause of this inconsistent behavior?
This is the correct answer because FortiGate firewall policies are matched in order of policy ID (and any explicit sequencing), and the first matching policy is enforced. If a higher-priority policy (lower policy ID) matches certain users' traffic (e.g., based on source IP, user group, or interface) and that policy lacks a web filter profile, those users bypass the intended filtering entirely, while others match the intended lower-priority policy that has the restrictive web filter profile.
Why this answer
When multiple firewall policies match traffic from the same source subnet, FortiGate uses the first matching policy in order (lowest policy ID). If a higher-priority policy with a different web filter profile matches some users' traffic (e.g., based on source port or application), those users will have different filtering behavior. This is a classic policy ordering issue where the intended web filter profile is not applied consistently to all users in the same subnet.
Exam trap
The trap here is that candidates assume all traffic from the same subnet is treated identically, overlooking that FortiGate policy matching is first-match and can differentiate based on other attributes like source port or user identity, leading to inconsistent profile application.
How to eliminate wrong answers
Option A is wrong because FortiGate does not use an external proxy server for web filtering by default; it uses local proxy-based inspection or flow-based inspection, and caching is not a factor in inconsistent web filter results. Option B is wrong because FortiGuard ratings are consistent per URL and do not vary per user; if the rating is inconsistent, it would affect all users equally, not selectively. Option C is wrong because FQDN resolution in firewall policies is performed by the FortiGate itself, not per user; DNS load balancing would return different IPs to the FortiGate, but the FortiGate resolves the FQDN once and uses that single IP for policy matching, so it cannot cause per-user differences.
An administrator configures a firewall policy with source address 'internal_net' (10.0.0.0/16) and destination address 'server_farm' (10.10.10.0/24). The action is set to ACCEPT with NAT enabled. However, traffic from 10.0.1.100 to 10.10.10.50 is being denied. What is the most likely cause?
FortiGate firewall policies are evaluated sequentially from top to bottom, and the first policy that matches source, destination, and service is executed. If there is a deny policy positioned above this allow policy and it matches the same traffic, the deny action takes precedence and the packet is blocked before ever reaching the allow rule. This is the most likely explanation for why traffic is not permitted, even though the allow policy appears correct.
Why this answer
The most likely cause is that a deny policy with a higher priority (lower sequence number) exists above the ACCEPT policy in the firewall policy list. FortiGate evaluates policies sequentially from top to bottom, and the first matching policy determines the action. If a deny policy matches the traffic (source 10.0.1.100, destination 10.10.10.50) before the ACCEPT policy is reached, the traffic will be denied regardless of the ACCEPT policy below it.
Exam trap
The trap here is that candidates often assume the configured ACCEPT policy will apply because it matches the traffic, forgetting that FortiGate uses first-match logic and a higher-priority deny policy can override it.
How to eliminate wrong answers
Option A is wrong because the destination address 'server_farm' is defined as 10.10.10.0/24, which includes 10.10.10.50. Option C is wrong because NAT (source NAT or IP pool) does not cause traffic to be dropped; it only translates the source address, and if the NAT configuration were invalid, the traffic would still be processed but might fail to translate, not be denied. Option D is wrong because the source address 'internal_net' is defined as 10.0.0.0/16, which includes 10.0.1.100.
Which of the following statements about FortiGate policy lookup order is correct?
FortiGate firewall policies are evaluated sequentially from the top of the policy list. The first policy whose source, destination, service, and other matching criteria align with the session's attributes is selected and enforced. Because evaluation stops at the first match, placing more specific rules above broader ones is critical for proper traffic control.
Why this answer
FortiGate uses a top-down sequential search for policy matching. When a packet arrives, the firewall starts at the top of the policy list and evaluates each policy in order until it finds one where all configured criteria (source, destination, service, schedule, etc.) match. The first matching policy is then applied, and no further policies are checked.
This is the fundamental behavior of FortiGate's firewall policy lookup.
Exam trap
The trap here is that candidates often confuse FortiGate's sequential top-down evaluation with other firewall platforms (like Cisco ASA) that use a priority-based or implicit-rule model, leading them to incorrectly select Option B or C.
How to eliminate wrong answers
Option B is wrong because FortiGate does not assign a numeric priority to each policy; the order in the policy list (sequence number) determines the evaluation order, not a separate priority field. Option C is wrong because FortiGate evaluates policies from top to bottom, not bottom to top; the last matching policy would never be used unless it is the first match from the top. Option D is wrong because FortiGate does not use random selection for policy matching; it strictly follows the sequential top-down order to ensure deterministic and predictable traffic handling.
A FortiGate administrator needs to ensure that traffic from the LAN (192.168.1.0/24) to the DMZ (10.0.0.0/24) uses a specific outbound interface (port3) instead of the default route. Which feature should be configured to achieve this?
Policy-based routing (PBR) in a firewall policy matches traffic using firewall-level criteria such as source address, destination address, user, or application, and then overrides the routing table by defining a specific next-hop gateway and egress interface. This lets the administrator force selected internal traffic out port3 while all other traffic continues to use the normal destination-based routing table.
Why this answer
Policy-based routing (PBR) allows the FortiGate to override the routing table for specific traffic based on criteria defined in a firewall policy, such as source and destination addresses. By configuring a PBR rule that matches traffic from 192.168.1.0/24 to 10.0.0.0/24 and setting the outbound interface to port3, the administrator can force this traffic to use port3 instead of the default route. This is the correct feature for interface-based path selection that is not based on destination prefix alone.
Exam trap
The trap here is that candidates often confuse policy-based routing (PBR) with static routes or SD-WAN, assuming that a static route with a higher administrative distance can override the default route for specific source-destination pairs, but static routes are destination-based and cannot match on source IP or other L4 criteria without PBR.
How to eliminate wrong answers
Option A is wrong because a static route with a higher distance would be less preferred than the default route (which typically has a lower distance), so it would not override the default route for the specified traffic. Option B is wrong because a Virtual IP (VIP) with port forwarding is used for destination NAT (port forwarding) to translate public IP addresses to private ones, not to influence routing decisions or outbound interface selection. Option D is wrong because an SD-WAN rule can steer traffic to a specific interface, but SD-WAN requires the interfaces to be members of an SD-WAN zone and is designed for WAN link load balancing, not for simple interface override in a LAN-to-DMZ scenario without SD-WAN being enabled.
A network admin needs to log all traffic from the sales VLAN to the internet. The firewall policy is configured with logging enabled. However, the admin notices that only session start logs are generated, not detailed traffic logs. What setting must be enabled to capture per-packet or per-session details?
Setting the log generation to 'All Sessions' in the firewall policy is the direct and complete way to fulfill the requirement. This configures FortiGate to create a forward traffic log entry for every session that matches the policy, including details like source/destination IP, port, and session duration. By selecting this option, the administrator ensures that no session is omitted, unlike the default 'Security Events' mode which only records sessions that trigger a security action.
Why this answer
In FortiGate, the 'Log Generation' setting on a firewall policy controls whether logs are generated for session start only or for all sessions. By default, a policy may log only session start events; setting it to 'All sessions' ensures that per-session details (including traffic volume, duration, and packet counts) are recorded. This is distinct from enabling security profiles, which inspect traffic but do not change the logging verbosity.
Exam trap
The trap here is that candidates often confuse enabling security profiles (like UTM features) with increasing log verbosity, but security profiles only inspect content and do not change the policy's log generation setting from 'Session start' to 'All sessions'.
How to eliminate wrong answers
Option A is wrong because 'Log Memory' is not a valid setting on a FortiGate firewall policy; memory logging is a global setting for storing logs locally, not a per-policy toggle for detailed logs. Option B is wrong because enabling security profiles (e.g., antivirus, web filter) adds inspection but does not alter the log generation mode from session-start to all-sessions; detailed traffic logs require the policy's log generation setting to be changed. Option D is wrong because a traffic shaper controls bandwidth allocation and QoS, not logging verbosity; it has no effect on whether per-packet or per-session details are captured.
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?
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.
Why this answer
Enabling NAT on the firewall policy with the outgoing interface address is the standard method for source NAT (masquerading) in FortiGate. This configuration translates all internal source IPs (192.168.1.0/24) to the single IP address of the egress interface, hiding the internal subnet from the internet. It is the simplest and most efficient approach for typical internet-bound traffic, requiring no additional objects like IP pools or VIPs.
Exam trap
The trap here is that candidates often confuse VIPs (destination NAT) with source NAT, or assume that a one-to-one IP pool is required for hiding internal IPs, when in fact interface NAT with PAT is the default and best practice for internet-bound traffic in FortiGate.
How to eliminate wrong answers
Option A is wrong because a Virtual IP (VIP) is used for destination NAT (port forwarding), not source NAT; applying a VIP to hide internal IPs would incorrectly translate destination addresses instead of source addresses. Option B is wrong because policy-based routing (PBR) controls the path traffic takes based on routing policies, not NAT; it does not perform address translation and would require a separate NAT device, which is unnecessary in FortiGate. Option D is wrong because a one-to-one IP pool maps each internal IP to a unique external IP, which is overkill and wasteful for hiding a subnet behind a single public IP; dynamic IP pools (overload) or interface NAT are more appropriate for many-to-one masquerading.
Which of the following best describes a Virtual IP (VIP) in FortiGate?
A FortiGate VIP maps an external public IP and port to an internal private IP and port, enabling inbound destination NAT for published services. This precisely matches the inbound translation definition rather than outbound source NAT or routing.
Why this answer
A Virtual IP (VIP) in FortiGate is used for Destination NAT (DNAT), translating an incoming public IP address and port to a private IP address and port. This allows external hosts to access internal servers (e.g., web servers) using a public IP, while the server remains on a private RFC 1918 address. The VIP object is referenced in a firewall policy to permit the inbound traffic and perform the translation.
Exam trap
The trap here is confusing Virtual IP (Destination NAT) with IP Pool (Source NAT), as both involve address translation but serve opposite traffic directions; candidates often pick Option B thinking VIP is for outbound translation.
How to eliminate wrong answers
Option B is wrong because it describes Source NAT (SNAT) or IP Pool, not a Virtual IP; SNAT translates private source IPs to a public IP for outbound traffic. Option C is wrong because grouping multiple firewall policies is done using policy packages or policy groups, not a Virtual IP. Option D is wrong because load balancing traffic across multiple WAN interfaces is achieved using SD-WAN or ECMP routing, not a Virtual IP; VIPs can be used for server load balancing (SLB) but not for balancing across WAN interfaces.
An administrator needs to configure a firewall policy to allow outbound traffic from the internal network to the internet. The internal network uses private IP addresses, and the administrator wants to hide these addresses from the internet. Which NAT configuration should be applied to the policy?
Enabling NAT on the policy and using the outgoing interface address translates the source IP of internal hosts to the IP address of the FortiGate's outgoing interface. This hides private addresses and allows return traffic to be routed back correctly. It is the standard configuration for outbound NAT (many-to-one or many-to-many depending on the pool).
Why this answer
For outbound traffic from a private network to the internet, source NAT (SNAT) is required to translate private IP addresses to a public IP address. The most common and straightforward method on a FortiGate is to enable NAT on the firewall policy and use the outgoing interface address. This translates all internal addresses to the IP of the FortiGate's external interface, allowing return traffic to be routed back.
Exam trap
The trap here is confusing central NAT with policy-based NAT; central NAT is a separate feature and not needed for simple outbound NAT.
Which TWO statements about firewall policy authentication are correct?
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.
Why this answer
FortiGate firewall policies allow authentication to be enabled on a per-policy basis using the 'set auth-on-demand' or 'set auth-cert' options, which enforce user authentication before traffic is processed. This granular control enables administrators to apply authentication only to specific policies, such as those controlling access to sensitive resources, without affecting other traffic flows.
Exam trap
The trap here is that candidates often assume authentication is only for inbound traffic or that it happens after policy allowance, but FortiGate enforces authentication as a prerequisite to policy matching, not as a post-allowance step.
Which statement about the implicit deny policy at the bottom of the firewall policy list is true?
This is precisely the behavior of the implicit deny policy: it drops (or denies) any traffic that does not match an explicit firewall policy. When a packet arrives, FortiGate evaluates the policy list from top to bottom; if no explicit policy matches, the packet falls through to this built-in final rule and is denied without generating an explicit log entry unless logging is enabled on the corresponding policy. This ensures that any unclassified or misconfigured traffic is blocked by default, upholding a least-privilege security model.
Why this answer
The implicit deny policy is a built-in, unchangeable rule at the bottom of the FortiGate firewall policy list that drops all traffic not matching any explicit policy. It ensures that only explicitly permitted traffic is allowed, enforcing a default-deny security posture. This policy cannot be edited, removed, or reordered, and it applies to all traffic regardless of source.
Exam trap
The trap here is that candidates often think the implicit deny policy can be edited or removed because they confuse it with an explicit deny policy that they can create and modify, but the implicit deny is a fixed, unchangeable rule at the bottom of the list.
How to eliminate wrong answers
Option A is wrong because the implicit deny policy applies to all traffic, not just traffic from the internet; it covers internal, DMZ, and any other interface traffic as well. Option B is wrong because the implicit deny policy is hardcoded and cannot be edited; its action is permanently set to deny and cannot be changed to accept. Option C is wrong because the implicit deny policy is mandatory and cannot be removed; it is always present at the bottom of the policy list and is not optional.
An administrator configures a firewall policy with a schedule object that is set to 'Available: Mon-Fri 09:00-17:00'. At 10:00 AM on Saturday, users report they cannot access the resource. The administrator checks the policy list and sees the policy is enabled. What is the MOST likely reason?
The schedule object defined as 'Mon-Fri 09:00-17:00' explicitly restricts allowed days to Monday through Friday. On Saturday, the current time falls outside the schedule's active period, so the policy's schedule condition is not met. Consequently, the FortiGate skips this policy and evaluates subsequent policies, eventually hitting the implicit deny rule that drops the traffic. This is a standard behavior: a firewall policy with a time-based schedule is inactive outside its defined window.
Why this answer
The schedule object is configured to allow traffic only from Monday to Friday, 09:00-17:00. Since Saturday is outside this range, the firewall policy will deny or not match the traffic, even though the policy is enabled. This is the most direct and likely reason for the access failure.
Exam trap
The trap here is that candidates may overlook the schedule's day-of-week restriction and assume the policy is simply 'enabled' means it should work, failing to recognize that a schedule object can limit traffic to specific days and times, making the policy inactive outside those windows.
How to eliminate wrong answers
Option A is wrong because an incorrect system time would affect all schedule-based policies, but the issue is specifically tied to the day of the week (Saturday), not a time drift; moreover, the administrator would likely notice other time-related anomalies. Option B is wrong because a deny policy with higher priority would block traffic regardless of the schedule, but the question states the policy is enabled and the schedule is the only configured restriction; there is no indication of a conflicting deny rule. Option C is wrong because the schedule object is correctly applied to the policy (the administrator sees the policy in the list with the schedule), and the issue is that the schedule itself does not include Saturday, not that it is misapplied.
An administrator needs to translate a single internal server (192.168.1.10:8080) to a public IP (203.0.113.10:80) so that external users can access it via HTTP. Which type of VIP should be configured?
Port Forwarding VIP is correct because it provides a destination NAT rule that maps a specific external IP address and port combination to a specific internal IP address and port combination. This allows an administrator to expose exactly one service (e.g., HTTPS on port 443) from a single internal server while hiding all other ports, and it conserves public IP addresses. In FortiOS, this is configured as a VIP with the 'port-forwarding' option enabled, which creates a one-to-one mapping of the destination port and optionally a different source port.
Why this answer
Port Forwarding VIP (also called DNAT or destination NAT) is the correct choice because it translates a single internal server's IP and port (192.168.1.10:8080) to a specific public IP and port (203.0.113.10:80), allowing external HTTP users to reach the internal server. This is a one-to-one mapping of a public IP:port to a private IP:port, which is the exact definition of port forwarding in FortiGate.
Exam trap
The trap here is that candidates often confuse Static NAT (one-to-one IP mapping) with Port Forwarding VIP, forgetting that Static NAT translates all ports and does not allow port remapping, while Port Forwarding VIP specifically handles port translation.
How to eliminate wrong answers
Option A is wrong because Server Load Balancing VIP distributes traffic across multiple backend servers using a virtual server IP, not a single internal server mapping. Option B is wrong because a Virtual IP (VIP) with no port forwarding would map the entire public IP to the private IP without changing the port, so external users on port 80 would not reach port 8080. Option C is wrong because Static NAT (one-to-one VIP) maps an entire public IP to an entire private IP (all ports), not a specific port translation like 8080 to 80.
A network administrator needs to allow only HTTPS traffic from the internal network (10.0.0.0/8) to the public DNS server (8.8.8.8). Which firewall policy configuration BEST enforces this restriction?
This rule is correct because it precisely matches the three constraints: the internal source subnet 10.0.0.0/8, the specific destination IP 8.8.8.8, and the well-known HTTPS service (TCP/443). FortiGate evaluates the source address, destination address, and service object together; when all three match, the Accept action permits the traffic. This adheres to least privilege and aligns directly with the stated requirement.
Why this answer
It specifies the internal network (10.0.0.0/8) as the source, the public DNS server (8.8.8.8) as the destination, and HTTPS (TCP/443) as the service, with an Accept action. This precisely matches the requirement to allow only HTTPS traffic from the internal network to that specific destination, blocking all other traffic by default via the implicit deny rule.
Exam trap
The trap here is that candidates may confuse 'service' with 'destination port' and overlook that specifying 'ALL' for service or destination will permit unintended traffic, failing the precise restriction required.
How to eliminate wrong answers
Option A is wrong because it allows traffic from ALL sources, not just the internal network (10.0.0.0/8), which violates the restriction. Option B is wrong because it allows ALL services (any protocol/port) from the internal network to 8.8.8.8, not just HTTPS, which fails to restrict traffic to HTTPS only. Option D is wrong because it allows HTTPS traffic from the internal network to ALL destinations, not just 8.8.8.8, which does not enforce the destination restriction.
A FortiGate has policy-based NAT enabled. The admin wants to translate the source IP of internal users to the interface IP for internet traffic. The firewall policy has NAT enabled. However, traffic from the internal network to the internet shows the original source IP instead of the interface IP. What is the MOST likely reason?
Central NAT is enabled and overrides the per-policy NAT setting. When central NAT is enabled in FortiOS, the per-policy NAT flag is ignored, and NAT is controlled exclusively by central NAT rules (source IP pools and destination VIPs). This means even if the policy shows NAT as enabled, the actual address translation is determined by the central NAT table, not the policy. Therefore, the admin would need to check the central NAT configuration to verify why NAT is not taking effect.
Why this answer
When policy-based NAT is enabled, the per-policy NAT setting should translate the source IP to the interface IP. However, if Central NAT is also enabled, it takes precedence and overrides the per-policy NAT configuration. Central NAT uses its own rules (e.g., IP pools) and can prevent the interface IP translation from being applied, leaving the original source IP unchanged.
Exam trap
The trap here is that candidates assume per-policy NAT always works when enabled, but FortiGate's Central NAT feature can silently override it, making it appear as if NAT is broken.
How to eliminate wrong answers
Option B is wrong because a VIP (Virtual IP) is used for destination NAT (port forwarding) and does not disable source NAT; in fact, VIPs often require source NAT to be enabled for return traffic. Option C is wrong because NGFW mode (profile-based vs. policy-based) affects inspection features like IPS and application control, not the NAT operation or precedence. Option D is wrong because proxy inspection mode changes how traffic is inspected (e.g., SSL inspection) but does not disable or override the per-policy NAT setting.
An administrator needs to block all traffic from a specific geographic region. Which object type should be used as the source in the firewall policy?
A geography address (also called a geo-IP object) uses FortiGate's built-in IP geolocation database to associate source IP addresses with countries, regions, or continents. By creating a geography object for the target country and referencing it in a firewall policy source address, the administrator can block all traffic originating from any IP in that country without enumerating individual IPs. This object type updates dynamically when the geolocation database is refreshed, making it the correct and scalable choice for region-based blocking.
Why this answer
A geography address object (also known as a geolocation object) allows the firewall to match traffic based on the source IP's registered country or region using GeoIP databases. This is the correct object type when the requirement is to block all traffic from a specific geographic region, as it evaluates the source IP against the FortiGate's built-in geolocation mapping.
Exam trap
The trap here is that candidates often confuse geography objects with IP range or FQDN objects, mistakenly thinking they can manually compile IP ranges for a region or use domain-based filtering to block geographic traffic, which is inefficient and inaccurate.
How to eliminate wrong answers
Option A (FQDN address) is wrong because it resolves a fully qualified domain name to IP addresses, which does not provide geographic region filtering. Option B (IP range address) is wrong because it defines a contiguous block of IP addresses, not a geographic region, and would require manual maintenance of all IPs in that region. Option C (Wildcard FQDN address) is wrong because it matches domain names using wildcards (e.g., *.example.com), which is unrelated to geographic location and cannot filter by region.
An administrator configures a firewall policy with a schedule that allows traffic only during business hours (Monday to Friday, 09:00-18:00). At 17:55 on a Friday, a user establishes an SSH session that is still active at 18:05. What happens to the session when the schedule ends?
FortiGate schedule expiry only blocks new sessions; established sessions persist because the firewall does not re-evaluate schedule objects against existing session entries. The SSH session therefore survives past 18:00 and continues until the user disconnects or the session times out, satisfying the stem's active-session constraint.
Why this answer
FortiGate firewall policies control the establishment of new sessions based on the schedule. Once a session is established, it is tracked in the session table and continues to be forwarded even if the schedule ends, until the session naturally terminates or times out. This behavior ensures that ongoing traffic is not abruptly disrupted when a schedule expires.
Exam trap
The trap here is that candidates assume schedules enforce a hard cutoff on all traffic, but FortiGate only applies schedules to new session initiation, not to already established sessions.
How to eliminate wrong answers
Option A is wrong because FortiGate does not immediately terminate active sessions when a schedule ends; it only blocks new session establishments. Option C is wrong because it describes the actual behavior (new sessions blocked, existing sessions continue), but the question asks what happens to the already active session, which continues until it ends naturally, not just 'allowed'—the session is not simply allowed; it continues without interruption. Option D is wrong because there is no 60-second grace period for session termination after a schedule ends; sessions persist based on their own idle timeout or until they finish naturally.
An administrator needs to configure outbound NAT for 200 internal users using a single public IP (203.0.113.1). The public IP provides 2000 ports. Some applications require a deterministic source port range for logging. Which TWO NAT settings should be used?
An Overload IP pool implements many-to-one source NAT by translating multiple private source IPs into one public IP and using unique source port numbers to keep sessions separate. This is the essential mechanism for allowing 200 internal hosts to reach the internet through a single public address, because the combined number of concurrent sessions can share the same destination port on that one public IP.
Why this answer
(IP Pool type: Overload) is correct because it enables Port Address Translation (PAT), allowing 200 internal users to share a single public IP (203.0.113.1) by multiplexing sessions across the 2000 available ports. Option E (Set 'Fixed Port Range' on the IP Pool) is correct because it assigns a deterministic source port range to each user, which is required for logging and auditing applications that expect consistent port mappings.
Exam trap
The trap here is that candidates often confuse 'Fixed Port Range' with static NAT or assume that session helpers (Option C) are needed for port allocation, when in fact session helpers are for application-layer gateway functions, not for deterministic port assignment.
A FortiGate administrator is troubleshooting a connectivity issue where internal clients cannot reach a public web server. The administrator has confirmed that routing is correct and there are no security profiles blocking traffic. Which TWO debugging steps should the administrator take? (Choose two.)
Running a packet capture on the internal interface is the correct first step because it tells you whether the client's frames actually reach the FortiGate. If the capture shows the traffic, then the problem lies in the FortiGate's processing (policy, route, NAT, or security profiles); if no traffic appears, the fault is upstream on the switch or the client. The capture also reveals the exact source/destination IPs, ports, and VLAN tags, which you then use to search for a matching firewall policy.
Why this answer
Running a packet capture on the internal interface (Option B) allows the administrator to verify whether the client's request is actually reaching the FortiGate and whether the firewall is processing the traffic correctly. This step isolates whether the issue is before, at, or after the FortiGate, which is essential when routing is already confirmed as correct.
Exam trap
The trap here is that candidates often confuse configuration changes (like disabling security profiles or changing NAT mode) with actual debugging steps, when the correct approach is to first gather evidence using packet captures and policy verification before making any modifications.
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?
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.
Why this answer
FortiGate firewall policies are evaluated sequentially from top to bottom, and the first matching policy is applied. By placing a deny policy for source 10.0.0.99 to destination 'all' on the WAN interface first, traffic from that IP is blocked. Then a subsequent allow policy for all other traffic (source 'all') permits everything else, ensuring the specific IP is blocked while all other traffic is allowed.
Exam trap
The trap here is that candidates often think a deny policy alone is sufficient, forgetting that FortiGate requires an explicit allow policy for other traffic to pass, or they misorder policies, placing the allow before the deny, which causes the deny to be ineffective due to first-match logic.
How to eliminate wrong answers
Option B is wrong because if an allow policy for source 'all' is placed before the deny policy for 10.0.0.99, traffic from 10.0.0.99 will match the allow policy first and be permitted, defeating the block requirement. Option C is wrong because local-in policies are used to control traffic destined to the FortiGate itself (management traffic), not traffic transiting through the FortiGate to the internet. Option D is wrong because while it denies traffic from 10.0.0.99 to any destination, it does not include an allow policy for other traffic, which would result in all other traffic being implicitly denied by default unless a separate allow policy is added.
Which firewall policy matching parameter is evaluated FIRST when a packet arrives at a FortiGate interface?
The incoming interface is the very first match criterion FortiGate uses for any new session. When a packet arrives, FortiGate uses the ingress interface (and egress interface for explicit proxy or multi-interface policies) to index into its policy list, which is organized by interface pairs. This interface selection happens before any consideration of source, destination, service, or schedule, and it drastically reduces the number of policies that need to be sequentially evaluated. Therefore, the incoming interface is the foundational discriminator in the policy matching hierarchy.
Why this answer
When a packet arrives at a FortiGate interface, the firewall policy lookup begins by matching the incoming interface. This is because the interface is the first parameter evaluated in the policy-matching sequence, as defined by FortiGate's session-based architecture. Only after the interface match is successful does the FortiGate proceed to evaluate source address, destination address, service, and schedule.
Exam trap
The trap here is that candidates often assume source or destination address is checked first, confusing the FortiGate's policy evaluation order with that of other firewalls (e.g., Cisco ASA) where interface is not always the primary match key.
How to eliminate wrong answers
Option A is wrong because source address is evaluated after the incoming interface in the policy-matching order; the FortiGate must first determine which interface the packet arrived on before checking source addresses. Option B is wrong because service (protocol/port) is evaluated later in the sequence, typically after source and destination addresses have been matched. Option C is wrong because schedule (time-based availability) is the last parameter checked in the policy lookup, after all other conditions (interface, source, destination, service) have been satisfied.
An administrator needs to allow internal users to access a public web server using the server's private IP address, while external users access it via a public IP. Which TWO components are required?
The VIP is the core destination NAT object that maps an external public IP and service to the internal server's private IP and port. Without it, there is no translation entry to tell the FortiGate where to forward arriving packets, so external access cannot work. Additionally, firewall policies can reference the VIP as the destination, allowing the FortiGate to apply security inspection before sending the traffic to the private server. This mapping is exactly what the task requires to publish the server.
Why this answer
A VIP (Virtual IP) is required to map the public IP address to the private IP address of the web server, enabling external users to reach the server via the public IP while the FortiGate performs destination NAT (DNAT). A firewall policy must allow traffic from internal users to the server's private IP, as internal traffic does not traverse the VIP and must be permitted directly to the private address.
Exam trap
The trap here is that candidates often think a VIP alone handles all traffic (internal and external), forgetting that internal traffic to the private IP requires a separate firewall policy, or they mistakenly select an IP pool or Central SNAT for destination NAT.
An organization requires that outbound HTTP and HTTPS traffic from the internal network be translated to a single public IP address (203.0.113.1) using overload NAT (PAT). Which TWO configurations are necessary?
An IP pool with type 'Overload' enables Port Address Translation (PAT), allowing the firewall to translate many internal source IPs to a single public IP address by multiplexing on the source port. When you specify a public IP address in that pool, the firewall will use it as the translated source address for all sessions that match the policy. This is the first and essential half of the solution because the pool defines the address pool and NAT behavior that the firewall policy will later reference. Without this overload pool, the policy's NAT action would not have an address pool to translate to.
Why this answer
Overload NAT (PAT) allows multiple internal hosts to share a single public IP by translating source ports. To achieve this, you must create an IP pool with type 'Overload' that specifies the public IP address (203.0.113.1) and then enable NAT on the firewall policy, selecting that IP pool. This configuration ensures outbound HTTP/HTTPS traffic is translated to the single public IP with unique source ports.
Exam trap
The trap here is that candidates often confuse one-to-one NAT (Option B) with overload NAT, or think a VIP (Option D) is needed for outbound traffic, when in fact VIPs are strictly for inbound destination NAT.
An admin needs to allow inbound SMTP traffic from the internet to a mail server in the DMZ. The public IP is 203.0.113.10, and the mail server's private IP is 10.0.0.5. Which VIP configuration is correct?
This is the correct configuration because SMTP traffic uses TCP port 25 by default. The virtual IP (VIP) maps the external address 203.0.113.10:25 to the internal mail server's SMTP listener on 10.0.0.5:25, performing destination NAT without altering the destination port. This allows inbound mail delivery to reach the actual service that speaks the SMTP protocol.
Why this answer
It configures a Virtual IP (VIP) that maps the public IP 203.0.113.10 on TCP port 25 (SMTP) to the internal mail server IP 10.0.0.5 on port 25. This allows inbound SMTP traffic from the internet to reach the mail server in the DMZ, performing both destination NAT (DNAT) and port forwarding for the specific SMTP service.
Exam trap
The trap here is that candidates may confuse port numbers or assume that any port mapping will work, but the NSE4 exam specifically tests that the VIP must match the service port (SMTP = 25) and that only the correct port mapping enables the intended application traffic.
How to eliminate wrong answers
Option B is wrong because it maps port 25 on the external IP to port 80 on the internal IP, which would send SMTP traffic to the mail server's HTTP port instead of the SMTP port, breaking email delivery. Option C is wrong because it maps all ports from the external IP to all ports on the internal IP, which is overly permissive and violates the principle of least privilege, exposing unnecessary services. Option D is wrong because it maps port 80 (HTTP) on the external IP to port 80 on the internal IP, which does not allow SMTP traffic on port 25, so inbound email would be blocked.
An administrator configures Central SNAT with a dynamic IP pool for internet-bound traffic. Some users report that certain applications fail when they should be translated to a specific public IP. The administrator checks the policy-based NAT rules and finds none. What is the most likely reason for the failure?
In FortiOS Central SNAT, rules are evaluated by priority before any other matching criteria. If a higher-priority central SNAT rule matches the same source and destination traffic, it is applied immediately and the dynamic IP pool rule is never reached. Consequently, sessions will be translated exactly as the higher-priority rule specifies, not with the intended dynamic pool. This is the root cause because the traffic is not being dropped or misrouted; it is being SNATed by an earlier rule.
Why this answer
Central SNAT rules are evaluated in order of priority, and the first matching rule is applied. If a higher-priority Central SNAT rule matches the traffic before the intended rule with the specific public IP, the traffic will be translated to the IP defined in that higher-priority rule, causing the applications to fail. Since no policy-based NAT rules exist, the issue lies in the Central SNAT rule priority order.
Exam trap
The trap here is that candidates often assume the issue is with the firewall policy's NAT setting or interface binding, when in fact Central SNAT rules have their own independent priority-based evaluation that can preempt the intended translation.
How to eliminate wrong answers
Option B is wrong because security profiles (e.g., antivirus, web filter) inspect traffic after NAT is applied; they would not prevent NAT from occurring, only block the session after translation. Option C is wrong because Central SNAT operates independently of the firewall policy's NAT setting; even if the firewall policy has NAT disabled, Central SNAT rules can still perform source NAT. Option D is wrong because the IP pool is bound to the Central SNAT rule, not directly to an interface; the rule's configuration determines the egress interface, and a misconfigured interface would not cause a specific public IP translation failure—it would affect all traffic using that rule.
An organization wants to implement least privilege for firewall policies. Which THREE best practices should be followed? (Choose three.)
Defining the exact services required, such as TCP/443 and TCP/22, restricts the protocol and port combinations that the firewall will permit, enabling a default-deny posture. FortiGate service objects can specify source/destination ports, protocol types, and even ICMP message types, ensuring that only necessary application traffic is allowed. This prevents attackers from using unapproved ports for lateral movement or command-and-control traffic.
Why this answer
Specifying exact services (e.g., TCP/443, TCP/22) enforces least privilege by allowing only the necessary protocols and ports, reducing the attack surface. In FortiGate firewall policies, this is configured under the 'Service' field, where you can select predefined services or create custom ones to match specific TCP/UDP port numbers. This prevents overly permissive rules that could expose services like SMB (TCP/445) or RDP (TCP/3389) unintentionally.
Exam trap
The trap here is that candidates often choose 'Use any any for source and destination to simplify management' (Option D) thinking it reduces administrative overhead, but this directly contradicts the principle of least privilege and is a common misconfiguration in FortiGate environments.
What is the purpose of the 'implicit deny' policy on a FortiGate?
The implicit deny is a built-in fallback rule that FortiGate automatically applies to any session that does not match an earlier explicit firewall policy. It performs a drop/deny action, ensuring default-deny security so unknown traffic cannot traverse the device. Because it is the last rule, it is never explicitly shown in the policy list but is conceptually always present.
Why this answer
The 'implicit deny' policy on a FortiGate is a default, last-resort rule that denies all traffic not matching any explicit firewall policy. It ensures that any packet that does not meet the source, destination, service, or schedule criteria of a configured policy is dropped, enforcing a default-deny security posture. This behavior is fundamental to stateful firewall operation and prevents unauthorized traffic from traversing the device.
Exam trap
The trap here is that candidates often confuse the implicit deny with a logging or allow action, or assume it behaves like a default permit, when in fact it silently drops all unmatched traffic without logging unless explicitly configured.
How to eliminate wrong answers
Option A is wrong because the implicit deny does not allow traffic from trusted internal networks; it denies all unmatched traffic regardless of source, and allowing trusted traffic requires explicit permit policies. Option C is wrong because the implicit deny does not inherently log all denied traffic; logging must be explicitly enabled on a deny policy or via global logging settings, and the implicit deny itself generates no log entry by default. Option D is wrong because the implicit deny does not allow traffic; it denies any traffic that does not match an explicit policy, and allowing unmatched traffic would require an explicit permit-all policy at the end of the policy list.
A network administrator creates a firewall policy allowing HTTP traffic from the internal network to a web server in the DMZ. Users report that they cannot access the web server. The administrator runs 'diagnose firewall iprope list' and sees the policy is present. What is the MOST likely cause of the issue?
In FortiGate, policy matching uses a first-match model: the firewall processes rules in ascending policy ID order and stops at the first rule whose source, destination, and service match the session. If a deny policy with a lower ID (i.e., positioned earlier in the policy list) matches the same HTTP traffic as the intended allow policy, that deny will drop the packets and the allow policy will never be reached. This shadowing behavior is the most probable cause, and it can be confirmed by placing the allow rule above the deny or by comparing policy IDs in the `get firewall policy` output.
Why this answer
The 'diagnose firewall iprope list' command confirms the allow policy exists in the FortiGate's kernel policy list, meaning it is present and enabled. However, FortiGate evaluates policies in sequential order based on policy ID (lowest first), so a deny policy with a lower ID that matches the same traffic (e.g., from internal to DMZ) will be hit first, blocking the HTTP request before the allow policy can be evaluated. This is the most likely cause because the policy is present but not being matched due to ordering.
Exam trap
The trap here is that candidates assume 'policy is present' means it is working, but FortiGate's policy order (lowest ID first) means a lower-ID deny policy can override a higher-ID allow policy even if both match the same traffic.
How to eliminate wrong answers
Option B is wrong because an incorrect source interface would cause the policy not to match at all, but the 'diagnose firewall iprope list' output would not show the policy as present for that traffic flow; the administrator would see no matching entry. Option C is wrong because a disabled policy would not appear in the 'diagnose firewall iprope list' output at all, yet the administrator sees it present. Option D is wrong because the web server not responding would result in a timeout or connection reset, but the firewall would still allow the traffic (the policy would match), and the issue would be reported differently; the 'diagnose firewall iprope list' check would not be the first troubleshooting step for a server-side problem.
An admin wants to block traffic from a specific geographic region (e.g., North Korea) from reaching the FortiGate's external interface. Which address object type should be used in the firewall policy?
A geography address object in FortiOS matches traffic based on the country or region mapped to the source or destination IP address, using the FortiGuard GeoIP database. When you add it to a firewall policy as the source address and set the action to DENY, all traffic originating from that geopolitical area is blocked dynamically, with no need to track individual IP ranges. This is the correct object type because it directly maps IP addresses to geographic locations.
Why this answer
A geography address object allows the firewall to match traffic based on the source or destination IP address's registered country. FortiGate uses a built-in GeoIP database to map IP addresses to geographic regions, making it the correct choice for blocking traffic from a specific country like North Korea.
Exam trap
The trap here is that candidates may confuse geography address objects with subnet or FQDN objects, thinking they can manually list IP ranges for a country, but FortiGate requires the use of the built-in GeoIP database for country-based filtering.
How to eliminate wrong answers
Option A is wrong because a subnet address object matches traffic based on a specific IP range or CIDR, not by geographic region. Option C is wrong because an FQDN address object resolves a domain name to IP addresses and cannot represent an entire country. Option D is wrong because a wildcard FQDN address object matches multiple domain names using wildcards, which is unrelated to geographic location.
An administrator wants to log all traffic that is denied by the implicit deny rule. How can this be achieved?
Creating an explicit firewall policy with DENY action and enabling logging, then placing it above the implicit deny rule, meets the administrator's requirement. This explicit policy will match traffic that would otherwise fall through to the implicit deny, block it, and generate a traffic log entry with details such as source, destination, and service. Because the policy is above the implicit deny, it takes precedence and ensures that denied traffic is properly logged.
Why this answer
The implicit deny rule at the bottom of the firewall policy list cannot be modified to enable logging. To log traffic denied by the implicit deny, you must create an explicit firewall policy with action DENY and logging enabled, placed above the implicit deny rule. This explicit deny policy will match traffic that would otherwise hit the implicit deny, and because it is an explicit policy, logging can be enabled on it.
Exam trap
The trap here is that candidates assume the implicit deny rule can be modified to enable logging, but FortiOS does not allow any configuration changes to the implicit deny rule, so you must create an explicit deny policy above it to log denied traffic.
How to eliminate wrong answers
Option A is wrong because an ACCEPT action would allow the traffic, not deny it, and logging would only show allowed traffic, not the denied traffic you want to capture. Option B is wrong because the implicit deny rule is a built-in, non-configurable rule; you cannot enable logging on it directly in the FortiGate GUI or CLI. Option D is wrong because 'diagnose debug flow' is a real-time troubleshooting tool that captures packet flow information for a specific session, not a method to log all denied traffic persistently.
A FortiGate administrator configures a policy-based NAT using an IP pool with type 'Fixed Port Range' for internal users accessing a specific external server. Users report that after some time, they cannot establish new connections to the server. 'diagnose ip pool list' shows many entries with 'used_port=65535'. What is the MOST likely cause?
Fixed port range NAT assigns a block of ports to each source IP. If the range is small (e.g., 1 port), it fills quickly and blocks new sessions. The 'used_port=65535' indicates the last port in a range is in use.
Why this answer
The 'Fixed Port Range' IP pool type allocates a specific range of ports per IP address for NAT translations. When all ports in the range are exhausted (indicated by 'used_port=65535'), no new connections can be established, causing the reported issue. This is classic port exhaustion, making D correct.
Exam trap
The trap here is that candidates may confuse IP address exhaustion (Option C) with port exhaustion, but the diagnostic output clearly shows IP addresses are still available while ports are maxed out, pointing directly to the fixed port range being too small.
How to eliminate wrong answers
Option A is wrong because the external server rate-limiting would affect all users equally and would not cause the specific symptom of 'used_port=65535' entries in the IP pool list. Option B is wrong because a low firewall policy timeout would cause connections to be dropped prematurely, not prevent new connections from being established due to port exhaustion. Option C is wrong because the 'diagnose ip pool list' output shows many entries with 'used_port=65535', indicating that IP addresses are still available but all ports within the fixed range are in use, not that IP addresses have run out.
A FortiGate administrator needs to block all traffic from a specific geographic region (country) from accessing the internal network. Which type of address object should be used in the firewall policy?
In FortiGate, a geography object (GeoIP object) represents a country or region using the FortiGuard GeoIP database, which maps IP address ranges to geographic locations. This object type is the only one among the listed options that inherently supports country-based identification, so it is the correct choice for blocking all traffic from a specific source country. The GeoIP database is regularly updated by FortiGuard to reflect new IP allocations, ensuring policy accuracy.
Why this answer
A Geography object is specifically designed to represent a geographic region (such as a country) based on IP address geolocation data. When used in a firewall policy, it allows the FortiGate to match traffic sources or destinations by country, enabling the administrator to block all traffic from that region. This is the correct and only address object type that supports country-based filtering.
Exam trap
The trap here is that candidates may confuse a Geography object with a Subnet object, thinking they can manually list all IP ranges for a country, but FortiGate's dynamic geolocation database makes the Geography object the only practical and correct choice for country-based blocking.
How to eliminate wrong answers
Option B (FQDN object) is wrong because it resolves a fully qualified domain name to an IP address and cannot represent a geographic region. Option C (Wildcard FQDN object) is wrong because it matches multiple domain names using wildcards, not geographic locations. Option D (Subnet object) is wrong because it defines a specific IP address range or subnet, which cannot dynamically represent all IPs belonging to a country.
When creating a firewall policy, an admin wants to ensure that traffic from a specific user group is allowed only during business hours (Monday to Friday, 09:00-18:00). Which object type must be configured and applied to the policy?
A schedule object with a recurring schedule is the correct Fortinet approach because it explicitly defines days-of-week and time-of-day ranges that are then bound directly to the firewall policy. When a schedule is attached to a policy, the policy becomes active only during the configured time window, and the firewall automatically disables enforcement outside that period. This matches the administrator's requirement precisely, and no other object type in FortiOS provides this built-in time-enforcement capability for policy activation.
Why this answer
To restrict traffic based on time, a firewall policy must reference a schedule object. A recurring schedule defines specific days and hours (e.g., Monday–Friday, 09:00–18:00) and is applied directly to the policy. This allows the FortiGate to permit or deny traffic based on the current time without additional profiles or user group modifications.
Exam trap
The trap here is that candidates confuse security profiles (which can have time-based filtering for web categories) with the schedule object required at the policy level, but only the schedule object controls whether the entire policy is active.
How to eliminate wrong answers
Option A is wrong because a security profile (e.g., antivirus, web filter) inspects content, not time; it cannot enforce time-based access. Option C is wrong because user group objects define users, not time windows; time restrictions are not a property of user groups. Option D is wrong because a traffic shaping policy controls bandwidth and QoS, not access permission; it cannot allow or deny traffic based on time.
An administrator is configuring a VIP to map a public IP to an internal server. The server hosts both HTTP and HTTPS services. The admin creates a VIP with port forwarding for port 80 to internal port 80, and another VIP for port 443 to internal port 443. Both VIPs use the same public IP. Users can access HTTP but not HTTPS. What is the most likely issue?
In FortiGate, VIPs only perform destination NAT; they do not implicitly permit traffic. A firewall policy must explicitly allow HTTPS traffic with the destination set to the VIP object, and the service must include HTTPS (or port 443). If the existing policy only allows HTTP to the same VIP, HTTPS packets are dropped due to no matching policy, so the connection never reaches the server.
Why this answer
The most likely issue is that the firewall policy for HTTPS traffic is missing or has an incorrect destination. Even with a correctly configured VIP, traffic must be allowed by a firewall policy that matches the destination (the VIP's public IP and port 443) and the action must be set to ACCEPT. Without this policy, the FortiGate will drop the HTTPS packets, while HTTP traffic works because its corresponding policy exists.
Exam trap
The trap here is that candidates assume a correctly configured VIP automatically allows traffic, but FortiGate requires an explicit firewall policy to permit the translated traffic, and the exam tests this separation of NAT and policy functions.
How to eliminate wrong answers
Option B is wrong because if the server's HTTPS service were not running, the admin would typically see connection refused or timeout errors, not a complete lack of access; the issue is at the firewall level, not the server. Option C is wrong because FortiGate VIPs can share the same public IP address as long as they use different ports (e.g., 80 and 443), which is a standard port-based VIP configuration. Option D is wrong because the admin explicitly configured the HTTPS VIP with internal port 443, which is correct for HTTPS; if the internal port were wrong, the traffic would reach the server but on the wrong port, causing a different failure mode.
Which THREE conditions must be met for a firewall policy with FSSO authentication to work correctly?
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.
Why this answer
FSSO (Fortinet Single Sign-On) relies on the FortiGate communicating with the domain controller to retrieve user login events via NetAPI or WMI. Without this communication, the FortiGate cannot map user identities to IP addresses, which is essential for FSSO-based authentication in firewall policies.
Exam trap
The trap here is that candidates often confuse source and destination address fields in the policy, mistakenly thinking the user's IP must be in the destination range, or assume FSSO requires local FortiGate authentication, when in fact it relies on domain authentication and the collector agent.
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?
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.
Why this answer
SMTP traffic from the internal network to an external mail server requires source NAT (masquerading) to translate private source IPs to the FortiGate's external interface IP. This ensures return traffic is routed back correctly. The default SMTP service uses TCP port 25, and enabling NAT on the policy is the standard configuration for outbound traffic to the internet.
Exam trap
The trap here is that candidates may confuse SMTP ports (25 vs 587) or assume SMTP can use UDP, but the exam tests the fundamental requirement that outbound internet traffic must have NAT enabled and that SMTP is TCP-based.
How to eliminate wrong answers
Option B is wrong because disabling NAT would send packets with private source IPs, which are not routable on the internet, causing the external mail server to drop replies or the packets to be discarded by intermediate routers. Option C is wrong because SMTP typically uses TCP port 25, not port 587 (which is SMTP submission, often used for authenticated client-to-server submission); the question specifies SMTP traffic, not SMTP submission, and the service should match the standard SMTP port. Option D is wrong because SMTP uses TCP, not UDP; SMTP relies on reliable, connection-oriented transport, and UDP would break the protocol's delivery guarantees.
An admin configures a VIP to map a public IP to an internal server. The firewall policy uses the VIP as the destination. External users can access the server, but the server's logs show the source IP as the FortiGate's internal interface IP instead of the original client IP. Why is this happening?
When the firewall policy matching the VIP traffic has NAT enabled, FortiGate replaces the original source IP with the IP of the egress interface used to forward the packet. This source NAT (SNAT) hides the client's real address, so the internal server logs show the FortiGate's interface IP as the connection source. This is the standard behavior, explaining why the admin observes the FortiGate IP instead of the client's public IP.
Why this answer
When a firewall policy has NAT enabled (typically 'Enable NAT' or 'Use Outgoing Interface Address'), the FortiGate performs source NAT (SNAT) on the traffic, replacing the original client source IP with the IP of its egress interface (the internal interface in this scenario). This is standard behavior for source NAT, which hides the original client IP from the internal server, causing the server logs to show the FortiGate's internal interface IP instead of the actual client IP.
Exam trap
The trap here is that candidates often assume NAT only applies to outbound traffic, but FortiGate policies apply NAT bidirectionally unless explicitly disabled, causing the source IP to be overwritten even for inbound VIP traffic.
How to eliminate wrong answers
Option A is wrong because port forwarding configuration on the VIP does not affect source IP preservation; it only translates destination ports, and the server expecting a different port would cause connectivity failure, not a source IP mismatch. Option B is wrong because using a different public IP than expected would result in the server not receiving traffic at all or traffic being dropped, not in the server seeing the FortiGate's internal IP as the source. Option D is wrong because misconfigured server routing causing asymmetric return traffic would typically lead to dropped connections or timeouts, not to the server logging the FortiGate's internal IP as the source; the source IP seen by the server is determined by the inbound packet's source address, which is already modified by NAT before the server processes it.
What is the purpose of policy-based routing (PBR) in FortiGate?
Policy-based routing (PBR) allows a FortiGate to choose the next hop for a packet based on policy criteria such as source address, destination address, or incoming interface, rather than performing a normal longest-prefix routing table lookup. When a policy route matches, the FortiGate follows its configured action (e.g., send to a specific gateway or tunnel) and skips the destination-based routing decision for that packet. This is an essential tool when traffic must be forced down a specific path independent of what the routing table would select.
Why this answer
Policy-based routing (PBR) in FortiGate allows you to override the default routing table lookup by forwarding traffic based on criteria such as source IP address, destination IP address, protocol, or even application. This is configured under the 'policy route' feature and is evaluated before the routing table, enabling granular control over traffic paths that static or dynamic routes cannot provide.
Exam trap
The trap here is that candidates often confuse PBR with SD-WAN or load balancing, but PBR is strictly about overriding routing decisions based on packet attributes, not about distributing traffic across multiple links for bandwidth or redundancy.
How to eliminate wrong answers
Option A is wrong because load balancing across multiple WAN links is achieved using ECMP (Equal-Cost Multi-Path) routing or SD-WAN rules, not PBR. Option B is wrong because filtering traffic based on application signatures is the function of Application Control, a feature within firewall policies, not PBR. Option D is wrong because authenticating users before allowing traffic is handled by firewall authentication (e.g., FSSO, LDAP) or captive portal, not by PBR.
A company uses FortiGate with firewall policies to control access between internal VLANs. Users in VLAN 10 report they can access internet but cannot reach a server in VLAN 20 on port 443. The server is reachable from other VLANs. The administrator checks the firewall policy configuration: there is a policy from VLAN10 to VLAN20 allowing HTTPS, with NAT disabled and logging enabled. The policy has a schedule set to 'Always'. The administrator also checks that there are no overlapping policies. What is the most likely cause?
A security profile (e.g., SSL inspection or application control) applied to the firewall policy can intercept HTTPS sessions and enforce actions like blocking based on certificate validation failure, URL category, or application signature. If the server presents an untrusted or expired certificate, the SSL inspection profile may block the HTTPS handshake while allowing other traffic, which matches the symptom of only HTTPS being affected.
Why this answer
Security profiles (such as web filtering, application control, or SSL inspection) applied to a firewall policy can inspect and block HTTPS traffic even when the policy itself allows the service. Since the server is reachable from other VLANs and the policy explicitly permits HTTPS with NAT disabled and logging enabled, the most likely cause is that a security profile is dropping or denying the traffic.
Exam trap
The trap here is that candidates often assume a policy allowing a service with NAT disabled is sufficient for reachability, overlooking that security profiles can independently block traffic at a higher layer, especially for HTTPS where inspection is required.
How to eliminate wrong answers
Option A is wrong because NAT is not required for reachability between internal VLANs; the server can send replies directly to the client's private IP address without NAT. Option B is wrong because the administrator has already confirmed there are no overlapping policies, so a deny policy above cannot be blocking traffic. Option D is wrong because the schedule is set to 'Always', meaning the policy is active at all times, and the users can access the internet, confirming the policy is not inactive.
Ready to test yourself?
Try a timed practice session using only Firewall Policies and NAT questions.