Fortinet NSE 4 Network Security Professional NSE4 NSE4 Questions 676–750 | Page 10/11

676

MCQhard

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?

A.The FortiGate is using a proxy server that caches different results for different users

B.The web filter profile is configured to 'allow' but the FortiGuard rating is inconsistent

C.The firewall policy has an FQDN destination that resolves to different IPs for different users due to DNS load balancing

D.Some users have a different web filter profile applied due to a policy ordering issue where a higher-priority policy matches their traffic

AnswerD

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.

Full explanation →

677

MCQmedium

An administrator configures a web filter profile with FortiGuard category blocking and URL filter to allow example.com. Users report that example.com is still blocked. What is the most likely cause?

A.The URL filter requires deep inspection to be enabled

B.The URL filter entry is placed after the FortiGuard category in the policy

C.The DNS filter is blocking example.com before the web filter is evaluated

D.The FortiGuard category action is set to 'block' and takes precedence over the URL filter allow rule

AnswerD

In FortiOS, when a category is set to block, it blocks all URLs in that category regardless of individual URL filter entries unless the URL filter uses an allow action and is configured to override categories.

Why this answer

When both FortiGuard category blocking and a URL filter are configured in the same web filter profile, the FortiGuard category action (e.g., 'block') is evaluated first and takes precedence over any URL filter allow rule. This is because FortiGate processes web filter rules in a specific order: FortiGuard category blocking is applied before URL filter entries. Therefore, even if a URL filter explicitly allows example.com, the FortiGuard category block will prevent access.

Exam trap

The trap here is that candidates assume URL filter entries are evaluated before FortiGuard categories, or that a URL filter allow rule can override a FortiGuard block, when in fact FortiGuard category blocking takes precedence regardless of URL filter order.

How to eliminate wrong answers

Option A is wrong because deep inspection is not required for URL filtering to work; URL filtering can operate with certificate inspection or no inspection, and deep inspection is only needed for HTTPS content scanning. Option B is wrong because the order of URL filter entries within the URL filter list does not affect precedence over FortiGuard categories; the FortiGuard category check occurs before the URL filter is evaluated. Option C is wrong because DNS filtering is a separate security profile that can block domains, but the question states the web filter profile is configured, and DNS filter would not block example.com unless explicitly configured; the most likely cause is the FortiGuard category taking precedence.

Full explanation →

678

MCQmedium

A network administrator notices that an IPS sensor is generating excessive false positives for a specific signature. The administrator wants to exclude traffic from a trusted internal server (IP 10.1.1.100) from inspection for that signature only, while keeping other signatures active. Which configuration change should the administrator apply?

A.Set the signature action to 'pass' and use an application control profile to bypass the server.

B.Disable the signature in the IPS sensor configuration.

C.Add the server's IP to the exempt list in the IPS sensor.

D.Create an IPS filter that excludes the server's source IP address from the signature.

AnswerD

An IPS filter allows you to create a conditional override for a specific signature based on attributes such as the source IP address. In Fortinet, you can set the signature's action to 'pass' or 'monitor' only when the source IP matches the trusted server, leaving the default (typically 'block') intact for all other sources. This gives exactly the required selectivity: the false positive is silently allowed, while the signature remains fully active for the rest of the network.

Why this answer

An IPS filter allows the administrator to define a rule that excludes traffic from a specific source IP address (10.1.1.100) from inspection for a particular signature, while leaving all other signatures active. This granular approach ensures that false positives for that signature are reduced without disabling the signature entirely or affecting other traffic.

Exam trap

The trap here is that candidates often confuse the 'exempt list' (which bypasses all IPS inspection for a host) with an 'IPS filter' (which can exclude traffic from a specific signature only), leading them to choose option C incorrectly.

How to eliminate wrong answers

Option A is wrong because setting the signature action to 'pass' would bypass inspection for that signature globally, not just for the trusted server, and using an application control profile does not apply to IPS signatures. Option B is wrong because disabling the signature entirely would stop all inspection for that signature across all traffic, which is too broad and would miss real threats from other sources. Option C is wrong because the exempt list in an IPS sensor typically excludes traffic from all inspection, not just for a specific signature, which would bypass all IPS signatures for that server.

Full explanation →

679

MCQmedium

A FortiGate HA cluster is configured in active-passive mode with two units. The primary unit fails. The secondary unit takes over, but some established TCP sessions are dropped. What is the most likely cause?

A.Session synchronization is not enabled

B.The HA failover threshold is set too high

C.The HA mode is active-passive

D.The heartbeat interface is down

AnswerA

Session synchronization is not enabled. In an active-passive HA cluster, the primary FortiGate maintains the complete session table for all inspected traffic. If session synchronization (or session sync) is not configured via the HA settings, the backup unit does not receive real-time updates about existing sessions. Upon failover, the newly active unit has no entries for these flows, so when endpoints continue sending packets, the FortiGate cannot match them to a session and drops them—causing established TCP connections to break and requiring applications to reconnect. This is the direct cause of the session loss observed.

Why this answer

In an active-passive FortiGate HA cluster, the primary unit synchronizes session state (including TCP session tables) to the secondary unit so that upon failover, established sessions can continue without interruption. If session synchronization is not enabled, the secondary unit has no knowledge of existing sessions, so when it takes over, it drops all established TCP sessions because it has no session entries for them. Thus, the most likely cause is that session synchronization is disabled.

Exam trap

NSE4 often tests the misconception that active-passive HA automatically preserves all sessions, when in fact session synchronization must be explicitly enabled and configured correctly.

How to eliminate wrong answers

Option B is wrong because the HA failover threshold (if configured) determines how many heartbeat misses trigger a failover, not whether sessions are preserved; a high threshold might delay failover but does not cause session drops after failover. Option C is wrong because active-passive HA mode itself does not cause session drops; in fact, it is designed to maintain sessions via synchronization. Option D is wrong because if the heartbeat interface is down, the cluster would likely split or failover might not occur correctly, but the scenario states the secondary unit took over, implying heartbeat communication was functional; a down heartbeat interface would not specifically cause established TCP sessions to drop if session synchronization were enabled.

Full explanation →

680

MCQeasy

A FortiGate needs to resolve DNS names for outbound traffic. The administrator configures DNS servers under System > DNS. However, internal DNS queries for private domains fail. What additional configuration is required?

A.Create a DNS database entry for the private domain.

B.Add a static route for DNS traffic.

C.Configure a DNS server on the WAN interface.

D.Enable DNS proxy on the FortiGate.

AnswerA

Creating a DNS database entry on the FortiGate is the correct solution because it statically maps the private domain to an IP address in the FortiGate's local DNS database. This allows the FortiGate to resolve that FQDN locally for its own outbound traffic, even when the upstream DNS servers have no record for the private domain. You can define this under Network > DNS as a static entry, and it takes precedence over normal DNS lookups.

Why this answer

When a FortiGate is configured with DNS servers under System > DNS, it can resolve public DNS names for outbound traffic. However, for private domains (e.g., internal.company.local), the FortiGate cannot resolve these because they are not registered in public DNS. Creating a DNS database entry for the private domain allows the FortiGate to act as an authoritative DNS server for that domain, providing local resolution for internal queries.

Exam trap

The trap here is that candidates often confuse the DNS proxy (which forwards queries) with the DNS database (which provides authoritative answers), leading them to select option D instead of A.

How to eliminate wrong answers

Option B is wrong because static routes are used for network-layer reachability, not for DNS resolution; DNS traffic will already follow the default route if the DNS server is reachable via the WAN. Option C is wrong because configuring a DNS server on the WAN interface is not a standard FortiGate feature; DNS servers are configured globally under System > DNS, and adding a DNS server on the WAN interface does not enable local domain resolution. Option D is wrong because enabling DNS proxy on the FortiGate only forwards DNS queries to configured DNS servers and does not provide local resolution for private domains; it is used for caching or filtering, not for authoritative responses.

Full explanation →

681

MCQmedium

Which type of log records information about firewall policy matches, such as allowed or denied traffic?

A.Security logs

B.Event logs

C.Traffic logs

D.Audit logs

AnswerC

Traffic logs are the correct answer because they are generated when a session is evaluated against a firewall policy and contain the matching policy ID, action (accept or deny), source/destination IP addresses, ports, protocol, and bytes transferred. These logs let administrators verify which policy handled a given connection, monitor traffic volumes per policy, and troubleshoot connectivity issues. They appear under Log & Report > Traffic Log and serve as the foundation for FortiView session monitoring and policy-based reporting.

Why this answer

Traffic logs in FortiGate record information about firewall policy matches, including allowed and denied traffic. They provide details such as source and destination IP addresses, ports, protocols, and the action taken by the firewall policy. This is the primary log type used for analyzing policy enforcement and troubleshooting connectivity issues.

Exam trap

NSE4 often tests the distinction between traffic logs and security logs, causing candidates to confuse policy match logging with security profile logging.

How to eliminate wrong answers

Option A is wrong because security logs in FortiGate typically refer to logs generated by security profiles such as antivirus, IPS, or web filtering, not basic policy matches. Option B is wrong because event logs record system events, administrative actions, and configuration changes, not traffic policy matches. Option D is wrong because audit logs track administrative activities and configuration changes, not traffic flows.

Full explanation →

682

MCQmedium

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?

A.The destination address 'server_farm' does not include 10.10.10.50

B.There is a deny policy above this policy that matches the traffic

C.The NAT translation is causing the traffic to be dropped

D.The source address 'internal_net' does not include 10.0.1.100

AnswerB

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.

Full explanation →

683

Multi-Selecthard

An administrator has configured an IPS profile to detect SQL injection attacks. However, some SQL injection attempts are still reaching the web server. Which TWO actions should the administrator take to improve detection?

Select 2 answers

A.Configure anomaly detection for SQL traffic

B.Update the IPS signature database

C.Disable flow-based inspection and use proxy-based only

D.Enable protocol decoders for HTTP and SQL

E.Enable SSL deep inspection on the policy

AnswersB, D

Updating the FortiGuard IPS signature database is the core step because SQL injection detection depends on signature patterns that recognize specific attack syntax and variations. Signature packages are regularly updated with new and refined rules for recent SQL injection techniques, such as union-based or time-based blind injection. If the database is outdated, the IPS engine lacks those rules, and the policy may silently ignore crafted SQL payloads. Therefore, to detect SQL injection effectively, an administrator must ensure the IPS database is current.

Why this answer

IPS signatures are the primary mechanism for detecting known SQL injection patterns. If attacks are reaching the web server, the signature database is likely outdated or missing recent attack vectors. Updating the signature database ensures the IPS has the latest patterns to match against SQL injection attempts.

Exam trap

The trap here is that candidates may confuse anomaly detection (which is for behavioral baselines) with signature-based detection, or assume that switching inspection modes (flow vs. proxy) fixes detection gaps when the real issue is outdated signatures or missing protocol decoders.

Full explanation →

684

MCQhard

A FortiGate is configured with SSL deep inspection using a locally generated CA certificate. A user reports that they cannot access https://www.example.com and receive a certificate error. The administrator checks the firewall policy and sees that the SSL inspection profile is set to 'certificate-inspection' instead of 'deep-inspection'. What is the MOST likely effect?

A.The FortiGate decrypts the traffic but does not re-sign, causing mismatch errors.

B.The FortiGate does not decrypt the traffic, so the original server certificate is presented to the client, which may be valid; the error is unrelated.

C.The FortiGate blocks the connection because certificate-inspection cannot handle deep inspection profiles.

D.The user will see a warning about the certificate but will be able to proceed after accepting it.

AnswerB

Certificate-inspection mode only checks the certificate chain; it does not re-sign. The client sees the original server certificate. If that certificate is valid, there should be no error. The issue likely stems from a different problem.

Why this answer

When the SSL inspection profile is set to 'certificate-inspection', the FortiGate does not decrypt the traffic; it only checks the certificate's validity (e.g., expiry, revocation). Therefore, the original server certificate from www.example.com is passed directly to the client. Since the client receives the actual server certificate (which is likely valid), the reported certificate error is unrelated to the FortiGate's configuration.

Option B correctly identifies that the error is not caused by the FortiGate's inspection profile.

Exam trap

The trap here is that candidates often confuse 'certificate-inspection' with 'deep-inspection', assuming that any SSL inspection profile decrypts traffic, leading them to incorrectly select option A or D.

How to eliminate wrong answers

Option A is wrong because 'certificate-inspection' does not decrypt traffic at all, so there is no re-signing to cause mismatch errors; decryption and re-signing only occur with 'deep-inspection'. Option C is wrong because 'certificate-inspection' does not block connections; it simply passes the original server certificate to the client, and the firewall policy still allows the traffic based on other criteria. Option D is wrong because 'certificate-inspection' does not generate a warning or prompt the user to accept a certificate; it does not modify the certificate chain, so the client sees the original server certificate without any FortiGate intervention.

Full explanation →

685

MCQmedium

A FortiGate administrator wants to configure Zero Trust Network Access (ZTNA) to secure access to an internal application. What is required on the FortiGate?

A.A FortiClient EMS subscription

B.A VPN tunnel to the application

C.A ZTNA server and a ZTNA rule

D.A firewall policy with SSL inspection enabled

AnswerC

A ZTNA server defines the internal application's host and port, while a ZTNA rule (configured in the firewall policy) specifies who can access it and what access proxy settings apply. Together they establish the FortiGate as an access proxy that authenticates users and enforces least-privilege access. Without these two objects, the FortiGate has no way to publish or protect the application, making them the core requirement for zero-trust network access.

Why this answer

FortiGate ZTNA requires configuring a ZTNA server (which defines the protected application, its real server, and the access proxy/certificate) and a ZTNA rule (which binds the server to users/groups and enforcement). Together they let the FortiGate act as an access proxy that authenticates users and brokers connections to the internal app without a full VPN tunnel.

Exam trap

NSE4 often tests whether candidates confuse ZTNA with traditional SSL VPN — the trap is selecting 'VPN tunnel' because ZTNA sounds like remote access, when ZTNA's defining feature is the access proxy (ZTNA server + rule) that avoids a full tunnel.

How to eliminate wrong answers

Option A is wrong because FortiClient EMS is used for endpoint posture and ZTNA client management, but it is not strictly required to configure the ZTNA server and rule on the FortiGate itself. Option B is wrong because ZTNA is specifically designed to avoid full VPN tunnels — it uses an access proxy, so a VPN tunnel to the application is not the ZTNA mechanism. Option D is wrong because a firewall policy with SSL inspection is a general security control, not the ZTNA configuration; ZTNA needs the dedicated ZTNA server and rule objects.

Full explanation →

686

MCQmedium

A FortiGate administrator wants to block all traffic to a known malicious IP address range using the Intrusion Prevention System (IPS). Which IPS configuration method is most appropriate?

A.Use a predefined IPS signature for known malicious IPs

B.Create a custom IPS signature that matches the IP range

C.Configure an IPS anomaly detection rule to block the IP range

D.Use a local IPS signature database

AnswerB

Creating a custom IPS signature allows specifying source or destination IP addresses or ranges using filters like 'source-ip' or 'destination-ip', making it the most direct method to block traffic to a known malicious IP range.

Why this answer

FortiGate's IPS allows administrators to create custom signatures that can match specific IP addresses or ranges using the 'source-ip' or 'destination-ip' filter criteria. This is the most direct and precise method to block traffic to a known malicious IP range, as predefined signatures typically target application-layer vulnerabilities or exploit patterns, not arbitrary IP addresses.

Exam trap

The trap here is that candidates may confuse IPS anomaly detection (which blocks based on traffic patterns) with the ability to block specific IPs, or assume predefined signatures cover all threats including IP-based blocks, when in fact custom signatures are required for IP-specific filtering.

How to eliminate wrong answers

Option A is wrong because predefined IPS signatures are designed to detect known attack patterns (e.g., SQL injection, buffer overflows) and do not include signatures for arbitrary IP addresses or ranges. Option C is wrong because IPS anomaly detection rules are used to detect deviations from normal traffic baselines (e.g., port scans, traffic floods), not to block specific IP ranges. Option D is wrong because a local IPS signature database is simply a repository for storing custom or downloaded signatures; it is not a configuration method to block traffic to an IP range.

Full explanation →

687

MCQeasy

Which of the following statements about FortiGate policy lookup order is correct?

A.Policies are evaluated from top to bottom, and the first matching policy is used

B.Policies are evaluated based on a priority number assigned to each policy

C.Policies are evaluated from bottom to top, and the last matching policy is used

D.Policies are evaluated randomly to balance load

AnswerA

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.

Full explanation →

688

MCQmedium

An administrator runs the CLI command 'diagnose debug rating' and sees that all FortiGuard web filter requests are timing out. What is the most likely cause?

A.The web filter profile has an incorrect action configured

B.The web filter is set to 'monitor all' which causes all requests to timeout

C.The FortiGuard web filtering license has expired

D.The DNS server configured on the FortiGate is not resolving the FortiGuard FQDN

AnswerD

Before it can send a rating request to FortiGuard, the FortiGate must resolve the FortiGuard server's FQDN (such as 'fortiguard.fortinet.net') via its configured DNS servers. If DNS resolution fails, the FortiGate has no IP address to connect to, so the HTTPS request never leaves the device and the rating operation eventually times out. This matches the timeout symptom in the 'diagnose debug rating' output, because the lookup cannot complete. To confirm, an administrator should check the FortiGate's DNS settings with 'get system dns' and test name resolution for the FortiGuard domain.

Why this answer

The 'diagnose debug rating' command shows real-time FortiGuard web filter request status. When all requests are timing out, it indicates that the FortiGate cannot reach the FortiGuard servers. The most common cause is a DNS resolution failure, where the FortiGate cannot resolve the FortiGuard FQDN (e.g., service.fortiguard.net) due to an incorrect or unreachable DNS server configuration.

Without proper DNS, the FortiGate cannot establish the necessary HTTPS connections to query the FortiGuard rating service.

Exam trap

The trap here is that candidates often assume timeouts are caused by license expiration or profile misconfiguration, but the debug output clearly distinguishes between 'timeout' (connectivity/DNS issue) and 'license expired' (licensing issue), so reading the exact debug message is critical.

How to eliminate wrong answers

Option A is wrong because an incorrect action in the web filter profile (e.g., 'block' vs 'monitor') affects how traffic is handled after a rating is received, not the ability to reach FortiGuard servers. Option B is wrong because 'monitor all' is not a valid setting; the web filter profile has an 'Action' setting with options like 'monitor' or 'block', but this does not cause timeouts. Option C is wrong because an expired FortiGuard web filtering license would result in a 'license expired' or 'unlicensed' error message in the debug output, not a timeout; timeouts indicate a connectivity or DNS issue, not a licensing problem.

Full explanation →

689

MCQeasy

A FortiGate administrator needs to backup the configuration to a remote TFTP server. Which CLI command should be used?

A.copy config tftp <filename> <tftp_server_ip>

B.execute restore config tftp <filename> <tftp_server_ip>

C.execute backup config tftp <filename> <tftp_server_ip>

D.backup configuration to tftp <tftp_server_ip>

AnswerC

This is the correct command for backing up a FortiGate configuration to a TFTP server. The `execute backup` keyword pair is the standard CLI mechanism for exporting device state, and `config tftp` specifies the destination protocol and remote host. The filename argument is the remote file name to create on the TFTP server, followed by the server's IP, and this command will save the active configuration without altering the running system.

Why this answer

The 'execute backup config tftp' command is the proper CLI syntax in FortiOS for backing up the current configuration to a remote TFTP server. This command triggers an immediate backup operation, and the filename and TFTP server IP are required parameters to specify the destination.

Exam trap

The trap here is that candidates familiar with Cisco IOS may mistakenly choose 'copy config tftp' (Option A) or 'backup configuration to tftp' (Option D), but FortiOS uses the 'execute' command structure and specific syntax 'backup config tftp' for this operation.

How to eliminate wrong answers

Option A is wrong because 'copy config tftp' is not a valid FortiOS command; Fortinet uses the 'execute' prefix for operational commands, and 'copy' is used in Cisco IOS, not FortiOS. Option B is wrong because 'execute restore config tftp' is used to restore a configuration from a TFTP server, not to back up; the keyword 'restore' indicates the opposite direction of data flow. Option D is wrong because 'backup configuration to tftp' is not a valid CLI command in FortiOS; the correct syntax requires the 'execute' keyword and the order 'backup config tftp'.

Full explanation →

690

MCQmedium

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?

A.Static route with a higher distance

B.Virtual IP (VIP) with port forwarding

C.Policy-based routing (PBR) in the firewall policy

D.SD-WAN rule to force traffic to port3

AnswerC

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.

Full explanation →

691

MCQmedium

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?

A.Enable 'Log Memory' on the policy

B.Enable security profiles

C.Set the log generation to 'All sessions' in the policy

D.Configure a traffic shaper

AnswerC

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.

Full explanation →

692

MCQhard

A FortiGate receives a file via SMTP that contains a virus. The antivirus profile is set to 'Block' for viruses and the action is set to 'Quarantine'. However, the email is delivered to the user with the infected attachment. What could be the reason?

A.The email filter profile is overriding the antivirus action

B.The antivirus profile is using flow-based inspection and the SMTP scan is not enabled

C.The antivirus signatures are outdated

D.The file is larger than the FortiGate's virus database can handle

AnswerB

Flow-based antivirus inspection does not scan every protocol by default; the antivirus profile must explicitly enable each protocol such as SMTP. In a flow-based profile, if SMTP scanning is left unchecked, mail attachments bypass the antivirus engine entirely — even when signatures are current and the same virus would be caught over HTTP or FTP. Proxy-based inspection, by contrast, scans all supported protocols (SMTP, POP3, IMAP, HTTP, FTP) out of the box, which is why this behavior is specifically tied to a flow-based profile with SMTP disabled.

Why this answer

B is correct because when an antivirus profile uses flow-based inspection, it must have SMTP scanning explicitly enabled in the profile settings. If SMTP scan is not enabled, the FortiGate will not inspect SMTP traffic for viruses, allowing infected attachments to pass through regardless of the antivirus action set to 'Block' and 'Quarantine'. Proxy-based inspection, by contrast, scans all protocols by default, but flow-based requires per-protocol enablement.

Exam trap

The trap here is that candidates assume the 'Block' and 'Quarantine' actions apply globally to all traffic, overlooking that flow-based inspection requires explicit protocol selection within the antivirus profile for SMTP scanning to occur.

How to eliminate wrong answers

Option A is wrong because email filter profiles handle spam, phishing, and content filtering, not virus detection; they cannot override the antivirus action for viruses. Option C is wrong because outdated signatures would cause missed detection of new viruses, but the question states the file contains a virus that the antivirus profile is configured to block, implying the signatures should detect it; the issue is inspection mode, not signature age. Option D is wrong because FortiGate's antivirus engine can scan files up to the configured buffer size (default 10 MB for flow-based, larger for proxy-based), and there is no indication the file exceeded this limit; the problem is that SMTP scanning is not enabled in the flow-based profile.

Full explanation →

693

MCQmedium

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?

A.Configure a VIP for source NAT

B.Use policy-based routing to send traffic through a NAT device

C.Enable 'NAT' on the firewall policy and use the outgoing interface address

D.Create a one-to-one IP pool and apply it to the policy

AnswerC

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.

Full explanation →

694

MCQeasy

Which of the following best describes a Virtual IP (VIP) in FortiGate?

A.A method to translate a public IP/port to a private IP/port for inbound traffic

B.A method to translate private source IPs to a public IP for outbound traffic

C.A method to group multiple firewall policies

D.A method to load balance traffic across multiple WAN interfaces

AnswerA

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.

Full explanation →

695

MCQeasy

What is the difference between certificate inspection and full SSL deep inspection on a FortiGate?

A.Certificate inspection decrypts traffic; deep inspection does not

B.Certificate inspection only validates the server certificate; deep inspection decrypts and inspects the content

C.Deep inspection is faster than certificate inspection

D.Both provide the same level of security

AnswerB

Certificate inspection reads only the server certificate's subject and issuer fields to validate trust, leaving payload encrypted. Deep inspection terminates the TLS session, decrypts traffic, and inspects content, which is the actual axis distinguishing the two inspection modes.

Why this answer

Certificate inspection only validates the server certificate's authenticity and checks for revocation, but does not decrypt the traffic payload. Full SSL deep inspection (also called SSL inspection) decrypts the entire SSL/TLS session, allowing the FortiGate to inspect the content for threats like malware, data leaks, or policy violations. This is why option B is correct: certificate inspection validates the certificate, while deep inspection decrypts and inspects the content.

Exam trap

The trap here is that candidates often confuse 'certificate inspection' with 'deep inspection,' assuming both decrypt traffic, but Fortinet specifically defines certificate inspection as a non-decrypting, lightweight validation method.

How to eliminate wrong answers

Option A is wrong because certificate inspection does not decrypt traffic; it only validates the certificate, whereas deep inspection does decrypt. Option C is wrong because deep inspection is actually slower than certificate inspection due to the overhead of decrypting and re-encrypting traffic. Option D is wrong because certificate inspection provides far less security than deep inspection, as it cannot inspect the encrypted payload for threats.

Full explanation →

696

MCQhard

A FortiGate has two WAN interfaces (wan1, wan2) configured with ECMP routes to the same destination. The administrator notices that traffic for a single session is being load-balanced across both links, causing performance issues. What should be configured to ensure sessions stick to one link?

A.Set policy routing to use source-based routing.

B.Change ECMP load balancing method to 'source-ip-based' or 'source-dst-ip-based'.

C.Configure SD-WAN rules to enforce per-session stickiness.

D.Disable ECMP and use a single default route.

AnswerB

Changing the ECMP load balancing method to 'source-ip-based' or 'source-dst-ip-based' forces the FortiGate to compute a deterministic hash from either the source IP alone or the source-destination IP pair for each session. All packets in a session share the same hash value, so they are consistently forwarded out the same WAN interface, preventing out-of-order delivery and dropped sessions. This is the built-in, scalable mechanism for per-session stickiness across equal-cost routes.

Why this answer

Changing the ECMP load balancing method to 'source-ip-based' or 'source-dst-ip-based' ensures that all packets belonging to the same session (identified by source IP or source-destination IP pair) are hashed to the same egress interface. This prevents a single session from being split across multiple WAN links, which can cause out-of-order packets and performance degradation. FortiGate’s ECMP hash algorithm uses the configured method to compute a hash value that deterministically selects the outgoing interface for each flow.

Exam trap

The trap here is that candidates often confuse ECMP load balancing methods with SD-WAN stickiness features, assuming SD-WAN is required for session persistence, when in fact ECMP’s hash algorithm can be tuned directly to achieve per-session stickiness.

How to eliminate wrong answers

Option A is wrong because policy routing (PBR) is used to override the routing table based on criteria like source/destination IP or port, but it does not inherently provide per-session stickiness; without careful configuration, PBR can still lead to asymmetric routing or session splitting. Option C is wrong because SD-WAN rules can enforce stickiness via session-based load balancing (e.g., 'source-ip-based' or 'session-based'), but the question specifically asks about ECMP routes, and SD-WAN is a separate feature that requires additional configuration and is not the direct fix for ECMP load balancing. Option D is wrong because disabling ECMP and using a single default route eliminates load balancing entirely, which is an overreaction and does not address the requirement to keep sessions on one link while still allowing load balancing across different sessions.

Full explanation →

697

MCQhard

An administrator wants to block users from uploading files to cloud storage services like Google Drive via HTTPS. Which security profile combination is required?

A.Application control profile to block cloud storage applications, with deep inspection enabled

B.IPS profile to block file uploads to cloud services

C.DNS filter to block Google Drive domain

D.Web filter profile with URL filter to block Google Drive

AnswerA

Deep inspection decrypts the TLS session, exposing the HTTPS upload stream so application control can identify and block Google Drive by its application signature. Without it, the traffic stays encrypted and only SNI or certificate metadata is visible, which cannot reliably stop file uploads to cloud storage.

Why this answer

To block file uploads to cloud storage services like Google Drive over HTTPS, an application control profile is required because it can identify and control specific application actions (e.g., file uploads) within encrypted traffic. Deep inspection must be enabled to decrypt the HTTPS traffic, allowing the FortiGate to inspect the application-layer payload and enforce the upload blocking rule.

Exam trap

The trap here is that candidates often assume a web filter or DNS filter can block specific actions within an encrypted session, but only application control with deep inspection can inspect HTTPS payloads to differentiate between uploading, downloading, or browsing.

How to eliminate wrong answers

Option B is wrong because an IPS profile is designed to detect and prevent network-based attacks and vulnerabilities, not to control application-specific actions like file uploads to cloud services. Option C is wrong because a DNS filter blocks domains at the DNS resolution level, but it cannot block file uploads within an already-established HTTPS session to Google Drive. Option D is wrong because a web filter profile with a URL filter can block access to the entire Google Drive domain, but it cannot selectively block only file uploads while allowing other activities like viewing or downloading.

Full explanation →

698

MCQhard

A FortiGate administrator needs to configure a policy so that traffic to a specific external server is exempted from SSL deep inspection. Which method should be used?

A.Add the server's address to the 'SSL/SSH Inspection Profile' exemptions list

B.Create a separate firewall policy without SSL inspection for that server

C.Disable the IPS sensor on that policy

D.Set the antivirus profile to 'monitor' only

AnswerA

The Exemptions list inside an SSL/SSH Inspection Profile lets the administrator define destination addresses that FortiGate should not attempt to decrypt, even though the deep-inspection profile remains attached to the firewall policy. Matched traffic is allowed to pass through the gateway without a TLS/SSL man-in-the-middle re-signing handshake, so it avoids certificate-validation failures for servers that use certificate pinning or restricted ciphers. This is the recommended approach because it keeps the policy architecture clean and confines exception handling to the inspection profile itself.

Why this answer

The SSL/SSH Inspection Profile includes an 'Exemptions' list where you can specify destination addresses that should bypass SSL deep inspection. This allows traffic to a specific external server to be excluded from SSL inspection without creating a separate firewall policy, ensuring that other security profiles (like antivirus, IPS, and web filtering) still apply to that traffic.

Exam trap

The trap here is that candidates often think they must create a separate firewall policy to bypass SSL inspection, but FortiGate's design intentionally centralizes SSL exemption within the inspection profile to maintain policy simplicity and avoid unintended security gaps.

How to eliminate wrong answers

Option B is wrong because creating a separate firewall policy without SSL inspection would require duplicating all other security profile settings and could lead to policy management complexity; the intended method is to use the exemption list within the SSL/SSH Inspection Profile. Option C is wrong because disabling the IPS sensor does not affect SSL inspection; it only disables intrusion prevention, leaving SSL deep inspection still active. Option D is wrong because setting the antivirus profile to 'monitor' only changes the action for antivirus detection (from block to log-only) but does not exempt traffic from SSL deep inspection.

Full explanation →

699

MCQmedium

An administrator configures an application control profile to block social media applications. Users can still access Facebook and Twitter via web browsers. What is the most likely reason?

A.The application signatures for Facebook and Twitter are not up to date

B.The firewall policy has SSL/SSH inspection set to 'certificate-inspection' instead of 'deep-inspection'

C.The application control profile is set to 'monitor' instead of 'block'

D.The firewall policy is configured with flow-based inspection

AnswerB

The correct reason for the failure is that the firewall policy uses certificate-inspection instead of deep-inspection. In certificate-inspection mode, the FortiGate validates the server certificate but does not decrypt the HTTPS payload, so the application control engine is blind to the actual web requests and cannot identify Facebook or Twitter traffic. Deep-inspection performs a man-in-the-middle decryption by presenting a generated CA certificate to the client, decrypting the session, scanning the content with application control and other security profiles, then re-encrypting the traffic. Without deep-inspection, application control can at best rely on incomplete heuristics like SNI, which is often insufficient for modern applications that use encrypted transports or certificate pinning.

Why this answer

When SSL/SSH inspection is set to 'certificate-inspection' (default), the FortiGate only inspects the certificate handshake and cannot decrypt the encrypted application-layer traffic. Social media applications like Facebook and Twitter use HTTPS, so without deep inspection (full decryption), the application control profile cannot identify and block the application signatures within the encrypted payload. Deep inspection is required to decrypt the traffic and allow the IPS engine to match application signatures.

Exam trap

The trap here is that candidates often assume application control works on all traffic regardless of encryption, but FortiGate requires deep inspection to inspect encrypted application payloads, and certificate inspection alone is insufficient for application control to function on HTTPS traffic.

How to eliminate wrong answers

Option A is wrong because outdated signatures would affect all traffic equally, not just encrypted traffic, and the administrator would likely see a signature update warning; the issue here is decryption, not signature freshness. Option C is wrong because if the profile were set to 'monitor', the administrator would see log entries for the blocked applications, but the question states users can still access the sites, implying no action is being taken—this points to a decryption failure, not a profile action setting. Option D is wrong because flow-based inspection is a processing mode (flow vs. proxy) that affects how the firewall processes traffic, but it does not prevent application control from working; deep inspection can still be applied in flow mode, so this is not the root cause.

Full explanation →

700

MCQhard

A FortiGate is configured with flow-based antivirus and an IPS profile on a policy. The administrator runs 'diagnose ips packet-list' and sees that packets are being forwarded without inspection. What is the most likely reason?

A.The session is offloaded to the NPU and is not being sent to the IPS engine

B.The antivirus profile is set to proxy-based, conflicting with flow-based IPS

C.The IPS profile is configured with 'monitor' mode instead of 'protect'

D.The traffic is UDP and flow-based inspection does not inspect UDP

AnswerA

In flow-based inspection, FortiGate ASICs such as the NP6/NP7 processors can offload entire sessions after the initial SYN/connection-setup packets are examined by the CPU. Once offloaded, the IPS engine never sees the remaining packets, so the IPS statistics and logs will show no inspection activity for that flow. This is by design in flow-based mode when the session meets offload criteria, and it does not indicate a misconfiguration or failure.

Why this answer

When a FortiGate offloads a session to the NPU (Network Processor Unit), the traffic bypasses the CPU and therefore does not reach the IPS engine for inspection. The 'diagnose ips packet-list' command shows packets forwarded without inspection because the NPU handles them directly, and flow-based inspection requires the session to be processed by the IPS engine on the CPU. This is the most likely reason when the administrator observes packets bypassing inspection despite having flow-based antivirus and IPS profiles applied.

Exam trap

The trap here is that candidates assume 'diagnose ips packet-list' always shows all traffic, but they overlook that NPU offloading can bypass the IPS engine entirely, making the command show no inspected packets even when inspection is configured.

How to eliminate wrong answers

Option B is wrong because flow-based and proxy-based profiles can coexist on the same policy; the antivirus profile being proxy-based does not conflict with a flow-based IPS profile, as each security profile operates independently. Option C is wrong because 'monitor' mode in an IPS profile logs or alerts on detected threats but still sends traffic to the IPS engine for inspection; it does not cause packets to be forwarded without inspection. Option D is wrong because flow-based inspection does inspect UDP traffic; UDP sessions are inspected by the IPS engine just like TCP sessions, and there is no protocol-based exclusion in flow-based inspection.

Full explanation →

701

MCQeasy

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?

A.Disable NAT and rely on the FortiGate to route private IPs.

B.Enable NAT and use a central NAT table with a specific IP pool.

C.Enable NAT and use a fixed port range for source translation.

D.Enable NAT and use the outgoing interface address.

AnswerD

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.

Full explanation →

702

Multi-Selectmedium

A FortiGate administrator is configuring a hub-and-spoke IPsec VPN with three spokes. Each spoke has a dial-up connection to the hub. The hub uses a dynamic DNS name. Which THREE settings are necessary on each spoke to establish the VPN?

Select 3 answers

A.A static route on the spoke for the hub's local networks

B.The pre-shared key or certificate for authentication

C.Hub's public IP address or FQDN as remote gateway

D.The Phase 2 proposal (encryption, authentication, etc.)

E.NAT enabled on the spoke tunnel interface

AnswersB, C, D

The pre-shared key or certificate is a mandatory authentication credential for IKE Phase 1, used by both sides to mutually authenticate before any encryption negotiation occurs. Without a matching PSK or a valid trusted certificate on the spoke, the hub will reject the initial IKE request, and no tunnel can be built. FortiGate supports both PSK and certificate-based authentication, but one must be explicitly configured on the spoke.

Why this answer

In a hub-and-spoke IPsec VPN with dial-up spokes, each spoke must authenticate with the hub. The pre-shared key or certificate (Option B) is required for IKE Phase 1 authentication, ensuring the spoke is trusted before the tunnel is established. Without this, the hub will reject the connection attempt.

Exam trap

The trap here is that candidates often think a static route (Option A) is required for VPN establishment, but routes only direct traffic after the tunnel is up, not for the IKE negotiation itself.

Full explanation →

703

Multi-Selectmedium

Which TWO statements about firewall policy authentication are correct?

Select 2 answers

A.Authentication cannot be used with FSSO

B.Authentication is only supported for inbound traffic

C.Authentication can be configured on a per-policy basis

D.Authentication can be based on local, LDAP, or RADIUS databases

E.Authentication is performed after the traffic is allowed by the policy

AnswersC, D

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.

Full explanation →

704

MCQhard

An administrator notices that traffic to a specific HTTPS website is being blocked. The FortiGate has SSL inspection enabled, and the web filter profile is set to monitor all categories. The URL is not in any blocked category. What should the administrator check next?

A.Check if the SSL inspection policy is using certificate inspection instead of full SSL inspection.

B.Review the SSL/SSH inspection profile's certificate revocation check settings.

C.Ensure that the FortiGate has the latest web filter database.

D.Verify that the web filter has the correct rating for the URL.

AnswerB

The SSL/SSH inspection profile contains certificate revocation check settings that validate the server certificate against Certificate Revocation Lists (CRL) and/or OCSP responders. If the revocation check is enabled and the site's certificate is revoked, the FortiGate will refuse to establish the TLS connection and block the HTTPS session, even if the URL category is allowed. This directly explains why traffic to a specific HTTPS site fails while other sites still work, making it the correct first step to review. Additionally, strict blocking can also occur if the OCSP responder is unreachable, so reviewing these settings is essential.

Why this answer

When SSL inspection is enabled and a specific HTTPS site is blocked despite not being in a blocked category, the issue often lies in the SSL/SSH inspection profile's certificate revocation check. If the FortiGate cannot verify the server's certificate revocation status (e.g., via OCSP or CRL), it may block the connection as a security precaution, even if the web filter category allows the URL. Option B directly addresses this by suggesting a review of the revocation check settings.

Exam trap

The trap here is that candidates often assume HTTPS blocking is always due to web filter categories or inspection depth, overlooking that certificate revocation checks in the SSL inspection profile can independently block traffic even when the URL is allowed by the web filter.

How to eliminate wrong answers

Option A is wrong because certificate inspection only examines the SNI and certificate metadata, not the full payload, but the question states SSL inspection is enabled and the web filter is set to monitor all categories; the blocking is likely due to certificate validation failure, not inspection depth. Option C is wrong because the web filter database being outdated would affect URL categorization, but the URL is not in any blocked category, so the database is likely current; the issue is with SSL certificate validation, not URL ratings. Option D is wrong because the administrator already knows the URL is not in a blocked category, so re-verifying the rating would not resolve a block caused by certificate revocation check failure.

Full explanation →

705

MCQeasy

Which log severity level indicates that the system is unusable?

A.Error

B.Critical

C.Alert

D.Emergency

AnswerD

Emergency is the highest severity level (0) in FortiGate's logging hierarchy and specifically denotes that the system is unusable, as seen with a kernel panic, critical hardware failure, or complete resource exhaustion. When a FortiGate logs at Emergency severity, the device has either crashed or lost its ability to function, requiring manual intervention or a reboot. This exact definition matches the question's criterion, confirming Emergency as the correct answer.

Why this answer

The Emergency severity level (level 0) indicates that the system is unusable. It is the highest severity level in syslog (RFC 5424) and is used for catastrophic failures. Alert (level 1) indicates immediate action needed, Critical (level 2) indicates critical conditions, and Error (level 3) indicates error conditions, but Emergency specifically means the system is unusable.

Exam trap

The trap is confusing Emergency with Alert or Critical; candidates might think Alert means the system is unusable, but Emergency is the only level that explicitly indicates that.

How to eliminate wrong answers

Option A is wrong because Error (level 3) indicates non-critical errors that don't render the system unusable. Option B is wrong because Critical (level 2) indicates critical conditions but the system may still be partially operational. Option C is wrong because Alert (level 1) requires immediate action but does not necessarily mean the system is unusable.

Full explanation →

706

MCQmedium

A FortiGate administrator needs to ensure that all DNS queries from internal clients are forwarded to a specific DNS server for security filtering. Which configuration should be applied?

A.Use policy routing to redirect DNS traffic to the server

B.Create a firewall policy to allow DNS traffic to the external server only

C.Enable DNS forwarding under Network > DNS and set the system DNS to the desired server

D.Configure a DNS database on the FortiGate

AnswerC

Enabling DNS forwarding under Network > DNS configures the FortiGate to accept DNS queries sent to its interface IP and then forward them to the system DNS servers, which you set to the desired server. This makes the FortiGate act as a DNS proxy or forwarder, ensuring that all clients that use the FortiGate as their DNS server have their queries resolved by the specified upstream server. It also provides the benefit of caching DNS responses. This is the correct and intended feature for this scenario because it directly addresses the need to centralize and control DNS resolution.

Why this answer

DNS forwarding on FortiGate allows the device to act as a DNS relay, intercepting DNS queries from internal clients and forwarding them to a specified DNS server for security filtering. This is configured under Network > DNS by setting the system DNS to the desired server, which ensures all DNS traffic is redirected without requiring policy routing or firewall rule changes.

Exam trap

The trap here is that candidates often confuse DNS forwarding with policy routing or firewall policies, assuming traffic redirection requires explicit routing or allow rules, rather than understanding that DNS forwarding is a dedicated application-layer relay feature.

How to eliminate wrong answers

Option A is wrong because policy routing is used to steer traffic based on routing criteria (e.g., source/destination IP), not to transparently forward DNS queries; it would require complex rules and does not inherently provide DNS-specific relay functionality. Option B is wrong because creating a firewall policy to allow DNS traffic to an external server only permits traffic but does not force all internal DNS queries to that server; clients could still use other DNS servers if configured. Option D is wrong because a DNS database on FortiGate is used for hosting local DNS records (e.g., for internal resolution or split DNS), not for forwarding queries to an external security filtering server.

Full explanation →

707

MCQhard

In an active-active HA cluster, session synchronization is configured. A new session is created on the primary unit. When does the secondary unit learn about this session?

A.During the next heartbeat interval

B.After the session is closed

C.Within a few milliseconds to seconds after creation

D.Immediately upon session creation

AnswerC

In FortiGate active-active HA, session synchronization is triggered periodically (default every 200 ms) as well as on immediate state changes such as session setup or teardown. Because of this periodic timer, a newly created session is typically copied to the secondary within a few hundred milliseconds to a couple of seconds, giving the secondary nearly up-to-date state without the performance overhead of instantaneous synchronous replication on every packet.

Why this answer

In an active-active HA cluster, FortiGate performs real-time session synchronization (session-pickup) between cluster members over the HA heartbeat link. When a new session is created on the primary, the session table entry is pushed to the secondary almost instantly — typically within milliseconds, though under load it can take up to a few seconds. This ensures that if a failover occurs, existing sessions continue without being dropped.

Exam trap

NSE4 often tests the misconception that HA synchronization happens on a fixed heartbeat schedule, when in fact session state is replicated continuously and asynchronously as sessions are created or updated.

How to eliminate wrong answers

Option A is wrong because session synchronization is event-driven and continuous, not batched at heartbeat intervals — heartbeats carry HA state, not session tables. Option B is wrong because waiting until session close would defeat the purpose of HA session pickup; failover would drop all active sessions. Option D is wrong because 'immediately' implies zero latency, but synchronization is asynchronous and subject to processing/network delay, so a small but nonzero delay always exists.

Full explanation →

708

MCQeasy

Which statement about the implicit deny policy at the bottom of the firewall policy list is true?

A.It only applies to traffic from the internet

B.It can be edited to change the action to accept

C.It is optional and can be removed

D.It drops all traffic that does not match any explicit policy

AnswerD

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.

Full explanation →

709

MCQhard

A FortiGate administrator is troubleshooting a dial-up IPsec VPN where remote users can connect but traffic does not pass. The Phase 1 and Phase 2 status show 'up'. The administrator runs 'diagnose vpn tunnel list' and sees the tunnel is up. However, 'diagnose sys session list' shows no sessions for the remote user's IP. What is the MOST likely cause?

A.The Phase 2 proposal uses AES256 but the remote client only supports AES128

B.The FortiGate's routing table does not have a route to the remote user's subnet

C.There is no firewall policy permitting traffic from the dial-up interface to the destination network

D.The remote user's FortiClient is blocking split tunneling

AnswerC

The FortiGate's implicit deny rule silently discards any traffic that does not match an explicit firewall policy, including traffic arriving from a dial-up IPsec tunnel interface. Even if the Phase 1 and Phase 2 SAs are fully up, the FortiGate will not forward packets from the remote VPN user to the internal destination unless a policy exists allowing that traffic between the VPN interface (e.g., ssl.root or dialup) and the destination zone. Since the session table is empty, the packets are being dropped by the firewall policy lookup, making a missing policy the most direct and common cause.

Why this answer

Even when Phase 1 and Phase 2 are up and the tunnel is established, traffic will not pass through a dial-up IPsec VPN unless a firewall policy explicitly permits traffic from the dial-up interface (often the virtual IPsec interface) to the destination network. The 'diagnose sys session list' showing no sessions for the remote user's IP confirms that the FortiGate is not processing any traffic for that user, which points to a missing or misconfigured firewall policy rather than an encryption or routing issue.

Exam trap

The trap here is that candidates assume an 'up' Phase 1 and Phase 2 guarantee traffic flow, but FortiGate requires a separate firewall policy to permit traffic from the IPsec interface to the destination, and the absence of sessions in 'diagnose sys session list' is the key diagnostic clue for this missing policy.

How to eliminate wrong answers

Option A is wrong because if the Phase 2 proposal used AES256 but the remote client only supported AES128, the Phase 2 would not come up at all; the status would show 'down' or negotiation would fail. Option B is wrong because in a dial-up IPsec VPN, the remote user's IP is dynamically assigned and not a subnet that requires a static route; the FortiGate uses the IPsec interface itself to route traffic back to the remote user. Option D is wrong because split tunneling on FortiClient controls which traffic goes over the VPN versus the local internet, but it does not prevent the FortiGate from seeing sessions; if the tunnel is up and traffic is sent, sessions would appear in 'diagnose sys session list' regardless of split tunneling settings.

Full explanation →

710

MCQeasy

A FortiGate administrator needs to allow remote management of a FortiGate from the internet. Which administrative access protocols should be enabled on the WAN interface? (Choose the best single answer.)

A.Ping and SNMP

B.HTTP and Telnet

C.FTP and TFTP

D.HTTPS and SSH

AnswerD

HTTPS (port 443) provides an encrypted web-based management interface, and SSH (port 22) offers an encrypted command-line session, both ensuring that all administrative traffic remains confidential and tamper-proof. These are the recommended protocols for remote management because they protect login credentials and configuration changes from eavesdropping. FortiGate also allows these protocols to be enabled selectively per interface and with trusted-host restrictions, which is a security best practice.

Why this answer

HTTPS (port 443) and SSH (port 22) are the only secure administrative access protocols that provide encrypted communication for remote management over the internet. HTTP and Telnet transmit credentials and data in plaintext, making them unsuitable for WAN-facing interfaces. FortiGate best practices mandate disabling all insecure protocols on external interfaces and enabling only HTTPS and SSH for administrative access.

Exam trap

The trap here is that candidates often confuse 'administrative access' with 'monitoring or file transfer protocols' (e.g., SNMP, FTP) or fail to recognize that HTTP and Telnet are insecure for internet-facing interfaces, leading them to choose options that include unencrypted protocols.

How to eliminate wrong answers

Option A is wrong because Ping (ICMP) is not an administrative access protocol—it is used for connectivity testing, and SNMP is a monitoring protocol, not a management interface for CLI/GUI access. Option B is wrong because HTTP and Telnet both transmit data in plaintext, exposing credentials and configuration to interception, and are strongly discouraged on any internet-facing interface. Option C is wrong because FTP and TFTP are file transfer protocols, not administrative access protocols; they do not provide a command-line or web-based management interface for the FortiGate itself.

Full explanation →

711

MCQhard

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?

A.The FortiGate's system time is incorrect

B.A deny policy with higher priority is blocking the traffic

C.The schedule object is not correctly applied to the policy

D.The schedule object only allows traffic on weekdays, and Saturday is not included

AnswerD

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.

Full explanation →

712

Multi-Selecthard

Which THREE statements about FortiGate's 'config system global' settings are true? (Choose three.)

Select 3 answers

A.The 'trusthost' setting restricts administrative access to specific source IPs.

B.The 'admin-login-retry-limit' setting limits the number of failed login attempts before lockout.

C.The 'hostname' setting sets the device name displayed in the GUI.

D.The 'allowaccess' setting controls which protocols are allowed on an interface.

E.The 'timezone' setting sets the FortiGate's local time zone.

AnswersB, C, E

This is correct because 'admin-login-retry-limit' is a global security setting under config system global. It defines the maximum number of consecutive failed administrator login attempts (default is 3) before the source IP is locked out for a period (admin-lockout-duration). This helps mitigate brute-force attacks on management interfaces and applies across all administrators and access methods.

Why this answer

The 'admin-login-retry-lockout' setting (often referred to as 'admin-login-retry-limit' in older firmware) defines the number of consecutive failed administrative login attempts before the administrator account is locked out for a specified duration. This is a security feature to prevent brute-force attacks against the management interface.

Exam trap

The trap here is confusing global system settings with interface-specific or admin-specific settings, leading candidates to select 'trusthost' or 'allowaccess' which are configured in different contexts (admin and interface respectively).

Full explanation →

713

Multi-Selecteasy

Which TWO types of inspection can be used for HTTPS traffic in a FortiGate security policy?

Select 2 answers

A.Deep inspection

B.Certificate inspection

C.Full inspection

D.Flow-based inspection

E.Proxy-based inspection

AnswersA, B

Deep inspection decrypts SSL/TLS traffic, inspects the full payload and headers for threats, then re-encrypts it before forwarding. This allows FortiGate to detect malicious content hidden inside encrypted sessions, but requires clients to trust a FortiGate CA certificate. It is one of the two valid HTTPS inspection types in Fortinet's NSE4 curriculum.

Why this answer

FortiGate security policies can inspect HTTPS traffic using either deep inspection or certificate inspection. Deep inspection decrypts the SSL/TLS session, inspects the full payload for threats like malware or data leakage, and re-encrypts the traffic, while certificate inspection only validates the server certificate without decrypting the content, checking for certificate validity and revocation.

Exam trap

The trap here is that candidates confuse processing modes (flow-based and proxy-based) with inspection types (deep and certificate), leading them to select flow-based or proxy-based as inspection methods instead of recognizing them as underlying operational modes.

Full explanation →

714

Multi-Selecthard

A FortiGate is configured in active-active HA mode. An administrator notices that session failover is not working properly during a failover event. Which THREE configurations should be checked?

Select 3 answers

A.Ensure the load-balance method is set to 'load-balance' or 'weighted-load-balance'.

B.Enable session synchronization under HA settings.

C.Increase the session TTL.

D.Set the HA mode to 'active-passive'.

E.Verify that all interfaces are included in the HA configuration.

AnswersA, B, E

In active-active HA, the cluster must use a load-balancing algorithm to distribute new sessions among all units. Setting the load-balance method to 'load-balance' or 'weighted-load-balance' ensures that session distribution occurs, rather than having one unit handle all traffic. This is a foundational requirement for true active-active operation and is separate from session synchronization.

Why this answer

In active-active HA mode, the load-balance method must be set to 'load-balance' or 'weighted-load-balance' to ensure that session ownership is properly distributed and that session failover can occur. If the method is set to 'hub' or 'spoke', session synchronization and failover may not function as expected, as these modes are designed for different topologies.

Exam trap

The trap here is that candidates may assume session failover is solely dependent on enabling session synchronization, overlooking the critical requirement that the load-balance method must be correctly set for active-active mode to distribute and synchronize sessions properly.

Full explanation →

715

MCQmedium

A company wants to provide remote access to internal resources for employees using laptops that may connect from untrusted networks. The security team requires that all traffic between the remote users and the corporate network be encrypted, and that users must authenticate using a username/password plus a one-time passcode from a hardware token. Which FortiGate VPN solution best meets these requirements?

A.IPsec VPN with certificate-based authentication

B.SSL VPN with local password authentication

C.SSL VPN with FortiToken two-factor authentication

D.L2TP/IPsec VPN with a pre-shared key and user password

AnswerC

SSL VPN with FortiToken two-factor authentication correctly combines HTTPS-based encrypted remote access with a time-based one-time password (TOTP) generated by FortiToken. This provides two distinct factors: something the user knows (password) and something the user has (FortiToken device or mobile app). FortiGate can enforce this at the firewall policy level, ensuring both factors are verified before tunnel establishment.

Why this answer

SSL VPN with FortiToken two-factor authentication meets the requirement for encrypted remote access with username/password plus a one-time passcode from a hardware token. SSL VPN provides encrypted tunnels over HTTPS, and FortiToken adds the required second factor, ensuring strong authentication even from untrusted networks.

Exam trap

The trap here is that candidates may assume any VPN with encryption (like IPsec or L2TP/IPsec) automatically supports two-factor authentication, but FortiGate requires explicit configuration of a second factor like FortiToken, and SSL VPN is the typical solution for this requirement in the NSE4 exam context.

How to eliminate wrong answers

Option A is wrong because IPsec VPN with certificate-based authentication provides encryption but does not inherently support a one-time passcode from a hardware token; it relies on certificates, not two-factor authentication. Option B is wrong because SSL VPN with local password authentication provides encryption but only uses a single factor (password), failing the requirement for a one-time passcode. Option D is wrong because L2TP/IPsec VPN with a pre-shared key and user password provides encryption but uses only a pre-shared key and password, lacking the required two-factor authentication with a hardware token.

Full explanation →

716

MCQmedium

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?

A.Server Load Balancing VIP

B.Virtual IP (VIP) with no port forwarding

C.Static NAT (one-to-one VIP)

D.Port Forwarding VIP

AnswerD

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.

Full explanation →

717

MCQeasy

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?

A.Source: ALL, Destination: 8.8.8.8, Service: HTTPS, Action: Accept

B.Source: 10.0.0.0/8, Destination: 8.8.8.8, Service: ALL, Action: Accept

C.Source: 10.0.0.0/8, Destination: 8.8.8.8, Service: HTTPS, Action: Accept

D.Source: 10.0.0.0/8, Destination: ALL, Service: HTTPS, Action: Accept

AnswerC

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.

Full explanation →

718

MCQmedium

A FortiGate is configured for SSL deep inspection using a CA certificate. Users report that some websites show certificate errors. The administrator wants to allow these sites without inspection. Which setting should be used?

A.Disable certificate validation in the SSL inspection profile

B.Create a separate firewall policy without SSL inspection

C.Set the action for invalid certificates to 'allow'

D.Add the websites to the SSL/SSH exemption list

AnswerD

Adding the websites to the SSL/SSH exemption list tells the FortiGate to skip deep inspection for those specific domains, so the original server certificate is passed directly to the client without interception. This preserves the exact certificate and avoids breaking apps that use certificate pinning, while all other web traffic continues to be inspected with the CA-signed proxy certificate. It is the recommended, granular approach because only the listed destinations are exempted, not the entire inspection policy.

Why this answer

The SSL/SSH exemption list allows administrators to specify websites that should bypass SSL deep inspection entirely, preventing certificate errors for sites that use self-signed, expired, or otherwise untrusted certificates. This is the intended mechanism in FortiOS to exclude specific destinations from inspection while maintaining inspection for all other traffic.

Exam trap

The trap here is that candidates often confuse 'allowing invalid certificates' (Option C) with 'exempting from inspection' (Option D), not realizing that allowing invalid certificates still performs inspection and may break sites with certificate pinning, whereas exemption completely bypasses inspection.

How to eliminate wrong answers

Option A is wrong because disabling certificate validation in the SSL inspection profile would allow invalid certificates for all inspected traffic, not just specific websites, and would weaken security by accepting any certificate. Option B is wrong because creating a separate firewall policy without SSL inspection would require duplicating all other policy settings and could lead to policy misconfiguration or order issues; it is not the designed method for selective bypass. Option C is wrong because setting the action for invalid certificates to 'allow' would permit invalid certificates for all inspected traffic, not just the problematic websites, and would still attempt to inspect the traffic rather than exempting it.

Full explanation →

719

MCQmedium

In a hub-and-spoke IPsec VPN topology with FortiGate, the spoke sites cannot communicate directly with each other. What configuration change allows direct spoke-to-spoke communication?

A.Set the 'add-route' option to 'enable' on the spoke Phase 1 settings

B.Configure dynamic routing (BGP) on all sites and enable route exchange

C.Add static routes on the hub pointing to each spoke's subnet via the respective tunnels

D.Create a separate IPsec VPN between each spoke pair

AnswerD

A full mesh of separate IPsec tunnels between every spoke pair gives each site a direct path, bypassing the hub entirely. This satisfies the requirement for direct spoke-to-spoke communication, though it scales poorly as tunnel count grows quadratically.

Why this answer

In a hub-and-spoke IPsec VPN topology, spoke sites cannot communicate directly by default. To enable direct spoke-to-spoke communication, the most straightforward configuration change is to create separate IPsec VPN tunnels between each spoke pair. While ADVPN (Auto Discovery VPN) with dynamic routing is a more efficient method, it is not listed as an option.

Option D directly establishes the required tunnels, allowing traffic to bypass the hub for spoke-to-spoke traffic. Other options are insufficient: Option A only adds routes for the hub, Option B only propagates routes without establishing direct tunnels, and Option C forces traffic through the hub.

Exam trap

The trap is that candidates may think dynamic routing alone enables direct communication, but it only shares routes. Without ADVPN or explicit Phase 2 selectors, traffic still flows through the hub. The only listed option that actually creates a direct tunnel is D.

How to eliminate wrong answers

Option A is wrong because the 'add-route' option on the spoke Phase 1 settings controls whether the FortiGate automatically adds a route to the remote subnet via the IPsec tunnel, but it does not enable direct spoke-to-spoke communication; it only affects routing to the hub. Option C is wrong because adding static routes on the hub pointing to each spoke's subnet via the respective tunnels would only route traffic through the hub, not allow direct spoke-to-spoke communication; the traffic would still be forwarded through the hub, not directly between spokes. Option D is wrong because creating a separate IPsec VPN between each spoke pair would work but is not a configuration change that enables direct communication within the existing hub-and-spoke topology; it is a different topology altogether and defeats the purpose of a hub-and-spoke design.

Full explanation →

720

MCQhard

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?

A.Central NAT is enabled and overrides the per-policy NAT setting

B.The destination is a VIP that disables NAT

C.The NGFW mode is set to profile-based

D.The policy is configured in proxy inspection mode

AnswerA

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.

Full explanation →

721

MCQeasy

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.FQDN address

B.IP range address

C.Wildcard FQDN address

D.Geography address

AnswerD

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.

Full explanation →

722

MCQmedium

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?

A.The session is immediately terminated at 18:00

B.The session continues until it ends naturally

C.The session is allowed but new sessions are blocked

D.The session is terminated after a 60-second grace period

AnswerB

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.

Full explanation →

723

Multi-Selecthard

A FortiGate is configured with an IPS profile to detect and block anomalous network behavior. Which THREE types of detection does IPS anomaly detection include? (Choose three.)

Select 3 answers

A.Protocol decoding

B.Port scan detection

C.SYN flood detection

D.Signature-based detection

E.UDP flood detection

AnswersB, C, E

Port scan detection in FortiGate's IPS is an anomaly-based behavioral technique that tracks the number of unique destination ports or distinct IP addresses contacted by a single source within a defined time window. When this activity exceeds a configured threshold, the IPS flags it as a port scan, even if no individual packet matches a known signature. This is a rate-based or heuristic anomaly detection approach, making it a correct example of the IPS anomaly detection mode.

Why this answer

Port scan detection is a type of anomaly detection in FortiGate's IPS profile that identifies reconnaissance attempts by monitoring for multiple connection attempts to different ports from a single source. This behavior deviates from normal traffic patterns and is flagged as anomalous, allowing the IPS to block potential scanning activity before an attack progresses.

Exam trap

The trap here is that candidates often confuse signature-based detection (Option D) with anomaly detection, but FortiGate explicitly separates these into distinct IPS detection methods, and the question asks specifically for anomaly detection types.

Full explanation →

724

MCQhard

An administrator runs 'diagnose ips anomaly list' and sees many 'tcp_syn_flood' entries. The IPS profile has anomaly detection enabled with action 'pass'. The administrator wants to block such attacks. What change is required?

A.Increase the threshold for the anomaly

B.Enable flow-based inspection on the policy

C.Add a DoS policy from the same source

D.Change the action for the anomaly from 'pass' to 'block'

AnswerD

The 'block' action for an IPS anomaly instructs the FortiGate's IPS engine to drop packets that match the anomaly signature, thereby preventing the malicious traffic from reaching the destination. Since the current setting is 'pass', the anomaly detection only observes and allows the traffic, which is why the diagnosed anomalies are not being stopped. Setting the action to 'block' is the direct fix, as it changes the response from permitting to actively dropping the offending packets.

Why this answer

The 'pass' action in the IPS anomaly detection configuration instructs the FortiGate to only log the detected anomaly without taking any blocking action. Changing the action to 'block' ensures that when the 'tcp_syn_flood' anomaly is detected, the FortiGate will actively drop the offending packets, thereby mitigating the SYN flood attack.

Exam trap

The trap here is that candidates may think increasing the threshold (Option A) or enabling flow-based inspection (Option B) will block the attack, when in fact the anomaly action must be explicitly changed from 'pass' to 'block' to enforce dropping of malicious traffic.

How to eliminate wrong answers

Option A is wrong because increasing the threshold would make the anomaly detection less sensitive, potentially allowing more SYN flood traffic to pass before triggering, which is counterproductive to blocking attacks. Option B is wrong because flow-based inspection is a processing mode (versus proxy-based) that affects how traffic is examined, but it does not change the action taken when an anomaly is detected; the anomaly action must still be set to 'block'. Option C is wrong because adding a DoS policy from the same source is a separate mechanism for rate-based DoS protection, but it does not modify the behavior of the already-configured anomaly detection entry; the anomaly action must be changed directly.

Full explanation →

725

Multi-Selecthard

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?

Select 2 answers

A.IP Pool type: One-to-One

B.Configure a VIP for the public IP

C.Enable session helper for application

D.IP Pool type: Overload

E.Set 'Fixed Port Range' on the IP Pool

AnswersD, E

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.

Full explanation →

726

MCQmedium

An administrator configures an IPS profile to block SQL injection attacks. However, SQL injection traffic is still passing through the FortiGate. The administrator confirms the IPS profile is applied to the correct policy. What is the most likely reason?

A.The firewall policy is in proxy-based mode

B.The IPS profile is configured for anomaly detection only

C.IPS signatures for SQL injection are disabled in the profile

D.Deep inspection is required for IPS to work

AnswerC

IPS in FortiGate detects SQL injection by matching traffic against a set of pre-defined signatures in the IPS database. If the administrator has not enabled those signatures in the IPS profile, or has set them to 'pass' rather than 'block,' the attack traffic will be allowed through even though the IPS profile is applied to the policy. Each signature in FortiOS has an individual action (allow, monitor, block) that can be overridden, so the most direct reason a SQL injection would not be blocked is that the corresponding signatures are disabled or set to pass. This is the correct answer because it precisely identifies the signature-level configuration as the cause.

Why this answer

IPS profiles in FortiGate consist of a set of IPS signatures that can be individually enabled or disabled. If the administrator configured an IPS profile to block SQL injection attacks but the specific SQL injection signatures are disabled within that profile, the FortiGate will not inspect or block that traffic, even if the profile is correctly applied to the policy.

Exam trap

The trap here is that candidates assume applying an IPS profile automatically blocks all attacks, but they overlook that individual signatures within the profile must be explicitly enabled and set to 'block' for the desired attacks.

How to eliminate wrong answers

Option A is wrong because firewall policy mode (proxy-based vs. flow-based) affects how traffic is processed, but IPS can operate in both modes; proxy-based mode does not prevent IPS from blocking attacks. Option B is wrong because an IPS profile configured for anomaly detection only would still block anomalies, but the question states SQL injection traffic is passing through, implying the profile is not blocking it; the issue is not about anomaly vs. signature detection but about signature enablement. Option D is wrong because deep inspection (SSL/TLS decryption) is required for IPS to inspect encrypted traffic, but SQL injection attacks typically occur in unencrypted HTTP traffic, where deep inspection is not necessary for IPS to function.

Full explanation →

727

MCQmedium

A network engineer is configuring an SD-WAN rule to steer voice traffic to the MPLS link with the lowest latency. The SLA target is set to latency < 50 ms and jitter < 10 ms. However, the MPLS link occasionally exceeds the latency threshold. What should the engineer do to ensure voice traffic uses the best available link without manual intervention?

A.Remove the latency performance SLA and rely only on jitter.

B.Configure the SD-WAN rule with a secondary strategy to use the broadband link when SLA is not met.

C.Increase the jitter threshold to 15 ms to avoid SLA violations.

D.Disable SLA enforcement on the SD-WAN rule so voice traffic always uses the MPLS link.

AnswerB

A correct fix is to set the SD-WAN rule to use the broadband link as a secondary strategy when the primary MPLS link fails its performance SLA. In Fortinet, this is done by listing multiple link members in the rule and specifying a strategy such as 'best quality' or 'SLA' where the next available member is used as a backup. The rule then automatically moves voice traffic to broadband whenever the MPLS link violates the configured latency threshold.

Why this answer

Configuring a secondary strategy (e.g., fallback to broadband) allows the SD-WAN rule to automatically steer voice traffic to the best available link when the primary MPLS link fails the SLA (latency > 50 ms). This ensures continuous SLA compliance without manual intervention, leveraging Fortinet's SD-WAN dynamic path selection based on real-time performance metrics.

Exam trap

The trap here is that candidates often think increasing SLA thresholds or disabling SLA enforcement solves the problem, but the correct approach is to implement a fallback strategy to maintain SLA compliance automatically.

How to eliminate wrong answers

Option A is wrong because removing the latency SLA eliminates the ability to detect high-latency conditions, which could lead to poor voice quality on the MPLS link; jitter alone does not guarantee acceptable one-way delay. Option C is wrong because increasing the jitter threshold to 15 ms does not address the latency violation (which is the actual SLA failure), and it may allow unacceptable jitter levels that degrade voice quality. Option D is wrong because disabling SLA enforcement forces all voice traffic to the MPLS link regardless of its performance, defeating the purpose of SD-WAN intelligent steering and risking poor user experience when latency spikes.

Full explanation →

728

MCQmedium

A FortiGate administrator wants to integrate with FortiSandbox to analyze suspicious files detected by antivirus. The administrator configures the FortiSandbox settings under Security Fabric. However, files are not being sent to FortiSandbox. The antivirus profile is set to 'flow-based' inspection. What could be the reason?

A.The antivirus profile is set to 'Monitor' instead of 'Block'.

B.The firewall policy is using NAT, which interferes with FortiSandbox connectivity.

C.The FortiGate does not have a valid FortiSandbox license.

D.Flow-based inspection does not support FortiSandbox integration; proxy-based inspection is required.

AnswerD

FortiSandbox file submission is only supported in proxy-based inspection mode on FortiGate models. Flow-based inspection does not buffer complete files for upload; it can only perform hash-based outbreak prevention queries against the FortiSandbox database. Because the file must be fully sent to FortiSandbox for analysis, the antivirus and sandboxing features must be configured with proxy mode in the security policy. Therefore, if the policy uses flow-based inspection, FortiSandbox integration will not perform file submissions.

Full explanation →

729

MCQmedium

A FortiGate admin wants to send logs to both a local disk and a remote FortiAnalyzer. Which log configuration must be set?

A.Use the 'diagnose debug application log' command

B.Select 'Mirror local logs to FortiAnalyzer'

C.Enable local logging and configure FortiAnalyzer as a remote server

D.Set the log severity to 'Information' on both

AnswerC

The correct approach is to enable two independent log destinations in the FortiGate's log settings: first, set the local disk as a log destination (config log disk set status enable), and second, add and enable the FortiAnalyzer as a remote log server (config log fortianalyzer set status enable set server <fortianalyzer_IP>). Each destination is configured in its own block with its own severity/filter settings, and FortiGate will deliver logs to both simultaneously once both are enabled. This matches the requirement to send logs to both a local disk and a FortiAnalyzer without any dependency between the two.

Why this answer

To send logs to both local disk and a remote FortiAnalyzer, you must enable local logging (so logs are written to disk) and configure FortiAnalyzer as a remote logging server. FortiOS supports simultaneous local and remote logging when both are enabled; no special 'mirror' toggle is required for FortiAnalyzer in standard configurations. This combination satisfies the requirement of dual destinations.

Exam trap

NSE4 often tests whether candidates know that local and remote logging are configured independently, so they pick a non-existent 'mirror' option instead of enabling both destinations.

How to eliminate wrong answers

Option A is wrong because 'diagnose debug application log' is a debug command for troubleshooting the logging daemon, not a configuration method for sending logs to two destinations. Option B is wrong because 'Mirror local logs to FortiAnalyzer' is not a standard FortiOS log configuration setting; logging to FortiAnalyzer is configured by adding it as a remote log server. Option D is wrong because log severity controls which events are logged, not where logs are sent; it does not enable dual-destination logging.

Full explanation →

730

MCQhard

An administrator is troubleshooting an IPsec VPN that fails to establish. The 'diagnose vpn ike log' shows 'initial contact received'. What does this message indicate?

A.The pre-shared key is incorrect

B.The Phase 1 proposal is mismatched

C.The remote peer has restarted and cleared its security associations

D.A network address translation device is altering the IKE packets

AnswerC

When the remote peer restarts (e.g., a firewall reboot or IPsec process restart), it may send an 'Initial Contact' informational message in IKEv2 (or a delete SA notification in IKEv1) to tell the local peer to purge all existing Security Associations for that peer. If the local peer does not process or receive this message, or if the remote peer does not send it, the local peer may still reference a stale SA, causing the tunnel to fail during rekeying or when a new SA is attempted. The 'Initial Contact' mechanism is designed to force the old SAs to be deleted and a new tunnel to be established.

Why this answer

In IPsec IKE (Internet Key Exchange), an 'initial contact' notification is sent by a peer to inform the other side that it has just restarted or cleared its security associations (SAs). This message tells the receiving peer to delete any existing SAs associated with that peer, allowing a fresh IKE negotiation to begin. Therefore, the message indicates the remote peer has restarted and cleared its SAs, not a configuration or NAT issue.

Exam trap

The trap here is that candidates often misinterpret 'initial contact' as a configuration mismatch or authentication error, but it is actually a standard IKE notification indicating a peer restart, not a failure cause.

How to eliminate wrong answers

Option A is wrong because an incorrect pre-shared key would cause an authentication failure during Phase 1, typically shown as 'no proposal chosen' or 'invalid payload' in the logs, not an 'initial contact' message. Option B is wrong because a Phase 1 proposal mismatch results in the peers failing to agree on encryption/hash parameters, leading to 'no proposal chosen' errors, not an 'initial contact' notification. Option D is wrong because a NAT device altering IKE packets would cause issues like 'NAT traversal mismatch' or 'payload length mismatch', not the specific 'initial contact' message, which is a legitimate IKE notification payload (RFC 2408).

Full explanation →

731

Multi-Selectmedium

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.)

Select 2 answers

A.Reboot the FortiGate

B.Run a packet capture on the internal interface

C.Change the NAT mode to Central SNAT

D.Disable the antivirus profile

E.Check the firewall policy list for matching policies

AnswersB, E

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.

Full explanation →

732

Multi-Selectmedium

Which TWO statements about FortiGate HA heartbeat interfaces are correct?

Select 2 answers

A.Heartbeat interfaces must be in the same VDOM.

B.Heartbeat interfaces must be dedicated management ports.

C.Heartbeat interfaces must be on the same subnet.

D.Heartbeat traffic is not encrypted by default.

E.Only two heartbeat interfaces can be configured.

AnswersC, D

For HA heartbeat to work, the heartbeat interfaces on both FortiGates must be in the same subnet, typically via a direct crossover connection or through a switch on the same VLAN. This is because heartbeat packets are sent as Ethernet frames (often multicast) and require Layer 2 adjacency; without a shared broadcast domain, the units cannot detect each other or exchange session-synchronization data. If the heartbeat interfaces are on different subnets, the HA cluster will never form.

Why this answer

FortiGate HA heartbeat interfaces must be on the same subnet to allow the heartbeat packets (typically UDP port 496) to be exchanged directly between the primary and secondary units. This ensures Layer 2 adjacency is maintained for reliable failure detection and synchronization.

Exam trap

The trap here is that candidates often assume heartbeat interfaces must be in the same VDOM (Option A) because they think VDOM boundaries restrict HA communication, but FortiGate HA operates at the system level and can use interfaces from different VDOMs as long as they share a subnet.

Full explanation →

733

Multi-Selectmedium

Which TWO configuration changes can reduce the risk of unauthorized administrative access to a FortiGate?

Select 2 answers

A.Use the default 'admin' account for all administrators

B.Restrict administrative access to trusted hosts

C.Change the default administrative port

D.Set a simple password for ease of use

E.Disable both HTTPS and HTTP administrative access

AnswersB, C

Restricting administrative access to trusted hosts limits which source IP addresses can initiate management sessions to the FortiGate. By configuring an allowlist of management station IPs on each admin user or the administrative interface, you drastically reduce the attack surface and block brute-force attempts from the internet. This is a fundamental, highly effective hardening measure.

Why this answer

Restricting administrative access to trusted hosts (Option B) is a fundamental security best practice that limits the source IP addresses allowed to connect to the FortiGate management interface. By configuring a trusted host list, the FortiGate will only accept administrative sessions (e.g., HTTPS, SSH, or Telnet) from specified IP addresses or subnets, effectively blocking all unauthorized sources. This reduces the attack surface and prevents brute-force or credential-stuffing attacks from untrusted networks.

Exam trap

The trap here is that candidates often think disabling HTTPS entirely is a valid security measure, but the NSE4 exam expects you to recognize that HTTPS must remain enabled for secure remote GUI access, and that disabling both HTTP and HTTPS would render the web interface inaccessible, which is not a recommended security practice.

Full explanation →

734

MCQeasy

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?

A.Create a deny policy for source 10.0.0.99 to destination 'all' on the WAN interface, then an allow policy for all other traffic

B.Create an allow policy for source 'all' and then a deny policy for 10.0.0.99

C.Use a local-in policy to block the IP

D.Create a policy that denies all traffic from 10.0.0.99 to any destination

AnswerA

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.

Full explanation →

735

MCQeasy

Which firewall policy matching parameter is evaluated FIRST when a packet arrives at a FortiGate interface?

A.Source address

B.Service

C.Schedule

D.Incoming interface

AnswerD

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.

Full explanation →

736

MCQeasy

What is the function of an IPS 'protocol decoder'?

A.Encode traffic to prevent attacks

B.Parse and normalize protocol traffic to improve detection accuracy

C.Rate-limit traffic based on protocol

D.Decrypt SSL traffic for inspection

AnswerB

A protocol decoder parses and normalises traffic for a specific protocol, extracting fields and enforcing syntax so signatures match reliably despite evasion or fragmentation. This directly satisfies the stem's requirement to define the decoder's function: improving detection accuracy by presenting consistent, decoded data to the IPS engine.

Why this answer

An IPS protocol decoder parses and normalizes traffic for a specific protocol (e.g., HTTP, SMB, DNS) to reconstruct the application-layer data stream. This normalization strips away evasion techniques like chunked encoding or whitespace obfuscation, allowing the IPS to match attack signatures against the true payload, which significantly improves detection accuracy.

Exam trap

The trap here is that candidates confuse 'protocol decoder' with 'SSL inspection' or 'traffic shaping,' assuming any deep packet inspection function must involve decryption or rate control, when in fact the decoder's sole purpose is to parse and normalize protocol fields for accurate signature matching.

How to eliminate wrong answers

Option A is wrong because protocol decoders do not encode traffic; encoding would alter the payload and potentially hide attacks, whereas decoders normalize to reveal the original data. Option C is wrong because rate-limiting is a function of traffic shaping or QoS policies, not of protocol decoders, which focus on parsing and normalization. Option D is wrong because decrypting SSL/TLS traffic is performed by a separate SSL/SSH inspection component, not by a protocol decoder; decoders operate on already-decrypted or plaintext traffic.

Full explanation →

737

Multi-Selectmedium

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?

Select 2 answers

A.Central SNAT policy

B.An IP pool for source NAT

C.A static route on the FortiGate for the public IP

D.A VIP (Virtual IP) mapping the public IP to the private IP

E.A firewall policy allowing traffic from internal to the server's private IP

AnswersD, E

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.

Full explanation →

738

Multi-Selecthard

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?

Select 2 answers

A.Disable 'Allow Traffic' on the implicit deny policy

B.Configure a one-to-one NAT IP pool

C.Create an IP pool with type 'Overload' and specify the public IP address

D.Configure a VIP for the public IP

E.Enable 'NAT' on the firewall policy and select the IP pool

AnswersC, E

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.

Full explanation →

739

MCQmedium

A FortiGate administrator is troubleshooting an SSL VPN connection issue. Users can connect but cannot access internal resources. The administrator checks the SSL VPN policy and confirms it allows access to the internal subnet. What should the administrator check next?

A.Verify that the firewall policy between the SSL VPN interface and the internal network allows the traffic

B.Check the routing table on the FortiGate for the internal subnet

C.Ensure the users have the correct client software installed

D.Check the FortiGate's DNS settings

AnswerA

SSL VPN traffic terminates on the FortiGate, then is re-evaluated against firewall policy before reaching the internal subnet. The SSL VPN portal policy alone does not permit forwarding, so a missing or misordered policy from the SSL VPN interface to the internal network silently drops the traffic.

Why this answer

Even if the SSL VPN policy permits access to the internal subnet, traffic must still traverse a firewall policy from the SSL VPN interface (e.g., ssl.root) to the internal network interface. Without an explicit firewall policy allowing the traffic, the FortiGate will drop the packets, preventing resource access. This is a common oversight because the SSL VPN policy only controls tunnel establishment and route injection, not the actual forwarding of traffic between zones.

Exam trap

The trap here is that candidates assume the SSL VPN policy alone governs all access, overlooking the separate firewall policy requirement that actually enforces traffic flow between the SSL VPN interface and the internal network.

How to eliminate wrong answers

Option B is wrong because the routing table on the FortiGate is not the primary issue here; if users can connect to the SSL VPN, the FortiGate typically installs a route for the virtual IP pool, and the internal subnet route is usually present. Option C is wrong because the users are already connected, indicating the client software is functioning correctly for the tunnel; the problem is post-connection traffic forwarding. Option D is wrong because DNS settings affect name resolution, not direct IP-based access to internal resources; if users can connect but cannot access resources by IP, DNS is irrelevant.

Full explanation →

740

Multi-Selecteasy

An administrator needs to configure ZTNA (Zero Trust Network Access) on a FortiGate to provide secure remote access to an internal application. Which components are required for a basic ZTNA configuration? (Choose three.)

Select 3 answers

A.IPsec VPN tunnel

B.ZTNA proxy (application gateway)

C.Captive portal

D.ZTNA rule (policy) on the FortiGate

E.Access proxy (or application) configuration

AnswersB, D, E

ZTNA proxy (application gateway): Correct. The ZTNA proxy is the FortiGate's application-layer reverse proxy that terminates the user's HTTPS connection and forwards requests to the internal application server. It validates the user's identity and device posture before proxying any traffic, and it only exposes the specific application port, not the full network. This proxy is the core enforcement point for ZTNA policy.

Why this answer

The ZTNA proxy (application gateway) is the core component that terminates client connections and forwards them to internal applications after verifying device and user identity. It acts as a reverse proxy, enforcing access policies before allowing any traffic to reach the protected resource. Without this gateway, the FortiGate cannot mediate ZTNA connections.

Exam trap

The trap here is that candidates often confuse ZTNA with traditional VPNs and incorrectly assume an IPsec tunnel is mandatory, when in fact ZTNA uses a TLS reverse proxy and does not require any VPN tunnel.

Full explanation →

741

MCQmedium

An administrator applies an application control profile to a firewall policy that allows outbound traffic. Users report that a specific business-critical application, which uses TLS on port 443, is now being blocked even though the application is not listed as blocked in the profile. The administrator wants to allow this application while still controlling other applications. What is the most likely reason the application is being blocked?

A.The firewall policy is using flow-based inspection, which cannot identify applications on port 443.

B.The application is being blocked by a separate IPS sensor that is applied to the same firewall policy.

C.The application control profile requires an SSL inspection profile to detect applications on port 443, and none is applied.

D.The application control profile is configured to block all applications that are not explicitly allowed.

AnswerD

When an application control profile is set to block unknown applications or has a default action of block for categories not explicitly allowed, applications not recognized or not listed may be blocked. This is a common misconfiguration where the administrator must either add the application to an allow list or adjust the default action to allow.

Why this answer

The correct answer is that the application control profile is configured to block all applications that are not explicitly allowed. In FortiGate application control, each category and application can have an action, and there is a default action for applications not explicitly listed. If the default action is set to block, any application not in the allow list will be blocked, even if it is not explicitly blocked.

The administrator should either add the application to the allow list or change the default action to allow.

Exam trap

The trap here is assuming that only explicitly blocked applications are blocked, while overlooking the default action for unknown applications.

Full explanation →

742

MCQmedium

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?

A.VIP: external IP 203.0.113.10 port 25 -> internal IP 10.0.0.5 port 25

B.VIP: external IP 203.0.113.10 port 25 -> internal IP 10.0.0.5 port 80

C.VIP: external IP 203.0.113.10 all ports -> internal IP 10.0.0.5 all ports

D.VIP: external IP 203.0.113.10 port 80 -> internal IP 10.0.0.5 port 80

AnswerA

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.

Full explanation →

743

MCQhard

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?

A.A higher priority Central SNAT rule matches the traffic first

B.The traffic is being dropped by a security profile

C.The firewall policy has NAT disabled

D.The IP pool is configured on the wrong interface

AnswerA

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.

Full explanation →

744

MCQeasy

Which CLI command is used on a FortiGate to perform a real-time packet capture on an interface?

A.diagnose sniffer packet

B.execute packet-capture

C.diagnose debug flow

D.diagnose sys session list

AnswerA

The `diagnose sniffer packet` command is the definitive FortiOS CLI for real-time packet capture. It allows you to specify an interface (e.g., `any`, `port1`), a BPF-style filter (e.g., `host 10.0.0.1`), and a verbose level (0-4) to inspect raw packet headers and payloads as they traverse the FortiGate. This is the standard tool for live traffic analysis and packet-level troubleshooting.

Why this answer

On a FortiGate, the real-time packet capture command is 'diagnose sniffer packet <interface> <filter> <verbose> <count> <timestamp>'. It captures live packets on a specified interface with optional BPF-style filters and verbosity levels, making it the standard tool for troubleshooting traffic at the packet level. This is the FortiOS equivalent of tcpdump.

Exam trap

NSE4 often tests the distinction between packet capture ('diagnose sniffer packet') and flow tracing ('diagnose debug flow') — candidates pick debug flow because it sounds more diagnostic, but only the sniffer captures raw packets.

How to eliminate wrong answers

Option B is wrong because 'execute packet-capture' is not a valid FortiOS CLI command — 'execute' commands handle system actions like reboot, backup, or ping, not packet sniffing. Option C is wrong because 'diagnose debug flow' traces the lifecycle of a packet through the FortiGate's policy and routing engine (showing allow/deny decisions), but it does not capture raw packet contents like a sniffer. Option D is wrong because 'diagnose sys session list' displays the session table (active flows, NAT translations, timeouts), not packet payloads — it is a state inspection tool, not a capture tool.

Full explanation →

745

Multi-Selectmedium

An administrator is configuring SNMP on a FortiGate for monitoring. Which THREE items are required for SNMPv3 configuration?

Select 3 answers

A.Security level (authPriv or authNoPriv)

B.Authentication protocol (e.g., SHA) and privacy protocol (e.g., AES)

C.SNMP view definition for the user

D.SNMP community string (read-only or read-write)

E.SNMP user with username and authentication password

AnswersA, B, E

SNMPv3 adds USM security levels. Choosing authPriv enforces both authentication and encryption, while authNoPriv enforces authentication only. The security level is mandatory because it determines which credential fields must be supplied for the SNMPv3 user.

Why this answer

For SNMPv3 on a FortiGate, the security level (Option A) must be specified because SNMPv3 defines whether messages are authenticated only (authNoPriv) or both authenticated and encrypted (authPriv), which directly determines the security mechanisms applied to the user. Option B is required because SNMPv3 authentication uses a hash protocol such as SHA (or MD5) and privacy uses an encryption protocol such as AES (or DES); these protocol selections must be configured alongside the passwords to build the user's security parameters. Option E is required because SNMPv3 is user-based rather than community-based, so an SNMP user must be created with a username and authentication password (and, when authPriv is used, a privacy password) before the FortiGate can respond to SNMPv3 queries.

Option C is not required for basic SNMPv3 configuration because views are optional MIB access restrictions, not mandatory parameters for creating an SNMPv3 user. Option D is incorrect because community strings apply to SNMPv1 and SNMPv2c, not to SNMPv3, which replaces communities with users and security levels.

Exam trap

The trap here is that candidates often confuse SNMPv3 with SNMPv2c and incorrectly select the community string option, forgetting that SNMPv3 eliminates community strings in favor of user-based authentication and encryption.

Full explanation →

746

MCQhard

A FortiGate administrator configures policy-based routing (PBR) to direct traffic from subnet 192.168.1.0/24 to the internet via ISP1. However, traffic from that subnet is still using the default route via ISP2. What is the most likely cause?

A.The PBR rule's source address does not match the traffic correctly.

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

C.PBR is not supported on FortiGate.

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

AnswerA

PBR evaluates its rule set before the routing table, so traffic only diverts when a rule's match criteria are satisfied. If the source address in the rule does not correctly identify 192.168.1.0/24, the rule is skipped and the packet falls through to the default route via ISP2.

Why this answer

Policy-based routing (PBR) on FortiGate overrides the routing table only when the traffic matches all configured criteria, including the source address. If the source address in the PBR rule does not match 192.168.1.0/24 exactly (e.g., a typo, wrong subnet mask, or missing entry), the traffic falls through to the default route via ISP2. This is the most likely cause because PBR rules are evaluated before the routing table, but only for matching traffic.

Exam trap

The trap here is that candidates often confuse PBR with static routing and assume the default route's administrative distance or priority can override PBR, but PBR is evaluated before the routing table and is not subject to route metrics.

How to eliminate wrong answers

Option B is wrong because administrative distance is a property of routes in the routing table, not of PBR rules; PBR operates before the routing table lookup and is not compared to administrative distance. Option C is wrong because PBR is fully supported on FortiGate, including in NSE4 scope, and is commonly used for multi-WAN setups. Option D is wrong because a higher priority in PBR would make the rule more likely to match, not less; the issue is that the rule is not matching at all, not that it is being overridden by the default route.

Full explanation →

747

Multi-Selectmedium

An organization wants to implement least privilege for firewall policies. Which THREE best practices should be followed? (Choose three.)

Select 3 answers

A.Use a single schedule covering all days

B.Specify the exact services required (e.g., TCP/443, TCP/22)

C.Apply security profiles (e.g., antivirus, IPS) to inspect allowed traffic

D.Use any any for source and destination to simplify management

E.Use specific source and destination addresses

AnswersB, C, E

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.

Full explanation →

748

MCQeasy

What is the purpose of the 'implicit deny' policy on a FortiGate?

A.It allows traffic from trusted internal networks

B.It denies all traffic that does not match any explicit policy

C.It logs all traffic that is denied

D.It allows all traffic that matches no other policy

AnswerB

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.

Full explanation →

749

MCQhard

An administrator runs 'diagnose debug flow' for a specific source IP and sees the output includes 'no matching policy'. The FortiGate has a firewall policy that should match the traffic. What is the most likely reason for this message?

A.The FortiGate's routing table does not have a route for the destination

B.The firewall policy is disabled or the source/destination interfaces do not match the traffic's ingress/egress interfaces

C.The security profiles applied to the policy are blocking the traffic

D.The session table is full and cannot accept new sessions

AnswerB

The debug flow output showing 'no matching policy' means the packet successfully completed route lookup and is now being matched against firewall policies. This error occurs when no enabled policy satisfies the traffic's characteristics, such as the ingress interface, egress interface, source/destination addresses, or destination port. A disabled policy is ignored entirely, and if the source or destination interfaces in a policy do not match the actual interfaces the traffic traverses, that policy will be skipped, leaving the traffic without a match.

Why this answer

'No matching policy' in diagnose debug flow means the FortiGate evaluated the packet against the policy list and found no policy whose ingress interface, egress interface, source, destination, schedule, and service all matched. The most common causes are a disabled policy or an interface mismatch (traffic arriving on an interface the policy does not list as incoming).

Exam trap

NSE4 often tests the distinction between routing failures, policy lookup failures, and session-table exhaustion — candidates see 'no matching policy' and wrongly blame routing or security profiles.

How to eliminate wrong answers

Option A is wrong because a missing route produces a different debug message (e.g., 'no route found' or 'reverse path check fail'), not 'no matching policy'. Option C is wrong because security profiles are evaluated only after a policy matches; if no policy matches, profiles are never reached. Option D is wrong because a full session table yields messages like 'session setup failed' or 'no free session', not a policy lookup failure.

Full explanation →

750

MCQmedium

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?

A.A deny policy with a lower policy ID is matching the traffic before the allow policy

B.The firewall policy has an incorrect source interface

C.The policy is disabled

D.The web server is not responding to HTTP requests

AnswerA

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.

Full explanation →

Fortinet NSE 4 Network Security Professional NSE4 (NSE4) — Questions 676–750