Fortinet NSE 4 Network Security Professional NSE4 NSE4 Questions 151–225 | Page 3/4

151

MCQeasy

Which FortiGate operating mode allows the device to act as a transparent layer 2 bridge, forwarding traffic without performing NAT or routing?

A.Transparent mode

B.HA mode

C.VDOM mode

D.NAT/Route mode

AnswerA

Transparent mode acts as a layer 2 bridge.

Why this answer

Transparent mode is the correct answer because in this mode, FortiGate operates as a Layer 2 bridge, forwarding traffic based on MAC addresses without performing Network Address Translation (NAT) or routing. The device does not have an IP address on its interfaces for forwarding decisions, making it invisible to the network at Layer 3.

Exam trap

The trap here is that candidates often confuse 'transparent mode' with 'VDOM mode' because VDOMs can be configured in transparent mode, but VDOM mode itself is a virtualization feature, not the operating mode that defines Layer 2 bridging behavior.

How to eliminate wrong answers

Option B (HA mode) is wrong because High Availability mode is a clustering configuration for redundancy and failover, not an operating mode that changes the device's Layer 2 or Layer 3 forwarding behavior. Option C (VDOM mode) is wrong because Virtual Domain mode is a virtualization feature that allows partitioning a single FortiGate into multiple logical firewalls, each operating in its own mode (transparent or NAT/route), but it does not inherently make the device a transparent bridge. Option D (NAT/Route mode) is wrong because this is the default Layer 3 operating mode where the FortiGate performs routing and NAT, acting as a router with IP addresses on interfaces, which is the opposite of transparent bridging.

Full explanation →

152

MCQmedium

A network administrator configures an IPsec VPN between two FortiGates using IKEv1 main mode. The Phase 1 negotiation fails with the error 'no proposal chosen'. The administrator checks both sides and confirms the IKE version, encryption algorithm (AES256), authentication (SHA256), and Diffie-Hellman group (14) match. Which additional parameter is MOST likely mismatched?

A.Pre-shared key

B.IKE version (IKEv2)

C.Phase 2 encryption algorithm

D.Local and remote identifiers (local ID / remote ID)

AnswerD

In main mode, identifiers are exchanged. A mismatch of local or remote ID can cause 'no proposal chosen'.

Why this answer

In IKEv1 main mode, the Phase 1 negotiation includes an exchange of identity (ID) payloads after the Diffie-Hellman exchange. If the local or remote identifiers (local ID / remote ID) do not match what is expected on the peer, the FortiGate will reject the proposal with a 'no proposal chosen' error, even if all other Phase 1 parameters (encryption, authentication, DH group, IKE version) are identical. The pre-shared key is verified later in Phase 1 (during authentication), so a mismatch there would cause a different error (e.g., 'authentication failed'), not 'no proposal chosen'.

Exam trap

The trap here is that candidates assume 'no proposal chosen' always means a cryptographic parameter mismatch (encryption, hash, DH group), but FortiGate (and other vendors) can also return this error when the identity payload does not match the expected peer ID, especially in IKEv1 main mode where identity is exchanged after the proposal is accepted.

How to eliminate wrong answers

Option A is wrong because the pre-shared key is not checked during the proposal exchange; it is used in the authentication phase (Main Mode messages 5 and 6) and a mismatch would result in an 'authentication failed' error, not 'no proposal chosen'. Option B is wrong because the administrator confirmed both sides use IKEv1, and if one side were using IKEv2, the error would typically be 'no acceptable proposal' or a version mismatch, but the question explicitly states IKEv1 is used on both sides. Option C is wrong because Phase 2 parameters (encryption algorithm, etc.) are negotiated after Phase 1 completes; a Phase 2 mismatch would cause a Phase 2 failure (e.g., 'no proposal chosen' during Phase 2), not a Phase 1 failure.

Full explanation →

153

MCQmedium

You notice that the FortiGate HA cluster is not failing over when the primary unit loses power. The HA configuration shows 'set ha-priority 250' on the primary and 'set ha-priority 200' on the secondary. What is the most likely cause?

A.The secondary unit has a lower priority, so it never takes over

B.The password for HA synchronization is incorrect

C.The session pickup feature is disabled

D.The HA heartbeat interface is not configured correctly or is down

AnswerD

The HA heartbeat interface is the dedicated link used by both units to exchange state and health information. If this interface is not configured correctly or is down, the secondary cannot reliably monitor the primary's heartbeat; in this scenario, the cluster may not even form, or if it did form, the secondary will not detect the primary's failure and will not initiate a failover. In some cases, a failed heartbeat with a still-functioning management plane can lead to split-brain, but a correctly working heartbeat is fundamental to failover detection and to avoid the cluster being stuck with an inactive primary.

Why this answer

The most likely cause is that the HA heartbeat interface is not configured correctly or is down (Option D). FortiGate HA relies on heartbeat packets exchanged over dedicated or VLAN interfaces to monitor peer status. If the heartbeat interface fails, the secondary unit cannot detect the primary's loss of power, so no failover occurs regardless of priority settings.

The HA priority values (250 vs. 200) are valid and would normally cause the primary to be elected as the active unit, but a broken heartbeat link prevents failover detection.

Exam trap

The trap here is that candidates often assume priority values alone determine failover behavior, but FortiGate HA failover requires a working heartbeat link to detect peer failure; without it, even a complete power loss goes unnoticed.

How to eliminate wrong answers

Option A is wrong because the secondary unit's lower priority (200) does not prevent it from taking over; in fact, when the primary fails, the secondary with the next highest priority becomes active. Option B is wrong because an incorrect HA synchronization password would cause configuration sync failures, not a failure to detect a power loss and trigger failover. Option C is wrong because session pickup (or session failover) is a feature for preserving active sessions during failover, not a requirement for the failover itself to occur.

Full explanation →

154

MCQmedium

An administrator configures a route-based IPsec VPN between two FortiGates. The Phase 1 and Phase 2 are up. The administrator adds a static route on each FortiGate pointing to the remote subnet via the virtual tunnel interface (e.g., 'to_remote'). Traffic between the subnets fails. What is the MOST likely missing configuration?

A.NAT must be disabled on the tunnel interface

B.The tunnel interface must be added to a zone

C.The Phase 2 proposal must include the correct local and remote subnets

D.A firewall policy is required to permit traffic between the interfaces

AnswerD

Route-based VPNs require explicit firewall policies to allow traffic through the tunnel.

Why this answer

In a route-based IPsec VPN, even when Phase 1 and Phase 2 are up and a static route exists via the virtual tunnel interface, traffic will still be dropped unless a firewall policy explicitly permits it. FortiGate uses a stateful firewall, so a policy must allow traffic from the local interface to the tunnel interface (or vice versa) to forward packets. Without this policy, the FortiGate will not forward traffic between the subnets, even though the tunnel is established.

Exam trap

The trap here is that candidates assume a static route and an established IPsec tunnel are sufficient for traffic flow, overlooking the mandatory firewall policy that FortiGate requires to permit inter-subnet traffic in a route-based VPN.

How to eliminate wrong answers

Option A is wrong because NAT is not required to be disabled on the tunnel interface for route-based VPNs; NAT is typically disabled automatically for IPsec traffic, and disabling it manually is not the missing configuration. Option B is wrong because adding the tunnel interface to a zone is optional and used for grouping interfaces for policy application, but it is not a prerequisite for traffic flow; a firewall policy can be applied directly to the interface without a zone. Option C is wrong because the Phase 2 proposal includes the correct local and remote subnets (0.0.0.0/0 for route-based VPNs), and the question states Phase 2 is up, indicating the proposal is correctly configured; the issue is not with Phase 2 parameters.

Full explanation →

155

MCQmedium

A FortiGate administrator has configured a firewall policy allowing HTTP traffic from the internal network (10.0.1.0/24) to the DMZ server (192.168.1.10). The policy is placed after a deny-all policy that blocks traffic from internal to DMZ. Even though the allow policy is more specific, traffic is still being denied. What is the most likely cause?

A.The deny-all policy has a higher policy ID than the allow policy

B.The allow policy is configured with the wrong source interface

C.The allow policy uses a schedule that is not active at the current time

D.The deny-all policy is placed above the allow policy in the policy list

AnswerD

FortiOS performs first-match evaluation, checking rules top-down and enforcing the first rule whose all conditions (source, destination, service, schedule, etc.) are satisfied. If a broad deny-all is positioned above the specific allow policy, every packet that would otherwise match the allow rule hits the deny-all first and is dropped. That is the classic misordering mistake, and it cannot be compensated for by policy IDs or other attributes.

Why this answer

FortiGate firewall policies are evaluated sequentially from top to bottom. The first matching policy is applied, and subsequent policies are ignored. Since the deny-all policy is placed above the more specific allow policy, traffic from 10.0.1.0/24 to 192.168.1.10 matches the deny-all first and is dropped, never reaching the allow rule.

Exam trap

The trap here is that candidates mistakenly believe FortiGate uses a 'best-match' or 'most-specific' logic like routing tables, when in fact it uses strict first-match sequential evaluation, making policy order critical.

How to eliminate wrong answers

Option A is wrong because policy ID order does not determine evaluation priority; FortiGate uses the physical sequence in the policy list, not the ID number. Option B is wrong because if the source interface were incorrect, the traffic would not match the allow policy at all, but the question states the traffic is denied by the deny-all policy, implying the allow policy is otherwise correctly configured. Option C is wrong because a schedule issue would cause the allow policy to be inactive, but the traffic would still be evaluated against the deny-all policy and denied; however, the most likely cause given the policy placement is the order, not a schedule.

Full explanation →

156

MCQmedium

An administrator wants to block an application named 'Skype' on the network. They create an application control profile and add a rule to block 'Skype'. However, after applying the profile to the policy, users can still use Skype. What is the most likely reason?

A.The application control profile is not enabled on the firewall policy

B.The application signature for Skype is outdated

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

D.Skype traffic is encrypted and SSL deep inspection is not enabled

AnswerD

Skype uses transport-layer encryption (TLS) to protect its signaling and media traffic. Without SSL deep inspection enabled in the firewall policy, the FortiGate cannot decrypt the SSL/TLS session to read the application-layer payload where the application signature resides. Consequently, the FortiGate sees only encrypted packets that do not match Skype's signature, so the block rule never triggers. To block Skype effectively, the administrator must enable SSL deep inspection with a valid CA certificate, allowing the FortiGate to proxy and inspect the traffic.

Why this answer

Skype uses proprietary encryption and often relies on peer-to-peer connections that bypass traditional port-based inspection. Without SSL deep inspection (also known as HTTPS inspection or certificate-based decryption), the FortiGate cannot decrypt the encrypted Skype traffic to match it against the application control signature. Application control relies on either protocol decoders or deep packet inspection (DPI) to identify applications; if the traffic is encrypted and not decrypted, the FortiGate sees only encrypted payloads and cannot apply the block rule.

Exam trap

The trap here is that candidates often assume application control can block any application by name alone, forgetting that encrypted traffic requires SSL deep inspection to be enabled on the firewall policy for the application signatures to work.

How to eliminate wrong answers

Option A is wrong because if the application control profile were not enabled on the firewall policy, the policy would not apply any application control at all, but the question states the profile was applied, so this is not the most likely reason. Option B is wrong because an outdated signature would cause a failure to detect new variants of Skype, but Skype itself is a well-known, long-standing application with stable signatures; an outdated signature is less likely than the fundamental encryption issue. Option C is wrong because if the rule were set to 'monitor' instead of 'block', the administrator would see log entries indicating the traffic was allowed, not that users could still use Skype without any indication; the question implies the block simply does not work, not that it is silently logging.

Full explanation →

157

Multi-Selectmedium

A FortiGate administrator wants to block spam emails sent to the company's mail server. The mail server is behind the FortiGate. Which THREE configurations should be applied?

Select 3 answers

A.Enable DLP to filter spam

B.Configure Application Control to block email applications

C.Enable FortiGuard spam filtering in the Email Filter profile

D.Apply the Email Filter profile to the firewall policy that allows SMTP traffic to the mail server

E.Create an Email Filter profile with spam detection enabled

AnswersC, D, E

FortiGuard provides up-to-date spam signatures.

Why this answer

FortiGate's Email Filter profile integrates with FortiGuard's antispam service to block spam at the gateway. This profile uses real-time signature-based and heuristic analysis to identify and reject spam before it reaches the internal mail server.

Exam trap

The trap here is that candidates confuse DLP or Application Control with email-specific spam filtering, failing to recognize that only the Email Filter profile with FortiGuard antispam can inspect SMTP message bodies and headers for spam content.

Full explanation →

158

Multi-Selectmedium

A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. The tunnel is established, but traffic is not passing. The administrator runs 'diagnose vpn tunnel list' and sees the tunnel is up. Which two additional diagnostics should the administrator run to isolate the issue?

Select 2 answers

A.diagnose sys session filter and diagnose sys session list

B.diagnose hardware sysinfo memory

C.diagnose debug application ike -1

D.diagnose netlink interface list

E.execute ping-options source and execute ping

AnswersA, C

This allows checking if sessions are being created and whether they match the expected policy.

Why this answer

'diagnose sys session filter' allows you to set filters (e.g., by source/destination IP or port) and 'diagnose sys session list' then displays the current session table entries matching those filters. Since the IPsec tunnel is up but traffic is not passing, the session table may show that traffic is being dropped or not matching the expected policies, helping isolate whether the issue is with policy routing, firewall rules, or session setup. Option C is also correct because 'diagnose debug application ike -1' enables detailed IKE debugging that can reveal post-establishment issues, such as rekey failures, phase 2 problems, or IPsec SA mismatches, which may not be apparent from the tunnel list alone.

Both diagnostics are appropriate: A checks the data plane (session table), and C checks the control plane (IKE negotiation details).

Exam trap

A common pitfall is to assume that 'diagnose debug application ike -1' is only useful during initial tunnel negotiation and not after the tunnel is up. In reality, this debug can be invaluable for troubleshooting issues like phase 2 rekey failures, SA mismatches, or traffic selector problems that occur after the tunnel is established. Another trap is to overlook the session table diagnostics (Option A), which directly show whether expected traffic is hitting the firewall policies and whether sessions are being created or dropped.

Both tools are needed for a complete analysis.

Full explanation →

159

MCQeasy

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

A.Quick mode

B.IKEv2

C.Aggressive mode

D.Main mode

AnswerC

Correct. Aggressive mode is used for peers with dynamic IPs because it can authenticate without prior IP knowledge.

Why this answer

Aggressive mode is used in IPsec IKE phase 1 when the VPN peer has a dynamic public IP address because it allows the initiator to send its identity and authentication data in the first packet, enabling the responder to identify the peer without requiring a reverse DNS lookup or static IP. This mode reduces the number of exchanges from six (Main mode) to three, which is essential when the peer's IP address is not known in advance, as in many remote-access or dynamic-IP site-to-site scenarios.

Exam trap

The trap here is that candidates confuse 'Aggressive mode' with 'IKEv2' or 'Quick mode,' thinking that IKEv2 inherently solves dynamic IP issues, but the exam specifically tests the phase 1 mode (Aggressive vs. Main) for dynamic IP scenarios, not the protocol version.

How to eliminate wrong answers

Option A is wrong because Quick mode is an IKE phase 2 exchange that negotiates IPsec security associations (SAs) for data traffic, not a phase 1 mode used to handle dynamic IP addresses. Option B is wrong because IKEv2 is a protocol version, not a mode; while IKEv2 can handle dynamic IPs through its built-in mechanisms (e.g., using cookies and initiator/responder cookies), the question specifically asks for a 'mode' used in IPsec VPN, and Aggressive mode is the correct phase 1 mode for dynamic IP peers. Option D is wrong because Main mode requires the IP address of the peer to be known beforehand, as it uses six exchanges and relies on the IP address for identity verification; it cannot be used when the peer has a dynamic public IP.

Full explanation →

160

MCQhard

A FortiGate administrator configures SSL deep inspection on a policy using a self-signed CA certificate. Users report that they see a certificate warning in their browsers when accessing HTTPS sites. What is the most effective solution to eliminate these warnings?

A.Use a publicly trusted CA certificate for the FortiGate

B.Disable deep inspection and use certificate inspection only

C.Add the websites to the exemption list in the SSL/SSH profile

D.Install the FortiGate's CA certificate on all client machines in the trusted root store

AnswerD

Installing the FortiGate's CA certificate into the trusted root store of every client establishes the FortiGate as a trusted certificate authority within the organization. When the FortiGate generates a per-session certificate signed by this CA, the client's browser accepts it without warnings because the CA is in its trust store. This directly addresses the root cause of the warning and is the recommended enterprise deployment practice for deep inspection.

Why this answer

The certificate warning occurs because the browser does not trust the FortiGate's self-signed CA certificate. By installing the FortiGate's CA certificate into the trusted root store on each client machine, the browser will trust certificates signed by that CA, eliminating the warning. This is the standard approach for self-signed CA certificates in SSL deep inspection environments.

Exam trap

The trap here is that candidates may think using a publicly trusted CA (Option A) is the solution, not realizing that the FortiGate must hold the private key for that CA, which is impractical and insecure; the correct approach is to trust the FortiGate's own CA internally.

How to eliminate wrong answers

Option A is wrong because using a publicly trusted CA certificate for the FortiGate would require the FortiGate to have the private key for that CA, which is a security risk and not standard practice; the FortiGate's self-signed CA is meant to be distributed internally. Option B is wrong because disabling deep inspection and using certificate inspection only would bypass the need for a trusted CA but would also eliminate the security benefits of inspecting encrypted traffic content. Option C is wrong because adding websites to the exemption list only prevents inspection for those specific sites, not all HTTPS sites, so users would still see warnings for non-exempted sites.

Full explanation →

161

MCQhard

A company is implementing SSL/TLS inspection on a FortiGate to monitor encrypted traffic. They want to ensure that traffic to high-risk categories is blocked, while traffic to financial sites is inspected but not blocked. The administrator creates an SSL inspection profile that deep-inspects all traffic except traffic to financial sites. However, users report that they cannot access financial websites. What is the most likely cause?

A.The web filter profile is configured to block financial websites, overriding the SSL inspection exemption.

B.The SSL inspection profile should be set to certificate-inspection instead of deep-inspection for financial sites.

C.The SSL inspection profile must be applied after the web filter profile in the firewall policy.

D.The SSL inspection profile should have deep-inspection disabled for all categories except financial.

AnswerA

The SSL inspection exemption only controls whether the FortiGate decrypts the TLS stream; it does not disable URL/web filtering. FortiGuard can still classify the destination based on the SNI, IP address, or FQDN from the ClientHello, so if the web filter profile blocks the 'Financial Services' category, the session is denied regardless of the decryption bypass. The exemption is the wrong place to expect 'allow' semantics when the web filter policy explicitly says block.

Why this answer

The most likely cause is that the web filter profile applied in the same firewall policy is configured to block financial websites. Even though the SSL inspection profile exempts financial sites from deep inspection, the web filter profile operates independently and can block traffic based on URL category. Since the web filter is evaluated after SSL inspection, it will block the decrypted or even non-decrypted traffic to financial sites if the category is set to block, overriding the SSL inspection exemption.

Exam trap

The trap here is that candidates assume the SSL inspection exemption automatically prevents web filtering from blocking the traffic, but FortiGate applies web filter policies independently, so a block action in the web filter profile overrides any SSL inspection exemption.

How to eliminate wrong answers

Option B is wrong because certificate-inspection only validates the certificate without decrypting the payload, which would not allow the web filter to inspect the content; the issue is not about the inspection type but about the web filter blocking the category. Option C is wrong because the order of profiles within a firewall policy does not affect the evaluation; both SSL inspection and web filter profiles are applied in sequence, but the web filter can still block traffic regardless of the SSL inspection profile's exemption. Option D is wrong because disabling deep-inspection for all categories except financial would still allow the web filter to block financial sites if the web filter profile is configured to block them; the exemption in the SSL inspection profile does not prevent the web filter from blocking.

Full explanation →

162

Multi-Selecthard

An admin is configuring a policy-based NAT (central SNAT) to translate internal users to a pool of public IPs using overload. The admin wants to ensure that specific applications using non-standard ports are not affected by NAT. Which THREE steps should the admin consider?

Select 3 answers

A.Disable NAT for those applications by adding a policy before the NAT policy with 'set nat disable'

B.Configure a separate IP pool dedicated to those applications

C.Use a fixed port range in the IP pool configuration

D.Use central SNAT with a VIP for source NAT

E.Enable 'set nat enable' on the policy

AnswersA, B, C

Adding a policy before the central SNAT policy with 'set nat disable' creates a deterministic exception: traffic matching that earlier policy is evaluated and its NAT disabled, so it is never processed by the subsequent central SNAT rule. Due to FortiOS policy ordering, the first match wins, meaning this exempt policy must be placed ahead of the NAT policy. This selectively preserves the original source address/port for those applications while other traffic continues through central SNAT.

Why this answer

Adding a policy before the central SNAT policy with `set nat disable` explicitly exempts specific traffic from NAT translation, ensuring that applications using non-standard ports are not affected by the overload behavior. Option B is correct because configuring a separate IP pool dedicated to those applications allows you to control the NAT behavior independently, such as using a pool without PAT or with a fixed port range, thereby avoiding port remapping issues. Option C is correct because using a fixed port range in the IP pool confines source port allocation to a specified range, accommodating applications that expect particular ports.

Option D is incorrect because a VIP is for destination NAT, not source NAT, and does not address source port modification. Option E is incorrect because enabling NAT on the policy would translate all traffic, not protect specific applications.

Exam trap

The trap is that candidates may believe only disabling NAT (Option A) can protect applications, overlooking that a dedicated IP pool with a fixed port range (Options B and C) can also preserve application behavior by controlling source port allocation. Additionally, some might incorrectly assume that a VIP (Option D) or simply enabling NAT (Option E) would address the issue.

Full explanation →

163

MCQeasy

A network administrator is configuring a FortiGate for the first time and needs to enable administrative access via HTTPS from the internal network. Which configuration step is required?

A.Set the administrative access to HTTPS on the internal interface

B.Enable HTTPS on the system global settings

C.Create a firewall policy allowing inbound HTTPS from internal to the FortiGate

D.Configure a static route for the management subnet

AnswerA

To manage a FortiGate via HTTPS on a specific interface, you must explicitly enable HTTPS in the interface's administrative access settings. This is done with `config system interface` and `set allowaccess https` (or `set allowaccess ping https ...`), which tells the control plane to accept HTTPS sessions destined to that interface's IP address. Without this setting, even if the interface has a valid IP and the firewall permits HTTP(S) traffic, the FortiGate will drop management connection attempts.

Why this answer

Administrative access to a FortiGate interface is controlled per-interface under the interface configuration. By default, HTTPS access is disabled on all interfaces. To enable administrative HTTPS access from the internal network, you must set the administrative access to HTTPS on the specific internal interface.

This allows the FortiGate to listen for HTTPS management traffic on that interface's IP address.

Exam trap

The trap here is that candidates confuse firewall policies (which control traffic passing through the FortiGate) with local-in policies (which control traffic destined to the FortiGate), leading them to incorrectly select Option C.

How to eliminate wrong answers

Option B is wrong because HTTPS is not enabled globally; it is enabled per-interface under config system interface. The global settings only control the HTTPS port (default 443) and certificate, not the interface-level access. Option C is wrong because firewall policies control traffic passing through the FortiGate, not traffic destined to the FortiGate itself.

Administrative access is governed by the local-in policy, which is implicitly controlled by the interface's administrative access settings. Option D is wrong because a static route is only needed if the management subnet is not directly connected; for the internal network, the FortiGate already has a directly connected route, so no static route is required.

Full explanation →

164

MCQhard

A FortiGate administrator is upgrading firmware from version 6.0 to 7.0. The upgrade path requires multiple steps. Which of the following is the recommended method to ensure a successful upgrade?

A.Upgrade to 6.2, then to 6.4, then to 7.0, following the official upgrade path

B.Perform a factory reset after upgrading to 7.0

C.Use the 'execute upgrade-version' command to automatically determine the path

D.Upload and install the 7.0 firmware directly, then restore configuration from backup

AnswerA

Stepwise upgrades ensure compatibility and prevent issues.

Why this answer

FortiGate firmware upgrades must follow a specific path to ensure compatibility of the firmware image, configuration database, and bootloader. Skipping intermediate versions (e.g., 6.2 and 6.4) can cause configuration corruption or boot failure because each major version may change the internal data structures or require a specific bootloader version. The official upgrade path from 6.0 to 7.0 is 6.0 → 6.2 → 6.4 → 7.0, as documented in Fortinet's release notes.

Exam trap

The trap here is that candidates may think a direct upgrade is acceptable because they assume firmware is backward-compatible, or they confuse the 'execute update-now' command with an automatic path resolver, when in fact Fortinet requires strict adherence to the documented upgrade path to prevent bootloader and configuration schema mismatches.

How to eliminate wrong answers

Option B is wrong because performing a factory reset after upgrading to 7.0 does not address the need for a correct upgrade path; it only resets the configuration, but the firmware itself must still be upgraded in the correct sequence to avoid bootloader or database incompatibilities. Option C is wrong because the 'execute upgrade-version' command does not exist; FortiGate uses 'execute update-now' for firmware updates, but there is no automatic path determination command—the administrator must manually follow the documented upgrade path. Option D is wrong because directly uploading and installing 7.0 firmware from 6.0 is not supported; it can result in a failed upgrade or a non-booting unit due to incompatible firmware structures, and restoring a configuration from backup after a direct upgrade may also fail if the configuration format has changed.

Full explanation →

165

MCQmedium

A network administrator has configured an IPsec VPN between two FortiGate devices. The Phase 1 proposal includes AES256-SHA256-DH14. The Phase 2 proposal includes AES128-SHA1. The VPN tunnel fails to establish. Which of the following is the MOST likely cause?

A.The Phase 1 proposal is too strong and the remote FortiGate does not support DH14

B.The Phase 2 proposal does not match between the two devices

C.The VPN policy has not been configured on the remote FortiGate

D.The pre-shared key is incorrect

AnswerB

Phase 2 parameters must be identical on both sides. One side may have AES256 or a different lifetime, causing mismatch.

Why this answer

The Phase 2 proposal must match exactly between both VPN endpoints for IPsec to establish. Here, the local device uses AES128-SHA1, but the remote device likely expects a different combination (e.g., AES256-SHA256 or another algorithm), causing the IKE negotiation to fail after Phase 1 completes. Even though Phase 1 succeeded with AES256-SHA256-DH14, the mismatch in Phase 2 prevents the IPsec SA from being created.

Exam trap

The trap here is that candidates assume Phase 1 and Phase 2 proposals must be identical in strength or that a strong Phase 1 automatically implies a strong Phase 2, but NSE4 tests that Phase 2 proposals are independently negotiated and must match exactly between peers.

How to eliminate wrong answers

Option A is wrong because DH14 is a widely supported Diffie-Hellman group, and if the remote FortiGate did not support it, Phase 1 would fail immediately—not Phase 2. Option C is wrong because a missing VPN policy would cause traffic to be dropped, but the IKE negotiation itself would still proceed and fail at a later stage, not specifically at Phase 2 proposal mismatch. Option D is wrong because an incorrect pre-shared key would cause Phase 1 authentication to fail, preventing any further negotiation, not a Phase 2 mismatch.

Full explanation →

166

MCQmedium

A network admin runs 'diag sys session filter proto 6' and 'diag sys session list' and sees many sessions with state 'SYN_SENT' to a public web server. The firewall policy allows TCP/443. What is the MOST likely cause?

A.The web server is overloaded and dropping connections

B.The policy is in proxy mode but should be flow mode

C.The destination NAT (VIP) for the web server is not configured

D.The firewall policy has session TTL set too low

AnswerC

The destination NAT (VIP) is the critical missing element in this scenario. When a client sends a TCP SYN to the web server's public IP, the FortiGate must use a matching VIP to translate that destination to the server's private IP address; without it, the firewall has no next hop or internal server to forward the packet to. As a result, the SYN is dropped or consumed by the firewall itself, the server never receives the request, and the client's session stays in SYN_SENT.

Why this answer

The 'diag sys session filter proto 6' command filters for TCP sessions (protocol 6). Seeing many sessions stuck in 'SYN_SENT' state indicates that the FortiGate is sending SYN packets to the destination but never receiving a SYN-ACK reply. Since the firewall policy allows TCP/443, the most likely cause is that the destination NAT (VIP) for the public web server is not configured.

Without a VIP, the FortiGate forwards the packet with the original destination IP (the public IP), which may not be routable or may not exist on the internal network, causing the SYN to be sent into a black hole.

Exam trap

The trap here is that candidates assume 'SYN_SENT' always indicates a server-side issue (like overload or firewall blocking), but in FortiGate diagnostics, it specifically points to a missing or misconfigured destination NAT when the destination is a public IP that must be translated to an internal server.

How to eliminate wrong answers

Option A is wrong because an overloaded web server would typically respond with a SYN-ACK or RST, not cause the FortiGate to see endless 'SYN_SENT' states; the server would still complete the TCP handshake or reject the connection. Option B is wrong because proxy mode vs. flow mode affects how the firewall processes traffic (e.g., deep inspection), but it does not cause sessions to remain in 'SYN_SENT' state; that state indicates a failure in the TCP handshake at the network layer. Option D is wrong because a low session TTL would cause sessions to expire prematurely, not prevent the initial SYN-ACK from being received; 'SYN_SENT' means the handshake never completed, not that it was terminated early.

Full explanation →

167

MCQmedium

A FortiGate admin is configuring a dial-up IPsec VPN for remote users. The users have dynamic IP addresses. Which Phase 1 configuration is appropriate?

A.Set the remote gateway to 'Dialup User' and enable an IP pool

B.Disable XAuth authentication

C.Set the remote gateway to the user's IP address

D.Use aggressive mode with a group pre-shared key

AnswerA

This allows any remote user to connect and get an IP from the pool.

Why this answer

For dial-up IPsec VPNs where remote users have dynamic IP addresses, the FortiGate cannot know the remote gateway IP in advance. Setting the remote gateway to 'Dialup User' allows the FortiGate to accept connections from any IP, and enabling an IP pool assigns a static internal IP to the remote user for routing and policy enforcement.

Exam trap

The trap here is that candidates often confuse 'Dialup User' with a static remote gateway setting, or they mistakenly think aggressive mode is required for dynamic IPs, when in fact FortiGate dial-up VPNs use main mode by default and the 'Dialup User' option handles dynamic peers transparently.

How to eliminate wrong answers

Option B is wrong because disabling XAuth authentication would remove user-level authentication, which is typically required for dial-up VPNs to identify and authorize remote users. Option C is wrong because setting the remote gateway to the user's IP address is impossible when the user has a dynamic IP that changes each connection. Option D is wrong because aggressive mode with a group pre-shared key is less secure (sends identity in cleartext) and is not the appropriate Phase 1 configuration for dial-up users; FortiGate dial-up VPNs typically use main mode with certificates or EAP.

Full explanation →

168

MCQeasy

Which statement best describes the 'implicit deny' policy on a FortiGate?

A.It can be moved to a different position in the policy list

B.It is automatically applied to all traffic that does not match any explicit policy

C.It is a configurable policy that denies all traffic

D.It logs all denied traffic by default

AnswerB

Any traffic not matched by a higher-priority allow policy is denied by the implicit deny.

Why this answer

The 'implicit deny' policy on a FortiGate is a built-in, last-resort rule that automatically denies any traffic not matching an explicit firewall policy. It is not visible in the policy list and cannot be moved, modified, or deleted; it is always applied as the final rule to ensure that only explicitly permitted traffic is allowed through the FortiGate.

Exam trap

The trap here is that candidates often confuse the implicit deny with a configurable policy, thinking it can be moved, logged, or modified, when in fact it is a fixed, non-configurable default rule that is always present and never logs traffic by default.

How to eliminate wrong answers

Option A is wrong because the implicit deny policy is not a movable entry in the policy list; it is a fixed, invisible rule that always resides at the bottom of the policy evaluation order. Option C is wrong because the implicit deny is not configurable — it is a hardcoded default behavior that cannot be edited or removed. Option D is wrong because the implicit deny does not log denied traffic by default; logging must be explicitly enabled on an explicit deny policy or via global logging settings.

Full explanation →

169

MCQmedium

A FortiGate is configured with FSSO for firewall authentication. Users report they are prompted for credentials every time they access the internet, even though they are logged into the domain. What is the most likely cause?

A.The users are not members of the FSSO group.

B.The firewall policy uses 'All Users' instead of a specific group.

C.The FSSO collector agent service is not running.

D.The FortiGate's LDAP server is unreachable.

AnswerC

The FSSO collector agent is the critical component that gathers logon events from Active Directory (either through NetAPI polling or by reading Windows security event logs) and forwards them to the FortiGate. If the collector agent service is stopped or not running, the FortiGate has no source of domain user logon information, so it treats all traffic as unauthenticated and triggers local firewall authentication prompts. This is the most direct cause of the symptom described, because the entire FSSO identity pipeline is broken.

Why this answer

If the FSSO collector agent service is not running, the FortiGate cannot receive the logon events from the domain controllers. Without these events, the FortiGate has no way to know which users are authenticated, so it falls back to prompting for credentials on every new session, even though users are already logged into the domain.

Exam trap

The trap here is that candidates often confuse FSSO with LDAP authentication, assuming an LDAP connectivity issue is the cause, when in fact FSSO relies on a separate collector agent and domain controller event polling, not direct LDAP queries.

How to eliminate wrong answers

Option A is wrong because users not being members of the FSSO group would cause them to be denied access or not matched to the policy, not repeatedly prompted for credentials. Option B is wrong because using 'All Users' in the firewall policy would actually bypass FSSO authentication entirely, allowing traffic without any credential prompt. Option D is wrong because the FortiGate's LDAP server being unreachable affects LDAP-based authentication or directory lookups, not the FSSO polling mechanism which relies on the collector agent and domain controller events, not direct LDAP queries.

Full explanation →

170

MCQeasy

An administrator wants to use Active Directory credentials to authenticate firewall administrators. Which authentication server type should be configured on the FortiGate?

A.TACACS+

B.FSSO

C.LDAP

D.RADIUS

AnswerC

LDAP is the protocol used to query Active Directory for authentication and user attributes.

Why this answer

LDAP (Lightweight Directory Access Protocol) is the correct choice because it directly integrates with Microsoft Active Directory to authenticate firewall administrators using their existing AD credentials. FortiGate can bind to an LDAP server to verify username and password pairs, making it the native protocol for AD authentication without requiring additional services or translation layers.

Exam trap

The trap here is that candidates often confuse FSSO (used for transparent network authentication) with direct admin authentication, or assume RADIUS is the only way to integrate with AD, but FortiGate's native LDAP support is the simplest and most direct method for admin authentication against Active Directory.

How to eliminate wrong answers

Option A is wrong because TACACS+ is a Cisco-proprietary protocol that separates authentication, authorization, and accounting (AAA) and is not natively used by Active Directory; it requires a separate TACACS+ server to bridge to AD. Option B is wrong because FSSO (Fortinet Single Sign-On) is designed for transparent user identification on the network, not for authenticating firewall administrators; it polls AD for login events but does not perform direct password validation. Option D is wrong because RADIUS is a generic AAA protocol that can authenticate against AD only if a RADIUS server (like NPS) is configured as an intermediary; it is not a direct AD authentication method and adds unnecessary complexity for admin authentication.

Full explanation →

171

MCQeasy

A network administrator wants to prevent users from downloading files with .exe extensions via HTTP and HTTPS. Which security profile feature should be used?

A.Web filter profile with URL filter to block .exe sites

B.Application control profile to block file transfer applications

C.Antivirus profile with 'block' action for file pattern matching .exe

D.IPS profile to block executable file transfers

AnswerC

The antivirus profile in FortiOS includes a file filter (or file pattern) capability that can match filenames, file extensions, or MIME types during protocol decoding. By configuring a file pattern for '.exe' and setting the action to 'block', FortiGate inspects the file's extension as it passes through HTTP (or HTTPS when deep inspection is enabled) and discards the file before it reaches the user. This is the correct method because the antivirus engine works at the content layer, not at the URL or application layer, and can enforce file-type blocking regardless of the website hosting the file.

Why this answer

The Antivirus profile in FortiGate can be configured with a file pattern matching rule to block files based on their extension, such as .exe. This feature operates at the application layer, inspecting HTTP and HTTPS traffic (via SSL inspection) to identify and block executable files before they reach the user. Option C is correct because it directly uses the antivirus engine's file pattern matching capability to enforce this policy.

Exam trap

The trap here is that candidates confuse URL filtering (which blocks sites) with file extension filtering (which blocks specific file types within allowed sites), leading them to choose the web filter profile option instead of the antivirus profile.

How to eliminate wrong answers

Option A is wrong because a web filter profile with URL filtering blocks access to entire websites or URL categories, not specific file extensions within HTTP/HTTPS downloads; it cannot inspect file content or extensions. Option B is wrong because an application control profile is designed to identify and control network applications (e.g., Skype, BitTorrent), not to block file transfers based on file extension; it does not inspect file payloads. Option D is wrong because an IPS profile is used to detect and prevent network-based attacks and vulnerabilities, not to block specific file types; it focuses on exploit signatures, not file extensions.

Full explanation →

172

MCQhard

A FortiGate with multiple WAN interfaces uses policy-based routing (PBR) to route traffic from subnet 10.0.0.0/24 through port1 and 10.0.1.0/24 through port2. However, traffic from 10.0.0.0/24 is still using port2. The PBR rule appears correctly configured. What is the MOST likely issue?

A.The source subnet in the PBR rule is incorrectly specified as 10.0.1.0/24

B.The firewall policy for that traffic has a route override setting that bypasses PBR

C.The static route for 0.0.0.0/0 has a higher administrative distance than the PBR rule

D.The PBR rule has a higher priority number than other rules

AnswerB

If the policy has an explicit route override (like setting the outgoing interface), it will bypass PBR. Disabling route override allows PBR to work.

Why this answer

The 'route override' setting in a firewall policy allows the FortiGate to ignore policy-based routing (PBR) rules for matching traffic. When enabled, the firewall policy uses the routing table (e.g., static or dynamic routes) instead of PBR, which explains why traffic from 10.0.0.0/24 is still using port2 despite a correctly configured PBR rule. This is a common misconfiguration where PBR appears correct but is overridden by the firewall policy's route override option.

Exam trap

The trap here is that candidates often assume PBR always takes precedence over static routes, but FortiGate's firewall policy 'route override' setting can silently bypass PBR, making it a hidden pitfall in multi-WAN configurations.

How to eliminate wrong answers

Option A is wrong because if the source subnet in the PBR rule were incorrectly specified as 10.0.1.0/24, traffic from 10.0.0.0/24 would not match the PBR rule at all, but the question states the PBR rule appears correctly configured, and the issue is that traffic is using port2 instead of port1, implying the rule exists but is being bypassed. Option C is wrong because administrative distance applies to static routes versus dynamic routes, not to PBR; PBR has a higher priority than static routes by default, and a static route's administrative distance does not affect whether PBR is applied. Option D is wrong because a higher priority number in PBR means lower priority (lower numbers are evaluated first), so a higher priority number would not cause the rule to be ignored; it would simply be evaluated later, but the rule would still apply if matched.

Full explanation →

173

MCQhard

You run the command 'diagnose vpn ike log filter name vpn1' and then 'diagnose vpn ike log filter type phase1'. The log shows: 'IKEv1 exchange:f4470f07:00000000: responder: main mode: received IKE_SA_INIT (aggressive mode not allowed)'. What is the problem?

A.The initiator is using IKEv2 while the responder uses IKEv1

B.The responder is configured for main mode only, but the initiator is sending aggressive mode

C.The pre-shared key is wrong

D.The phase1 proposal is incompatible

AnswerB

In IKEv1, an aggressive-mode initiator sends its SA proposal, key-exchange material, nonce, and identity in a single packet, while a main-mode-only responder expects the two-round-trip Main Mode sequence (SA exchange first, then KE/nonce). When the responder's phase 1 configuration is set to 'main mode only,' it immediately discards the incoming aggressive-mode packet and logs a mode mismatch such as 'aggressive mode is not supported.' This rejection occurs before any proposal comparison or PSK authentication, so the log indicates a configuration mismatch rather than a cryptographic or proposal failure.

Why this answer

The log message 'aggressive mode not allowed' indicates the responder (FortiGate) is configured to accept only main mode IKE phase1 negotiations, but the initiator sent an aggressive mode request. This mismatch causes the responder to reject the IKE_SA_INIT message, as aggressive mode is disabled by default or explicitly set to main mode only in the phase1 configuration.

Exam trap

The trap here is that candidates may confuse the 'aggressive mode not allowed' message with a proposal mismatch or authentication failure, but the log explicitly states the mode is the issue, not the cryptographic parameters or keys.

How to eliminate wrong answers

Option A is wrong because the log explicitly shows 'IKEv1 exchange', so both sides are using IKEv1, not IKEv2. Option C is wrong because a pre-shared key mismatch would cause a different error, such as 'invalid payload' or 'authentication failed', not a mode rejection message. Option D is wrong because an incompatible phase1 proposal would generate a 'no acceptable proposal' or 'proposal mismatch' error, not a message about aggressive mode not being allowed.

Full explanation →

174

MCQeasy

A FortiGate administrator configures a firewall policy to allow HTTP traffic from internal users to the internet. The policy uses source address 'internal_subnet', destination address 'all', and service 'HTTP'. After applying the policy, users report they cannot access websites. What is the most likely cause?

A.The source interface is misconfigured

B.The destination address object 'all' is incorrect

C.The policy order is incorrect and a deny policy above is blocking the traffic

D.The policy only allows HTTP (port 80), but users are likely accessing HTTPS (port 443)

AnswerD

A common oversight: the policy only permits port 80, but most websites use HTTPS on port 443.

Why this answer

The policy explicitly allows HTTP (TCP port 80), but modern web traffic predominantly uses HTTPS (TCP port 443). Since the service object does not include HTTPS, the firewall will drop HTTPS packets by default unless a separate policy or rule permits them. This is the most likely reason users cannot access websites, as most sites redirect HTTP to HTTPS or require HTTPS for secure connections.

Exam trap

The trap here is that candidates assume 'HTTP' covers all web traffic, but FortiGate treats HTTP and HTTPS as distinct services based on port numbers, and the implicit deny will block any unmatched traffic.

How to eliminate wrong answers

Option A is wrong because the source interface misconfiguration would typically cause a complete lack of connectivity for all traffic from that interface, not just web browsing, and the policy would not match at all. Option B is wrong because the destination address object 'all' is a valid FortiGate object that represents any destination IP address, and it is correct for allowing traffic to the internet. Option C is wrong because while policy order can affect traffic matching, the question states the policy was applied and there is no indication of a deny policy above; the most direct and common cause is the service mismatch.

Full explanation →

175

MCQhard

An administrator has configured an IPS profile with an anomaly detection sensor for 'tcp_syn_flood'. After applying the profile to a firewall policy, users report intermittent connectivity issues. The administrator runs 'diagnose ips anomaly list' and sees entries for 'tcp_syn_flood' with action 'pass'. What is the MOST likely cause of the connectivity issues?

A.The anomaly sensor is set to 'block' but the action is overridden by the policy

B.The anomaly sensor is using a different action than expected; it might be set to 'block' for some other sensor

C.The anomaly sensor is not actually applied; the list shows default entries

D.The anomaly sensor is set to 'pass' but the threshold is too low, causing false positives

AnswerC

Why this answer

The 'diagnose ips anomaly list' command shows default entries for 'tcp_syn_flood' with action 'pass' only when no custom anomaly sensor is applied to the policy. The administrator configured an IPS profile with an anomaly detection sensor, but if the profile is not correctly attached to the firewall policy or the sensor is not enabled, the firewall falls back to default anomaly entries that are set to 'pass' (i.e., no blocking). The intermittent connectivity issues are therefore not caused by the anomaly sensor blocking traffic, but by another misconfiguration or unrelated network problem.

Exam trap

The trap here is that candidates assume the 'diagnose ips anomaly list' output reflects the configured sensor action, when in fact it shows the active entries in the IPS engine, which may be defaults if the custom sensor is not applied, leading them to misinterpret the cause of connectivity issues.

How to eliminate wrong answers

Option A is wrong because if the anomaly sensor were set to 'block', the 'diagnose ips anomaly list' output would show 'block' for that sensor, not 'pass'; the policy does not override the sensor action for anomaly detection. Option B is wrong because the output specifically shows 'tcp_syn_flood' with action 'pass', not a different sensor; the administrator configured only one sensor, so there is no confusion with other sensors. Option D is wrong because if the sensor were set to 'pass' with a low threshold, it would still show 'pass' in the list, but the connectivity issues would be due to false positives causing drops, not intermittent issues; moreover, the 'pass' action means the firewall does not block the traffic, so false positives would not cause connectivity loss.

Full explanation →

176

Multi-Selectmedium

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

Select 2 answers

A.Configure an IP Pool with type Overload using 203.0.113.10

B.Configure a Virtual IP mapping 203.0.113.10:443 to 10.0.1.10:443

C.Create a firewall policy with source NAT enabled and the IP Pool selected

D.Configure Central SNAT with the same public IP

AnswersA, B

This provides source NAT for outbound traffic using the required public IP.

Why this answer

An IP Pool with type Overload allows multiple internal hosts to share a single public IP (203.0.113.10) for source NAT when traffic goes to the internet. This is the standard method for PAT (Port Address Translation) in FortiGate, enabling many-to-one NAT.

Exam trap

The trap here is that candidates often confuse IP Pools (for source NAT) with Virtual IPs (for destination NAT), or think that enabling source NAT in a policy alone is enough without configuring the IP Pool object.

Full explanation →

177

MCQhard

A FortiGate administrator runs 'diagnose vpn tunnel list' and sees the following output for an IPsec tunnel: 'status: up', 'incoming: 0 packets', 'outgoing: 100 packets'. Phase 1 and Phase 2 both show state 'up'. What is the MOST likely cause of zero incoming packets?

A.The remote gateway is using aggressive mode

B.The FortiGate has a static route pointing to the VPN interface

C.The VPN is configured in policy-based mode

D.The Phase 2 proposal includes a mismatched proxy ID

AnswerD

During Phase 2 negotiation, both peers exchange proxy IDs (traffic selectors) that define which source and destination subnets are encrypted. If the local proxy ID does not exactly match the remote peer's expected subnets, the IPsec SA is established with mismatched selectors. The remote gateway may then drop incoming packets that fall outside its configured selectors, or it may not respond at all, causing the tunnel to appear up but traffic to fail in one or both directions.

Why this answer

The output shows the VPN tunnel is up with outgoing packets but zero incoming packets. This indicates a Phase 2 mismatch, most commonly due to mismatched proxy IDs (local/remote subnets). When proxy IDs do not match between peers, the tunnel establishes but traffic is not correctly matched, causing the remote gateway to drop or not send traffic to the FortiGate, resulting in zero incoming packets.

Exam trap

The trap here is that candidates see 'status: up' and assume the tunnel is fully functional, overlooking that Phase 2 proxy ID mismatches can leave the tunnel up but unable to pass traffic in one direction.

How to eliminate wrong answers

Option A is wrong because aggressive mode affects Phase 1 authentication (using fewer exchanges and sending the ID in plaintext) but does not cause zero incoming packets once the tunnel is up; it would prevent Phase 1 from completing if mismatched. Option B is wrong because a static route pointing to the VPN interface is necessary for routing traffic into the tunnel; its presence would not cause zero incoming packets—it would actually help traffic flow. Option C is wrong because policy-based mode (vs. route-based) does not inherently cause zero incoming packets; both modes can work correctly if proxy IDs match.

The issue is specifically a Phase 2 proxy ID mismatch, which prevents the remote peer from associating incoming traffic with the correct SA.

Full explanation →

178

MCQmedium

An administrator needs to apply traffic shaping to limit bandwidth for video streaming traffic on a firewall policy. Which configuration step is required?

A.Use an application control profile to restrict video streaming

B.Configure policy-based routing to shape traffic

C.Enable QoS on the interface and set the bandwidth limit

D.Create a traffic shaper and reference it in the firewall policy

AnswerD

Traffic shapers define bandwidth limits and are applied via policies.

Why this answer

Traffic shaping in FortiGate is applied by creating a traffic shaper (either per-IP or shared) and then referencing that shaper in the firewall policy that matches the video streaming traffic. This allows the administrator to control bandwidth usage for specific traffic flows without affecting other traffic. Option D is correct because it directly describes this required configuration step.

Exam trap

The trap here is that candidates often confuse QoS interface settings (which limit all traffic on an interface) with traffic shapers (which limit specific traffic in a policy), leading them to select Option C instead of D.

How to eliminate wrong answers

Option A is wrong because an application control profile is used to identify and optionally block or allow applications, not to shape or limit bandwidth; it does not provide traffic shaping capabilities. Option B is wrong because policy-based routing (PBR) is used to route traffic based on source/destination or other attributes, not to shape or limit bandwidth; shaping is applied via traffic shapers in policies, not via routing decisions. Option C is wrong because enabling QoS on an interface sets a bandwidth limit for the entire interface, not for specific traffic types like video streaming; traffic shaping for specific applications requires a traffic shaper referenced in a firewall policy.

Full explanation →

179

Multi-Selecthard

A company needs to allow inbound HTTPS traffic from the internet to a web server behind the FortiGate. The public IP is 203.0.113.10, and the internal server is 192.168.1.10. The server must receive the original source IP of the client. Which THREE configurations are required to achieve this?

Select 3 answers

A.A firewall policy from WAN to DMZ allowing HTTPS traffic to the VIP

B.Disabling source NAT on the firewall policy (set nat enable disable)

C.A static route for 203.0.113.10 pointing to the ISP gateway

D.A Central SNAT policy to translate the source to the FortiGate's IP

E.A Virtual IP (VIP) mapping 203.0.113.10:443 to 192.168.1.10:443

AnswersA, B, E

The policy must permit the traffic to the VIP destination.

Why this answer

A firewall policy from WAN to DMZ is required to permit the inbound HTTPS traffic to the VIP. The policy must reference the VIP as the destination and allow HTTPS (TCP/443) to pass through the FortiGate.

Exam trap

The trap here is that candidates often think a static route for the public IP is needed, but the VIP is handled by the FortiGate's local routing, and the default route suffices for outbound traffic to the ISP.

Full explanation →

180

MCQhard

You run the CLI command 'diagnose vpn ike gateway list' and see that an IPsec VPN gateway is in 'up' state with 'initiator' mode, but no Phase 2 selectors are established. What is the most likely cause?

A.The Phase 2 proposal parameters (encryption, authentication) do not match between peers

B.The remote gateway is not responding to IKE packets

C.The local and remote Phase 2 selectors (proxy IDs) do not match

D.The IPsec interface is down

AnswerC

Mismatched proxy IDs prevent Phase 2 negotiation from completing successfully. The Phase 1 can be up but Phase 2 fails to establish.

Why this answer

When an IPsec VPN gateway is in 'up' state with 'initiator' mode but no Phase 2 selectors are established, it indicates that IKE Phase 1 (main mode or aggressive mode) has completed successfully, but Phase 2 (quick mode) negotiation has failed. The most common cause for Phase 2 failure is a mismatch in the Phase 2 selectors (proxy IDs), which define the local and remote subnets to be encrypted. FortiGate uses these selectors to match traffic and establish the IPsec SA; if they do not align between peers, the Phase 2 negotiation will not complete.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 failures, assuming an 'up' gateway means the entire VPN is working, but the 'initiator' mode and lack of Phase 2 selectors specifically point to a proxy ID mismatch rather than a proposal or connectivity issue.

How to eliminate wrong answers

Option A is wrong because Phase 2 proposal parameter mismatches (encryption, authentication) would typically cause a Phase 2 failure, but the question specifically states 'no Phase 2 selectors are established,' and the gateway is in 'up' state, meaning Phase 1 succeeded; Phase 2 proposal mismatches are a different issue that would still show Phase 2 negotiation attempts. Option B is wrong because if the remote gateway were not responding to IKE packets, the gateway would not reach an 'up' state in Phase 1; the 'up' state confirms that IKE Phase 1 completed, so the remote gateway is responding. Option D is wrong because the IPsec interface being down would prevent the gateway from reaching an 'up' state at all; the gateway status would show 'down' or the interface would be administratively down, not 'up' with no Phase 2 selectors.

Full explanation →

181

MCQhard

A FortiGate in flow-based mode is configured with an antivirus profile to block infected files. A user downloads a .zip file containing a known virus, but the download is allowed and the file is not quarantined. What is the MOST likely reason?

A.The antivirus profile is not set to 'block' for virus outbreaks

B.The virus definition database is outdated

C.Flow-based inspection does not support antivirus for .zip archives

D.Flow-based inspection does not decompress archives by default

AnswerD

In flow-based inspection mode, the FortiGate processes files in a streaming fashion, reading data as it flows through and not buffering the whole file, which means it cannot decompress archive files like .zip before scanning their contents. Because the virus is hidden inside the .zip, the scanner never actually sees it, so the file passes through undetected even if signatures are current. Proxy-based inspection, in contrast, buffers the entire file and can decompress archives to scan each contained file, which is why flow mode fails in this situation. The default behavior in flow mode is not to decompress archives, making this the correct explanation.

Why this answer

In flow-based inspection mode, FortiGate does not decompress archive files (such as .zip) by default. This means the antivirus engine cannot inspect the contents of the compressed file, so even if a known virus is inside, it will not be detected or blocked. To inspect archives in flow-based mode, you must enable 'deep archive inspection' in the antivirus profile.

Exam trap

The trap here is that candidates assume flow-based and proxy-based modes behave identically regarding archive scanning, but FortiGate's flow-based mode requires explicit configuration to decompress archives, whereas proxy-based mode does it by default.

How to eliminate wrong answers

Option A is wrong because the antivirus profile's 'block' action for virus outbreaks is a separate setting for outbreak prevention, not for standard virus detection; the issue here is that the file inside the archive was never inspected. Option B is wrong because an outdated virus definition database would cause missed detection of new viruses, but the scenario specifies a 'known virus', implying the signature exists; the core problem is the lack of archive decompression, not signature age. Option C is wrong because flow-based inspection does support antivirus for .zip archives, but only if archive decompression is explicitly enabled; the statement that it does not support it at all is incorrect.

Full explanation →

182

MCQeasy

A FortiGate administrator wants to authenticate VPN users against an existing LDAP server. The administrator creates an LDAP user group on the FortiGate. What additional configuration is REQUIRED to use this group for IPsec VPN authentication?

A.In the IPsec Phase 1 configuration, set the peer type to 'dialup' and specify the user group under authentication

B.Enable LDAP over TLS (LDAPS) on the FortiGate

C.Assign the LDAP user group to a firewall policy

D.Configure a RADIUS server as an intermediate proxy between FortiGate and LDAP

AnswerA

For dial-up IPsec VPN, the Phase 1 configuration must include the user group to authenticate users against LDAP.

Why this answer

For IPsec VPN authentication, the FortiGate must know which users are allowed to connect. Setting the peer type to 'dialup' in Phase 1 enables the FortiGate to accept connections from remote users rather than another gateway. Specifying the LDAP user group under authentication tells the FortiGate to validate the VPN user's credentials against that group's members, which are resolved via the LDAP server.

Without this configuration, the FortiGate has no way to associate the LDAP group with the VPN tunnel.

Exam trap

The trap here is that candidates often confuse the authentication configuration (Phase 1) with the authorization configuration (firewall policies), leading them to select Option C, thinking that assigning the group to a policy is sufficient for VPN authentication.

How to eliminate wrong answers

Option B is wrong because LDAPS (LDAP over TLS) is a transport security measure for the LDAP connection, but it is not required for IPsec VPN authentication; the FortiGate can authenticate using plain LDAP or LDAPS, and the question asks for what is required. Option C is wrong because firewall policies control traffic flow after authentication, not the authentication process itself; assigning the LDAP user group to a firewall policy is needed for authorization and access control, but it does not enable the VPN to authenticate users. Option D is wrong because a RADIUS server is not required; the FortiGate can directly query the LDAP server for authentication without an intermediate proxy, and using RADIUS would be an additional, optional configuration.

Full explanation →

183

Multi-Selectmedium

A network admin wants to block all traffic from the BitTorrent application. The admin has enabled application control on the firewall policy. Which step is necessary to achieve this?

Select 1 answer

A.Add a DNS filter profile to block BitTorrent tracker domains

B.Add the BitTorrent application signature to the application control profile and set action to block

C.Set the application control inspection mode to proxy-based

D.Enable 'deep inspection' in the application control profile

E.Enable SSL deep inspection on the firewall policy

AnswersB

Correct. Adding the BitTorrent signature to the application control profile and blocking it will directly prevent the traffic.

Why this answer

To block BitTorrent traffic, the admin must add the BitTorrent application signature to the application control profile and set the action to block (option B). Application control can detect BitTorrent even though it uses proprietary encryption—FortiGate uses protocol decoders and signature matching on unencrypted handshake data. SSL deep inspection (option E) is not required because BitTorrent does not use SSL/TLS encryption; enabling deep inspection would not help and would add unnecessary overhead.

Options A, C, and D are also unnecessary: DNS filter does not block the application itself, proxy-based inspection is not mandatory, and deep inspection (in the profile) is not the correct setting.

Exam trap

The trap is assuming that all encrypted applications require SSL deep inspection. BitTorrent uses proprietary protocol encryption, not SSL/TLS. Application control can identify BitTorrent without decryption by analyzing unencrypted portions of the traffic, so deep inspection is not needed.

Full explanation →

184

MCQmedium

A network administrator wants to implement two-factor authentication for SSL VPN users using FortiToken. The users are already authenticated against an LDAP server. Which configuration step is required to enforce two-factor authentication?

A.Create a local user with the same username as the LDAP user and assign a FortiToken to that local user

B.Create a user group that uses LDAP as the authentication server and enable FortiToken two-factor authentication in the group settings

C.Configure the SSL VPN portal to require FortiToken and set the authentication server to LDAP

D.Set the SSL VPN authentication method to 'certificate' and use FortiToken as second factor

AnswerB

Correct. The user group authenticates against LDAP and then requires a FortiToken for two-factor.

Why this answer

FortiGate requires a user group to combine LDAP authentication with FortiToken two-factor authentication. By creating a user group that uses LDAP as the authentication server and enabling FortiToken in the group settings, the FortiGate will first authenticate the user against LDAP and then prompt for a FortiToken code as the second factor. This is the standard method to enforce two-factor authentication for SSL VPN users without creating duplicate local users.

Exam trap

The trap here is that candidates often think two-factor authentication can be enabled directly on the SSL VPN portal or by creating a local user with a token, but FortiGate requires the token to be associated with a user group that references the external authentication server.

How to eliminate wrong answers

Option A is wrong because creating a local user with the same username as the LDAP user and assigning a FortiToken to that local user would require the user to authenticate against the local database, not LDAP, which defeats the purpose of using LDAP as the primary authentication source. Option C is wrong because configuring the SSL VPN portal to require FortiToken and setting the authentication server to LDAP does not actually enable two-factor authentication; the portal settings only control the user experience, not the authentication method itself. Option D is wrong because setting the SSL VPN authentication method to 'certificate' changes the primary authentication to certificate-based, and FortiToken cannot be used as a second factor in that context; certificate authentication and FortiToken are separate mechanisms.

Full explanation →

185

MCQeasy

An administrator has configured two FortiGate units in an active-passive HA cluster. The primary unit fails. How does the secondary unit become active?

A.The secondary unit detects loss of heartbeat from the primary and takes over

B.The administrator must manually reboot the secondary unit

C.The secondary unit becomes active only if the heartbeat link is also down

D.The secondary unit waits for a configuration change before becoming active

AnswerA

Heartbeat monitoring triggers failover when primary is unreachable.

Why this answer

In an active-passive HA cluster, the secondary unit monitors the primary unit's health via heartbeat messages. When the primary fails and stops sending heartbeats, the secondary unit detects the loss of heartbeat and initiates a failover, transitioning to the active role. This is the default behavior in FortiGate HA, where the secondary unit does not require manual intervention or additional conditions to become active.

Exam trap

The trap here is that candidates may think the secondary unit requires the heartbeat link to be down or manual intervention to become active, but FortiGate HA automatically promotes the secondary unit upon detecting the primary's failure via heartbeat loss.

How to eliminate wrong answers

Option B is wrong because FortiGate HA is designed for automatic failover; the administrator does not need to manually reboot the secondary unit, as that would defeat the purpose of high availability. Option C is wrong because the secondary unit becomes active when the primary fails, regardless of whether the heartbeat link is also down; the heartbeat link being down alone would not trigger a failover if the primary is still active. Option D is wrong because the secondary unit does not wait for a configuration change; it becomes active based on the failure detection, and configuration synchronization occurs after the failover.

Full explanation →

186

MCQhard

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

A.diagnose user fsso poll user <username>

B.diagnose wad user list

C.diagnose debug authd fsso list

D.diagnose test authserver ldap <server> <username>

AnswerC

Correct. This command lists all FSSO users with their IP addresses and group memberships.

Why this answer

The command 'diagnose debug authd fsso list' displays the current FSSO login status for all users, including the Fortinet Single Sign-On (FSSO) session information such as username, IP address, and group membership. This command queries the authentication daemon (authd) which maintains the FSSO user database, allowing the administrator to verify if a specific user is authenticated and which firewall policies apply. It directly addresses the scenario where users are logged into the domain but web traffic is blocked, as it confirms whether the FSSO polling has successfully registered the user's login.

Exam trap

The trap here is that candidates confuse FSSO verification commands with LDAP authentication test commands or proxy user lists, leading them to choose options that test different authentication mechanisms (LDAP or WAD) rather than the FSSO-specific authd database.

How to eliminate wrong answers

Option A is wrong because 'diagnose user fsso poll user <username>' is not a valid CLI command; the correct syntax for polling a specific user is 'diagnose user fsso poll-user <username>' (with a hyphen), and even then it only triggers a one-time poll from the collector agent, not a verification of current login status. Option B is wrong because 'diagnose wad user list' displays users authenticated by the web application daemon (WAD) for explicit proxy or web cache, not FSSO domain users; it is irrelevant for verifying Active Directory polling-based FSSO. Option D is wrong because 'diagnose test authserver ldap <server> <username>' tests LDAP authentication against an LDAP server, which is used for direct LDAP authentication, not for FSSO polling; FSSO relies on domain controller event logs or polling, not LDAP binds.

Full explanation →

187

MCQmedium

A FortiGate administrator wants to ensure that traffic from the 192.168.1.0/24 network to the internet is translated to a single public IP address using overload (PAT). Which NAT configuration should be used?

A.Policy-based NAT with a fixed port range

B.One-to-one NAT IP Pool

C.Virtual IP (VIP) with port forwarding

D.Central SNAT with a dynamic IP pool using overload

AnswerD

Central SNAT with a dynamic IP pool using overload is the correct approach because it implements many-to-one Source NAT: the FortiGate dynamically selects a public IP from the pool and rewrites each internal source IP to that public IP while also changing the source port to a unique value, enabling thousands of internal connections to share a single public address. Central NAT is the recommended method for outbound internet traffic because it cleanly separates NAT configuration from firewall policies and directly supports overload/PAT, matching the requirement for general internet egress.

Why this answer

Central SNAT with a dynamic IP pool using overload (PAT) is the correct method to translate all traffic from the 192.168.1.0/24 network to a single public IP address. The 'overload' option enables port address translation (PAT), allowing multiple internal hosts to share one public IP by using unique source port numbers, which is exactly what the administrator needs for internet-bound traffic.

Exam trap

The trap here is that candidates often confuse 'one-to-one NAT' (Option B) with PAT, thinking it can overload a single IP, but one-to-one NAT requires a dedicated public IP per internal host and does not perform port translation.

How to eliminate wrong answers

Option A is wrong because policy-based NAT with a fixed port range restricts the number of concurrent translations to the size of the port range, which would not allow all hosts in the /24 network to share a single IP efficiently and could exhaust ports quickly. Option B is wrong because one-to-one NAT IP Pool maps each internal IP to a unique public IP, requiring multiple public IPs and not supporting overload (PAT) to share a single IP. Option C is wrong because Virtual IP (VIP) with port forwarding is used for inbound destination NAT (port forwarding) to internal servers, not for outbound source NAT with overload to a single public IP.

Full explanation →

188

MCQhard

An administrator configures a policy route to send all traffic from a specific subnet to a different next-hop. However, traffic from that subnet is still using the default route. Which configuration could be causing this?

A.The firewall policy denies the traffic before policy routing

B.The policy route is applied to the wrong incoming interface

C.The default route has a higher administrative distance

D.The policy route destination is set to all

AnswerB

Policy routes are tied to a specific incoming interface, so if the traffic arrives on a different interface than the one specified in the policy route, the route will never be evaluated. The administrator must confirm that the policy route's incoming interface matches the physical port where the traffic actually enters the FortiGate. Since the policy route is not applied on the wrong interface, the traffic follows the normal routing table, and the intended policy behavior is not observed.

Why this answer

Policy routes are evaluated based on the incoming interface of the traffic. If the policy route is applied to the wrong incoming interface, traffic from the specified subnet arriving on a different interface will not match the policy and will instead follow the default route. This is a common misconfiguration where the administrator assumes the policy applies globally rather than per-interface.

Exam trap

The trap here is that candidates often assume policy routes apply globally to all traffic matching the source/destination, forgetting that FortiGate requires the incoming interface to be explicitly specified for policy routes to be evaluated.

How to eliminate wrong answers

Option A is wrong because firewall policies are evaluated after policy routing in FortiGate's processing order; if policy routing matches, the traffic is forwarded to the policy route's next-hop before any firewall policy is checked, so a deny firewall policy would not cause the traffic to use the default route. Option C is wrong because a higher administrative distance makes a route less preferred, so if the default route had a higher administrative distance, it would be less likely to be used, not more; the issue is that the policy route is not being matched at all. Option D is wrong because setting the policy route destination to 'all' would match all destinations, which would actually increase the likelihood of the policy route being applied, not cause it to be ignored; the problem is the interface mismatch, not the destination setting.

Full explanation →

189

MCQmedium

An administrator runs the following CLI command and sees the output: 'diagnose sys session list | grep -A 5 10.1.1.100' and finds a session with 'proto=6 proto_state=01 duration=3600 expire=3599'. What does this indicate about the session?

A.The session is about to expire

B.The session has been active for approximately 1 second

C.The session has been active for 3600 seconds

D.The session is using UDP protocol

AnswerC

The 'duration' field in Fortinet's session output records the age of the session in seconds, counting upward from the moment the connection was first seen. In this output, duration=3600 directly indicates the session has been active for exactly 3600 seconds (one hour). This is the only option that matches the literal value in the CLI output.

Why this answer

The 'duration' field in Fortinet session output indicates the actual time the session has been alive (session age), while 'expire' indicates the remaining time before timeout. Here, duration=3600 means the session has been active for 3600 seconds (1 hour). expire=3599 is just slightly less than the duration, but the key is that duration is the age. Therefore, option C is correct.

Exam trap

Common mistake: Candidates think 'duration' is the timeout value, but in Fortinet's 'diagnose sys session list', 'duration' is the elapsed time since the session started, and 'expire' is the remaining time. The timeout is the sum of duration and expire (if not zero), but here duration is directly the age.

How to eliminate wrong answers

Option A is wrong because 'expire=3599' indicates the session still has 3599 seconds left, so it is not about to expire; it is nearly full duration. Option C is wrong because 'duration=3600' is the total session timeout value, not the actual time the session has been active; the active time is duration minus expire (1 second). Option D is wrong because 'proto=6' indicates TCP protocol (protocol number 6), not UDP (which is protocol 17).

Full explanation →

190

MCQhard

An administrator runs 'diagnose ips anomaly list' and sees the following output: List of anomaly events: ID: 1, Type: tcp_syn_flood, Status: triggered, Count: 1500, Threshold: 1000 What does this indicate?

A.The IPS anomaly sensor is configured to block all TCP traffic.

B.The FortiGate has detected a single TCP SYN packet and is logging it.

C.The FortiGate is experiencing a TCP SYN flood attack and has triggered rate-based detection.

D.The FortiGate is performing a TCP SYN flood attack.

AnswerC

The output displays an anomaly event of type 'tcp_syn_flood' in the triggered state, which means the FortiGate has detected that the number of incompleted TCP SYN packets has exceeded the configured threshold for the anomaly sensor. This is rate-based detection because the sensor continuously monitors the rate of SYN packets and compares it against a threshold; when the rate shoots up, the anomaly is considered triggered and the configured action (such as dropping subsequent packets or sending an alert) is executed. Therefore, the FortiGate is correctly interpreting a TCP SYN flood attack targeting itself or a protected host.

Why this answer

The output from 'diagnose ips anomaly list' shows a tcp_syn_flood anomaly with a count of 1500 exceeding the threshold of 1000, and the status is 'triggered'. This indicates that the FortiGate's IPS anomaly sensor has detected a rate-based anomaly — specifically, the number of TCP SYN packets received per second has surpassed the configured threshold, which is a classic sign of a TCP SYN flood attack. The FortiGate has triggered its rate-based detection mechanism, which can then take configured actions such as alerting or blocking, confirming option C as correct.

Exam trap

The trap here is that candidates may confuse a triggered anomaly with a permanent block action or misinterpret the count as a single packet, when in fact the output clearly shows a rate-based threshold exceedance indicating an ongoing flood attack.

How to eliminate wrong answers

Option A is wrong because the IPS anomaly sensor does not block all TCP traffic; it only monitors and optionally blocks traffic that exceeds a specific rate threshold for a defined anomaly type, such as tcp_syn_flood. Option B is wrong because the output shows a count of 1500 and a threshold of 1000, indicating multiple packets have been detected over a rate interval, not a single packet, and the anomaly is triggered, not just logged. Option D is wrong because the FortiGate is the victim or detection point, not the attacker; the output indicates it is receiving an excessive number of SYN packets, not generating them.

Full explanation →

191

MCQmedium

A FortiGate administrator wants to ensure that traffic from the internal network to an external FTP server uses a specific source IP address (203.0.113.10). The internal network uses RFC 1918 addresses. Which NAT configuration should be used?

A.Policy-based NAT using an IP pool set to 'Fixed Port Range'

B.Virtual IP (VIP) mapping the internal server to 203.0.113.10

C.Central SNAT with dynamic IP pool

D.Policy-based NAT using an IP pool with type 'Overload' and the IP address 203.0.113.10

AnswerD

Policy-based NAT with an IP pool of type Overload performs source NAT by translating the source address of all matching sessions to the single IP defined in the pool. Since the pool contains only 203.0.113.10, every outbound session from the internal server will appear to originate from that exact IP using PAT (port address translation). This directly meets the requirement of ensuring all traffic from the server uses 203.0.113.10 as the source IP.

Why this answer

Policy-based NAT with an IP pool type 'Overload' (PAT) allows multiple internal hosts to share the single public IP 203.0.113.10 for outbound traffic. This meets the requirement to translate RFC 1918 source addresses to a specific source IP when accessing an external FTP server, while preserving port multiplexing.

Exam trap

The trap here is confusing VIP (inbound destination NAT) with source NAT (SNAT), leading candidates to select Option B, even though the requirement is for outbound traffic from internal clients to use a specific source IP.

How to eliminate wrong answers

Option A is wrong because 'Fixed Port Range' IP pools are used for static port allocation, typically for protocols that require predictable ports (e.g., SIP), not for general outbound source NAT with a single IP. Option B is wrong because a Virtual IP (VIP) is used for inbound destination NAT (port forwarding) to map an external IP to an internal server, not for outbound source NAT from internal clients. Option C is wrong because Central SNAT with a dynamic IP pool would select from a range of IPs, not guarantee the specific source IP 203.0.113.10.

Full explanation →

192

MCQeasy

An administrator wants to restrict SSL VPN access to only users who have a valid client certificate issued by the company's internal CA. Which setting should be configured?

A.Configure a firewall policy with identity-based authentication

B.Enable 'certificate-based authentication' in the user group

C.Enable 'require client certificate' in the SSL VPN settings

D.Import the users' public keys into the FortiGate

AnswerC

Setting 'Require Client Certificate' in the SSL VPN settings makes the FortiGate demand a client certificate during the SSL/TLS handshake, and only a certificate signed by a configured trusted CA will be accepted. This ensures that every SSL VPN session is cryptographically tied to a credential that is bound to a specific US user, so users without a valid certificate cannot even initiate the handshake. This is the direct control that physically enforces certificate-based access.

Why this answer

The 'require client certificate' setting in the SSL VPN portal or interface configuration enforces mutual TLS (mTLS), where the FortiGate requests and validates a client certificate against the configured CA. This ensures that only users presenting a valid certificate issued by the company's internal CA can establish the SSL VPN tunnel, regardless of their authentication credentials.

Exam trap

The trap here is that candidates confuse 'certificate-based authentication' with a user group setting, when in fact the enforcement point is the SSL VPN portal or interface configuration, not the user group definition.

How to eliminate wrong answers

Option A is wrong because identity-based firewall policies control access based on user/group authentication (e.g., LDAP or local users), not client certificate validation; they do not enforce certificate-based client identity at the SSL VPN tunnel level. Option B is wrong because 'certificate-based authentication' in a user group is not a valid FortiGate setting; user groups support authentication methods like LDAP, RADIUS, or PKI, but the group itself does not have a toggle for certificate-based authentication—this must be configured in the SSL VPN settings. Option D is wrong because importing users' public keys into the FortiGate is not a standard method for client certificate validation; the FortiGate validates client certificates by trusting the issuing CA's certificate, not by importing individual user public keys.

Full explanation →

193

MCQmedium

An administrator creates a firewall policy with a traffic shaper to limit bandwidth for guest wireless users. After applying the policy, users can still consume high bandwidth. The administrator confirms the policy is matching. What is the MOST likely reason the traffic shaper is not effective?

A.The traffic shaper's maximum bandwidth is set too high

B.The traffic shaper is applied to the wrong direction (egress vs ingress)

C.The traffic shaper is configured but not applied to the policy's 'Traffic Shaper' field

D.The traffic shaper is a per-IP shaper but the policy applies to a subnet

AnswerC

FortiGate traffic shapers are objects that must be explicitly referenced in a firewall policy; simply creating a shaper under Traffic Shaping does not cause any policy to use it. The firewall policy's 'Traffic Shaper' field and 'Per-IP Shaper' field both default to 'None', which means traffic matching the policy is forwarded with no bandwidth limitation. To enforce a shaping rule, the administrator must select the desired shaper in that drop-down field. When the shaper is left unassigned, the policy passes traffic at full interface speed, perfectly explaining the 'high bandwidth consumption' symptom.

Why this answer

In FortiGate, a traffic shaper must be explicitly selected in the 'Traffic Shaper' field of the firewall policy to be applied. Simply creating a shaper and configuring it is insufficient; the policy's shaper field links the shaper to the traffic. Without this link, the shaper is not enforced, even if the policy matches.

Exam trap

The trap here is that candidates assume creating a traffic shaper automatically applies it to all matching traffic, but FortiGate requires explicit assignment in the firewall policy's shaper field to enforce the limit.

How to eliminate wrong answers

Option A is wrong because setting the maximum bandwidth too high would still limit bandwidth, just at a higher threshold; it would not cause the shaper to be completely ineffective. Option B is wrong because traffic shapers in FortiGate are applied per policy and control both ingress and egress directions based on the shaper type (e.g., per-policy shaper applies to both directions); direction misconfiguration would not render the shaper entirely ineffective. Option D is wrong because a per-IP shaper applied to a subnet is valid and would limit each individual IP's bandwidth; it would not cause the shaper to be ineffective.

Full explanation →

194

MCQeasy

A network administrator wants to prevent users from accessing known malicious websites using FortiGate. Which security profile should be applied to the firewall policy to achieve this goal?

A.Antivirus profile

B.Application control profile

C.IPS profile

D.Web filtering profile

AnswerD

A web filtering profile is purpose-built to control web access by evaluating each requested URL against FortiGuard's real-time web category database, which includes categories like gambling, adult, and malicious sites. It can block or allow entire categories, apply URL or DNS filtering, and log or warn users based on policy. This is the exact tool to prevent users from accessing inappropriate content, as it can be assigned to a firewall policy to filter both HTTP and HTTPS traffic.

Why this answer

Web filtering profile. FortiGate's web filtering profile uses URL rating and category-based filtering to block access to known malicious websites by leveraging FortiGuard's real-time threat intelligence. This is the specific security profile designed to control web access based on URL reputation, including blocking malicious URLs.

Exam trap

The trap here is that candidates often confuse web filtering with application control or IPS, mistakenly thinking that blocking malicious websites requires signature-based detection or application-layer control, rather than URL reputation-based filtering.

How to eliminate wrong answers

Option A is wrong because an Antivirus profile scans files for malware but does not block access to websites based on URL reputation or category. Option B is wrong because an Application control profile identifies and controls network applications (e.g., social media, streaming) but does not filter web URLs or block malicious websites. Option C is wrong because an IPS profile detects and prevents network-based attacks using signatures, but it is not designed to block access to known malicious websites based on URL filtering.

Full explanation →

195

MCQeasy

Which of the following FortiGate features allows users to authenticate using a one-time password generated by a mobile app?

A.FSSO

B.LDAP

C.FortiToken

D.Captive portal

AnswerC

FortiToken generates OTPs for two-factor authentication.

Why this answer

FortiToken is Fortinet's two-factor authentication solution that generates one-time passwords (OTPs) via a mobile app (FortiToken Mobile) or hardware token. When a user authenticates, they must provide both their regular password and the current OTP from the FortiToken app, which is validated by the FortiGate against the token's seed record. This directly matches the question's requirement for OTP generation by a mobile app.

Exam trap

The trap here is that candidates often confuse FortiToken with FSSO or LDAP because all three involve authentication, but only FortiToken specifically generates and validates one-time passwords via a mobile app.

How to eliminate wrong answers

Option A (FSSO) is wrong because FSSO (Fortinet Single Sign-On) collects user login events from domain controllers to map users to IP addresses for policy enforcement, but it does not generate or validate one-time passwords. Option B (LDAP) is wrong because LDAP is a directory service protocol used for storing and retrieving user credentials and attributes; it does not generate OTPs or provide two-factor authentication. Option D (Captive portal) is wrong because a captive portal is a web-based authentication interface that redirects users to a login page, but it does not generate OTPs; it can be used with external authentication methods but is not itself an OTP generator.

Full explanation →

196

MCQmedium

A FortiGate admin notices that HTTPS traffic to a web server is not being scanned by the antivirus profile applied to the firewall policy. The admin confirms the policy is correct and antivirus is enabled. What is the MOST likely reason the traffic is not being scanned?

A.The FortiGuard antivirus subscription has expired

B.The web server's certificate is self-signed and FortiGate is rejecting the connection

C.SSL/TLS deep inspection is not enabled on the firewall policy

D.The antivirus profile is configured for flow-based inspection instead of proxy-based

AnswerC

HTTPS traffic is encrypted. FortiGate cannot inspect the payload without SSL deep inspection decrypting the TLS session. The antivirus profile requires inspection mode to be enabled.

Why this answer

HTTPS traffic is encrypted with SSL/TLS, so the FortiGate cannot inspect the payload for viruses unless SSL/TLS deep inspection is enabled to decrypt the traffic. Even with an antivirus profile applied, the FortiGate can only scan the outer headers of encrypted sessions without deep inspection, leaving the actual content unscanned. Option C correctly identifies that deep inspection must be explicitly enabled on the firewall policy to allow the antivirus profile to scan decrypted HTTPS traffic.

Exam trap

The trap here is that candidates often assume antivirus profiles can scan all traffic types by default, forgetting that encrypted traffic requires explicit decryption via SSL/TLS deep inspection before any content scanning can occur.

How to eliminate wrong answers

Option A is wrong because an expired FortiGuard antivirus subscription would prevent signature updates but would not stop scanning of traffic that is already encrypted; the FortiGate would still attempt to scan, but with outdated signatures, not fail to scan entirely. Option B is wrong because a self-signed certificate does not cause the FortiGate to reject the connection; by default, the FortiGate passes HTTPS traffic without inspection, and a self-signed certificate would only cause issues if deep inspection is enabled and the FortiGate is configured to validate certificates. Option D is wrong because both flow-based and proxy-based inspection modes can scan HTTPS traffic when deep inspection is enabled; the inspection mode affects how scanning is performed (e.g., performance vs. granularity) but does not prevent scanning of encrypted traffic without decryption.

Full explanation →

197

MCQmedium

A network admin configures a site-to-site IPsec VPN between two FortiGates using IKEv1 main mode. The tunnel establishes successfully, but no traffic passes. What is the MOST likely cause?

A.Aggressive mode should be used instead of main mode

B.The pre-shared key is incorrect

C.There is no firewall policy allowing traffic through the VPN tunnel

D.The phase2 proposal does not match between peers

AnswerC

Even when the IPsec tunnel interface is up and phase 1/phase 2 SAs are active, FortiGate will not forward any user traffic through the tunnel unless an explicit firewall policy permits it. The policy must be configured with the source address, destination address, and service, and its outgoing interface must be set to the VPN tunnel interface (or the virtual IPsec interface). Without such a policy, packets are dropped at the firewall policy check even though the encrypted tunnel exists and is healthy. This is the classic root cause when the VPN shows connected but users cannot reach remote resources, and the fix is to create the appropriate ACCEPT policy from the local zone to the VPN zone.

Why this answer

The tunnel establishes successfully, meaning IKE phase 1 and phase 2 negotiations completed correctly, which rules out mismatched proposals or incorrect pre-shared keys. However, even with a functional IPsec tunnel, traffic cannot flow unless a firewall policy explicitly permits it between the source and destination zones using the VPN interface. In FortiGate, the VPN tunnel is treated as an interface, and without a policy allowing traffic from the internal network to the VPN interface (or vice versa), packets are dropped by the firewall engine.

Exam trap

The trap here is that candidates assume a successful IPsec tunnel automatically allows traffic, but FortiGate requires an explicit firewall policy to permit traffic through the VPN interface, unlike some other vendors where the tunnel itself implies a permit.

How to eliminate wrong answers

Option A is wrong because aggressive mode is used for faster negotiation with less security (e.g., when peer IP is dynamic), but main mode is fully valid and not the cause of traffic failure after tunnel establishment. Option B is wrong because if the pre-shared key were incorrect, IKE phase 1 authentication would fail and the tunnel would never establish. Option D is wrong because a phase 2 proposal mismatch would cause the IPsec SA negotiation to fail, preventing the tunnel from establishing; since the tunnel is up, the proposals must match.

Full explanation →

198

MCQhard

A FortiGate has the following policy list: ID 1: allow from trust to untrust, source 10.0.0.0/24, destination all, service HTTP, NAT enabled. ID 2: allow from trust to untrust, source 10.0.1.0/24, destination all, service ALL, NAT enabled. A host 10.0.1.50 sends an HTTP request to 203.0.113.5. Which policy matches?

A.Policy ID 2 because it matches the source and service

B.Both policies, and the traffic is load-balanced

C.No policy matches, traffic is denied by implicit deny

D.Policy ID 1 because it is first in order and matches the service HTTP

AnswerA

Policy ID 2 matches source and service.

Why this answer

Policy ID 2 matches because the source IP 10.0.1.50 falls within the 10.0.1.0/24 subnet, and the service is set to ALL, which includes HTTP. FortiGate uses a top-down policy lookup and selects the first match based on source, destination, and service; since Policy ID 2 matches all criteria, it is applied.

Exam trap

The trap here is that candidates assume the first policy in the list always matches if the service is HTTP, ignoring that the source must also match; FortiGate requires all conditions to be met for a policy to apply.

How to eliminate wrong answers

Option B is wrong because FortiGate does not load-balance traffic across multiple matching policies; it uses a first-match logic, so only one policy is selected. Option C is wrong because a matching policy exists (ID 2), so traffic is not denied by the implicit deny rule. Option D is wrong because Policy ID 1 does not match the source (10.0.1.50 is not in 10.0.0.0/24), so it is skipped even though it is first in order.

Full explanation →

199

MCQhard

A FortiGate administrator receives reports that users cannot access a legitimate website that uses HTTPS. The web filtering profile is configured with strict FortiGuard categories and 'monitor all' for unknown sites. The firewall policy has an SSL/SSH inspection profile set to 'deep-inspection'. What is the most likely cause of the issue?

A.The website uses a self-signed certificate which is not trusted by the FortiGate CA bundle

B.The antivirus profile is blocking a file on the website

C.The DNS filter is blocking the domain

D.The website's FortiGuard category is set to 'block'

AnswerA

Deep inspection requires the FortiGate to trust the server certificate. A self-signed or untrusted CA certificate will cause the connection to fail.

Why this answer

The most likely cause is that the website uses a self-signed certificate, which is not included in the FortiGate's trusted CA bundle. When deep inspection is enabled, the FortiGate acts as a man-in-the-middle and must validate the server's certificate against its CA store; a self-signed certificate fails this validation, causing the connection to be blocked. This is a common issue with strict inspection profiles that require trusted certificates.

Exam trap

The trap here is that candidates often confuse a certificate validation failure (caused by self-signed or untrusted certificates) with a web filtering category block, but the presence of deep inspection and 'monitor all' for unknown sites points directly to the SSL inspection process, not the web filter.

How to eliminate wrong answers

Option B is wrong because an antivirus profile blocking a file would typically generate a specific block message or log entry for the file, not a general inability to access the HTTPS website. Option C is wrong because a DNS filter blocking the domain would prevent DNS resolution entirely, resulting in a 'server not found' error, not an HTTPS certificate error. Option D is wrong because if the website's FortiGuard category were set to 'block', the web filtering profile would block the site regardless of the SSL inspection profile, and the user would see a FortiGate block page rather than a certificate error.

Full explanation →

200

MCQhard

A FortiGate is configured with SSL deep inspection using a self-signed CA certificate. Users report that they see a certificate warning in their browser when accessing HTTPS sites. The admin wants to eliminate these warnings. What should the admin do?

A.Install the FortiGate's CA certificate on each client device's trusted root certificate store

B.Disable SSL deep inspection and rely on flow-based antivirus

C.Change the SSL inspection mode to certificate inspection only

D.Configure an SSL certificate exemption for all HTTPS traffic

AnswerA

Installing the FortiGate CA certificate into each client's trusted root store is the only way to make the browser accept the dynamically generated server certificates that FortiGate presents during MITM decryption. Without this trust anchor, every HTTPS session fails the chain validation and triggers a 'certificate not trusted' warning. This step validates the FortiGate as the legitimate signing authority for its intercepted sessions, eliminating warnings and restoring secure, transparent deep inspection.

Why this answer

When FortiGate performs SSL deep inspection, it decrypts HTTPS traffic by acting as a man-in-the-middle, using its own CA certificate to re-encrypt the connection. If the FortiGate's self-signed CA certificate is not trusted by the client, the browser will display a certificate warning because the issuer is not in the client's trusted root store. Installing the FortiGate's CA certificate on each client device's trusted root certificate store establishes trust, eliminating the warnings.

Exam trap

The trap here is that candidates may think disabling or bypassing SSL inspection (options B, C, or D) is a valid way to eliminate warnings, but the correct approach is to establish trust by distributing the FortiGate's CA certificate to clients.

How to eliminate wrong answers

Option B is wrong because disabling SSL deep inspection removes the ability to inspect encrypted traffic for threats, but it does not address the root cause of certificate warnings; it simply avoids the issue. Option C is wrong because certificate inspection only examines the certificate exchange without decrypting the payload, which prevents deep content inspection but still requires a trusted CA to avoid warnings if any interception is performed. Option D is wrong because configuring an SSL certificate exemption for all HTTPS traffic effectively bypasses inspection entirely, leaving the traffic unexamined and defeating the purpose of SSL deep inspection.

Full explanation →

201

MCQmedium

An admin wants to block all traffic from a specific geographic region. Which address object type should be used in the firewall policy source?

A.FQDN

B.Subnet

C.IP range

D.Geography

AnswerD

Geography objects use IP geolocation to match traffic from specific countries.

Why this answer

FortiGate firewalls include a built-in Geography address object type that allows policies to match traffic based on the source or destination IP address's registered country or region. This object uses GeoIP databases to classify IP addresses, enabling administrators to block or allow traffic from entire geographic areas without needing to manually list individual subnets or ranges.

Exam trap

The trap here is that candidates may confuse Geography with IP range or subnet, thinking they can manually compile a list of all IPs for a region, but FortiGate's Geography object automates this via the GeoIP database and is the correct, scalable approach for geographic blocking.

How to eliminate wrong answers

Option A is wrong because FQDN (Fully Qualified Domain Name) objects resolve to IP addresses via DNS and are used for policies based on domain names, not geographic location. Option B is wrong because a Subnet object defines a contiguous block of IP addresses using a network prefix (e.g., 192.168.1.0/24) and cannot represent an entire geographic region. Option C is wrong because an IP range object specifies a start and end IP address (e.g., 10.0.0.1-10.0.0.255) and is intended for arbitrary address ranges, not for geographic classification.

Full explanation →

202

MCQmedium

A company has a web server in the DMZ that needs to be accessible from the internet on port 443 (HTTPS). The administrator configures a Virtual IP (VIP) mapping the public IP 203.0.113.10 to the private IP 10.0.1.10 port 443. Which firewall policy is required to allow inbound traffic?

A.A policy from WAN to DMZ with source any, destination IP of the server (10.0.1.10), and action ACCEPT

B.A policy from WAN to DMZ with source any, destination VIP, and action ACCEPT

C.No firewall policy is needed; the VIP automatically allows traffic

D.A policy from DMZ to WAN with source VIP, destination any, and action ACCEPT

AnswerB

This is the correct way to publish a server. The VIP object defines the public-to-private IP mapping, and the policy uses that VIP as the destination to explicitly allow inbound traffic. After the policy is matched, FortiOS performs destination NAT, replacing the VIP IP with the server's private IP and forwarding the packet to the DMZ. This ensures that all traffic is inspected and controlled by the firewall.

Why this answer

When a Virtual IP (VIP) is configured in FortiGate, the firewall policy must reference the VIP object as the destination, not the actual private IP. The VIP translates the public IP (203.0.113.10) to the private IP (10.0.1.10), and the policy from WAN to DMZ with destination VIP ensures that inbound traffic is matched and permitted before NAT translation occurs. Without this policy, the VIP alone does not allow traffic; it only defines the translation rule.

Exam trap

The trap here is that candidates often assume a VIP automatically permits traffic or that the policy should use the private IP, but FortiGate requires an explicit firewall policy referencing the VIP object to allow inbound traffic through the NAT mapping.

How to eliminate wrong answers

Option A is wrong because the policy must use the VIP object as the destination, not the actual private IP (10.0.1.10); referencing the private IP bypasses the NAT translation and will not match the incoming traffic destined to the public IP. Option C is wrong because a VIP does not automatically allow traffic; it only defines the NAT mapping, and a corresponding firewall policy with action ACCEPT is mandatory to permit the traffic. Option D is wrong because the required policy must be from WAN to DMZ (inbound direction), not from DMZ to WAN; the DMZ-to-WAN policy would control outbound responses, not the initial inbound connection.

Full explanation →

203

MCQmedium

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

A.Create an IP pool with the external IP and reference it in the firewall policy

B.Enable NAT on the firewall policy without specifying an IP pool

C.Create a VIP for the web server and reference it in the firewall policy

D.Configure Central SNAT and a matching rule

AnswerB

When you enable NAT on a firewall policy and leave the IP pool field blank, FortiOS performs source NAT using the primary IP address of the egress interface—here, 198.51.100.1. This is the simplest and most common method for enabling internet access from a private network, as it requires no separate NAT objects or additional configuration. The NAT action is directly part of the policy, exactly matching the scenario's request to apply NAT to the policy itself.

Why this answer

When a firewall policy uses source NAT (SNAT) to translate internal source IPs to the FortiGate's own egress interface IP, simply enabling NAT on the policy without specifying an IP pool is sufficient. This is the default behavior: the FortiGate automatically performs source NAT using the IP address of the outgoing interface (in this case, 198.51.100.1). No additional IP pool or central NAT rule is required for this standard outbound NAT scenario.

Exam trap

The trap here is that candidates often confuse source NAT with destination NAT and incorrectly select a VIP (option C), or they overcomplicate the scenario by assuming an IP pool is always required for NAT, when in fact the default interface NAT is sufficient when the goal is to use the FortiGate's own external IP.

How to eliminate wrong answers

Option A is wrong because creating an IP pool is necessary only when you need to translate to a specific IP address that is not the egress interface IP, or when you need to use a range of IPs (e.g., for load balancing or hiding many internal hosts behind a smaller set of public IPs). Here, the requirement is to use the FortiGate's own external IP, which is the default behavior when NAT is enabled without a pool. Option C is wrong because a Virtual IP (VIP) is used for destination NAT (DNAT), i.e., translating an incoming public IP to an internal private IP, not for source NAT.

The question asks for source NAT, so a VIP is irrelevant. Option D is wrong because Central SNAT is an alternative method for configuring source NAT, but it is not required; the question does not specify a need for central NAT management, and the standard policy-based NAT (enabling NAT on the policy) is the simplest and correct approach for this scenario.

Full explanation →

204

Multi-Selecthard

A FortiGate administrator is troubleshooting an issue where users cannot access an internal HTTPS server (10.10.10.10:443) after enabling SSL deep inspection. The administrator sees that the server's certificate is self-signed. Which TWO actions should the administrator take to allow access while maintaining inspection?

Select 2 answers

A.Disable deep inspection on the policy

B.Change the policy action to DENY

C.Disable certificate validation in the SSL/SSH profile

D.Import the server's self-signed certificate into FortiGate's trusted CA list

E.Add the server's IP address to the SSL/SSH profile's exemption list

AnswersD, E

If FortiGate trusts the server's CA (or the certificate itself), it can establish the inspection without certificate errors.

Why this answer

Importing the server's self-signed certificate into FortiGate's trusted CA list allows the FortiGate to trust the certificate during SSL deep inspection, preventing certificate validation errors. Option E is correct because adding the server's IP to the SSL/SSH profile's exemption list bypasses inspection for that specific server, allowing access without deep inspection while still applying other security profiles.

Exam trap

The trap here is that candidates often think disabling certificate validation (Option C) is a safe workaround, but it actually disables all certificate checks, which is a security risk and not the intended solution for trusting a specific self-signed certificate.

Full explanation →

205

MCQhard

An administrator runs 'diagnose vpn ike gateway list' on a FortiGate and sees the following output for a dial-up IPsec VPN: gateway name: 'dialup' version: IKEv1 mode: aggressive local IP: 203.0.113.1 remote IP: 0.0.0.0 state: up peers: 0 What does 'peers: 0' indicate?

A.The remote IP should be set to a specific address

B.The gateway is in a down state

C.No IPsec clients are currently connected

D.The Phase 2 proposals are mismatched

AnswerC

Peers: 0 indicates zero active connections.

Why this answer

In the output of 'diagnose vpn ike gateway list', the 'peers' field shows the number of active IPsec tunnels (Phase 1 SAs) currently established through that gateway. A value of '0' means no remote clients have successfully completed IKE negotiation and are connected. Since the gateway state is 'up', it is ready to accept connections, but no clients are currently associated with it.

Exam trap

The trap here is that candidates see 'state: up' and assume the gateway has active connections, but 'up' only indicates the IKE process is running and listening, not that any peers are actually connected.

How to eliminate wrong answers

Option A is wrong because in a dial-up IPsec VPN, the remote IP is intentionally left as 0.0.0.0 to allow any remote client to initiate a connection; setting a specific address would defeat the purpose of a dial-up configuration. Option B is wrong because the output explicitly shows 'state: up', indicating the IKE gateway process is active and listening, not down. Option D is wrong because Phase 2 proposal mismatches would cause failures during IPsec SA establishment, not affect the Phase 1 peer count; the 'peers' counter specifically tracks Phase 1 SAs, not Phase 2.

Full explanation →

206

Multi-Selectmedium

An administrator wants to allow only HTTPS and SSH administrative access to the FortiGate from a specific management subnet 192.168.100.0/24. Which TWO steps must be taken on the FortiGate?

Select 2 answers

A.Set the trusted host(s) on the administrator account to 192.168.100.0/24

B.Create a local-in policy to allow traffic from 192.168.100.0/24

C.Enable HTTPS and SSH globally under system global

D.Configure a firewall policy to permit HTTPS and SSH from the management subnet to the FortiGate

E.On the interface, set allowaccess to https and ssh

AnswersA, E

This restricts which IPs can access the FortiGate via those protocols.

Why this answer

Setting the trusted host(s) on an administrator account restricts administrative logins to only those originating from the specified subnet (192.168.100.0/24). This is a per-account access control that works in conjunction with interface-level allowaccess settings to enforce administrative source IP restrictions.

Exam trap

The trap here is that candidates often confuse firewall policies (which control forwarded traffic) with local-in policies or interface allowaccess settings (which control traffic destined to the FortiGate itself), leading them to incorrectly select option D.

Full explanation →

207

MCQhard

An administrator configures an application control profile to block 'Facebook' and 'Twitter' using application signatures. Users can still access Facebook via HTTPS. The firewall policy has application control enabled and SSL deep inspection is not configured. Why is Facebook not blocked?

A.The application signature for Facebook is not updated

B.The application control profile is configured in monitor-only mode

C.HTTPS traffic is encrypted and cannot be inspected without SSL deep inspection

D.Facebook uses a non-standard port that application control does not monitor

AnswerC

Application signatures rely on payload; encryption hides that.

Why this answer

Without SSL deep inspection, the FortiGate cannot decrypt HTTPS traffic to inspect the application-layer payload. Application control relies on inspecting unencrypted traffic or using SSL inspection to identify applications within encrypted sessions. Since Facebook uses HTTPS, the encrypted traffic passes through without being matched against the application signature, so the block action is not enforced.

Exam trap

The trap here is that candidates assume application control can block any application regardless of encryption, overlooking the fundamental requirement for SSL deep inspection to inspect HTTPS traffic at the application layer.

How to eliminate wrong answers

Option A is wrong because the question states the administrator configured application signatures for Facebook and Twitter, and there is no indication the signatures are outdated; even if they were, the core issue is encryption, not signature version. Option B is wrong because the question says the firewall policy has application control enabled, and there is no mention of monitor-only mode; if it were monitor-only, the traffic would be logged but not blocked, yet the user can still access Facebook, which aligns with the lack of inspection, not a monitor-only setting. Option D is wrong because Facebook uses standard HTTPS ports (443) and application control monitors all ports by default; the issue is encryption, not port selection.

Full explanation →

208

MCQhard

An administrator integrates FortiGate with FortiSandbox for advanced threat detection. The FortiGate is configured to send files to FortiSandbox for analysis. Despite correct configuration, files are not being submitted. The administrator runs 'diagnose debug application fortisandbox -1' and sees 'no server configured'. What is the issue?

A.The FortiSandbox license has expired

B.Firewall policies are blocking communication to the FortiSandbox server

C.The FortiSandbox server IP address is not configured on the FortiGate

D.The antivirus profile is not configured to submit files to FortiSandbox

AnswerC

The debug message clearly states 'no server configured', meaning the FortiSandbox server definition is missing.

Why this answer

The debug output 'no server configured' explicitly indicates that the FortiGate does not have a FortiSandbox server IP address defined in its configuration. Without the server IP configured under 'config system fortisandbox', the FortiGate cannot establish a connection or submit files, regardless of other settings. This is a prerequisite step before any file submission can occur.

Exam trap

The trap here is that candidates often assume the issue is a firewall policy or license problem, but the debug output's exact wording 'no server configured' directly points to a missing server IP configuration, which is a common oversight.

How to eliminate wrong answers

Option A is wrong because an expired FortiSandbox license would generate a license-related error or warning in the debug output, not 'no server configured'. Option B is wrong because firewall policies blocking communication would result in connection timeouts or 'connection refused' errors, not a 'no server configured' message which indicates the server address is missing entirely. Option D is wrong because while the antivirus profile must have 'fortisandbox' enabled for submission, the debug message 'no server configured' points to a missing server IP configuration, not a profile misconfiguration.

Full explanation →

209

Multi-Selecteasy

An administrator needs to configure DNS on a FortiGate so that internal hosts can resolve external domain names. Which two settings are required? (Choose two.)

Select 2 answers

A.Configure DNS servers under System > DNS.

B.Create a firewall policy allowing DNS traffic from internal to external.

C.Enable DNS proxy on the FortiGate.

D.Set the FortiGate's hostname to the domain name.

E.Configure a static route for DNS servers.

AnswersA, C

DNS server addresses must be specified for the FortiGate to perform resolution.

Why this answer

Configuring DNS servers under System > DNS is the fundamental step that tells the FortiGate which external DNS resolvers (e.g., 8.8.8.8) to use for resolving domain names. Without this, the FortiGate cannot forward DNS queries from internal hosts to the internet. Option C is correct because enabling the DNS proxy on the FortiGate allows it to intercept DNS requests from internal clients, cache responses for performance, and forward them to the configured DNS servers, which is essential for internal hosts to resolve external domains through the FortiGate.

Exam trap

The trap here is that candidates often think a firewall policy is required for DNS traffic, but the FortiGate's DNS proxy handles the forwarding internally, making the explicit policy unnecessary unless the proxy is disabled and hosts send queries directly.

Full explanation →

210

MCQhard

A company has two remote sites connected via an SD-WAN overlay. The headquarters uses a FortiGate with two WAN links: Fiber (priority 1) and LTE (priority 2). The SD-WAN rule for business-critical traffic uses the 'best quality' strategy with SLA targets for latency and jitter. The fiber link occasionally experiences high jitter but low latency. The engineer notices that traffic is not failing over to LTE even when jitter exceeds the threshold. What is the most likely reason?

A.The performance SLA for jitter is not configured, only latency.

B.The SD-WAN rule has SLA match set to 'either' instead of 'all'.

C.The LTE link has a higher cost and is not considered for failover.

D.The fiber link has a higher interface weight.

AnswerA

Correct; only configured SLA targets are measured for failover.

Why this answer

The SD-WAN rule uses the 'best quality' strategy, which selects the best link based on configured SLA metrics. If only latency is configured in the performance SLA, jitter exceeding the threshold will not trigger a failover, as the SLA only evaluates the configured metrics. The fiber link may still meet the latency SLA, so traffic remains on it despite high jitter.

Exam trap

The trap here is that candidates assume jitter is automatically monitored in SD-WAN SLA, but FortiGate requires explicit configuration of each metric (latency, jitter, packet loss) in the performance SLA; otherwise, unconfigured metrics are ignored for failover decisions.

How to eliminate wrong answers

Option B is wrong because the 'either' vs 'all' setting in SLA match determines whether any or all configured SLA targets must be met for the link to be considered compliant; it does not prevent failover when jitter exceeds the threshold if jitter is not configured. Option C is wrong because SD-WAN failover decisions are based on SLA compliance and strategy, not link cost; cost influences route selection in routing protocols but not SD-WAN rule failover. Option D is wrong because interface weight affects load-balancing ratios in strategies like 'lowest cost' or 'maximize bandwidth', not failover decisions in 'best quality' strategy.

Full explanation →

211

MCQmedium

A company has a FortiGate with multiple VDOMs. An admin creates a firewall policy in the root VDOM to allow traffic from a subnet to the internet. The traffic is not matching the policy. What is the most likely cause?

A.The traffic is in a different VDOM than the policy

B.The internet-facing interface is not part of any VDOM

C.The subnet object is defined in the wrong address group

D.The policy is placed at the bottom of the list

AnswerA

Each VDOM on a FortiGate operates as an independent virtual firewall with its own routing table, policy set, and interface associations. A firewall policy configured in the root VDOM only examines traffic whose ingress and egress interfaces belong to that same VDOM. If the traffic flows through interfaces assigned to VDOM2, the root policy is never evaluated, so the traffic is instead subject to VDOM2's own policy list, and the mismatch explains why the policy has no effect.

Why this answer

In a multi-VDOM FortiGate, each VDOM operates as an independent virtual firewall with its own routing table, policies, and interfaces. A firewall policy created in the root VDOM only applies to traffic that enters and exits interfaces assigned to that root VDOM. If the traffic originates from or is destined to an interface belonging to a different VDOM, it will never match the root VDOM policy, causing the traffic to be dropped or handled by the correct VDOM's policies.

Exam trap

The trap here is that candidates assume a policy in the root VDOM applies to all traffic by default, not realizing that VDOMs create strict administrative boundaries where policies are only effective within their own VDOM.

How to eliminate wrong answers

Option B is wrong because an internet-facing interface must be assigned to a VDOM to function; unassigned interfaces are not operational and cannot pass traffic. Option C is wrong because even if the subnet object is in the wrong address group, the policy would still match if the source IP falls within the defined subnet range; the issue is VDOM isolation, not address group membership. Option D is wrong because policy order only matters within the same VDOM; a policy at the bottom of the list in the root VDOM would still match traffic that belongs to the root VDOM, but it cannot match traffic from a different VDOM regardless of its position.

Full explanation →

212

MCQhard

A FortiGate administrator is troubleshooting a problem where users cannot access the Internet. The FortiGate has a default route pointing to the ISP gateway. The administrator runs 'execute ping 8.8.8.8' from the FortiGate CLI and it succeeds. However, internal users behind NAT are unable to reach external servers. Which is the most likely cause?

A.The default route is incorrectly configured

B.An implicit deny policy is blocking traffic from internal to external

C.No NAT policy is configured for internal users

D.External access profile is set to read-only

AnswerC

If no NAT policy is configured for internal users' traffic, the FortiGate forwards packets with the original private source IP addresses (e.g., 10.0.0.0/8). The external server sends reply packets to that private address, which is not routable across the public internet, causing return traffic to be dropped or blackholed. The FortiGate's own ping works because it uses its interface's public IP as the source, so replies are routable. This mismatch—successful ping from the FortiGate but failures for internal users—is a classic symptom of missing source NAT.

Why this answer

The administrator confirmed that the FortiGate itself can reach the Internet (ping 8.8.8.8 succeeds), so the default route and basic connectivity are working. However, internal users behind NAT cannot reach external servers, which indicates that traffic from internal users is either not being translated or is being blocked. The most likely cause is that no NAT policy (or firewall policy with NAT enabled) exists to perform source NAT for internal users, so their private IP addresses are not translated to the FortiGate's public IP, and the ISP gateway drops the packets because private addresses are not routable on the Internet.

Exam trap

The trap here is that candidates assume a successful ping from the FortiGate CLI proves end-to-end connectivity for all users, but they overlook that NAT translation is required for internal private IPs to reach the Internet.

How to eliminate wrong answers

Option A is wrong because the default route is correctly configured — the 'execute ping 8.8.8.8' succeeded, proving the route works. Option B is wrong because an implicit deny policy would block all traffic, including the ping from the FortiGate itself; since the ping succeeded, there is no implicit deny blocking outbound traffic. Option D is wrong because the external access profile is a GUI/administrative access setting that controls read/write permissions for the web interface, not a factor in NAT or traffic forwarding.

Full explanation →

213

MCQmedium

A FortiGate administrator is configuring an SSL VPN web mode portal. The administrator wants users to access only a specific internal web application (https://internal-app.company.local) and nothing else. Which SSL VPN setting should be configured to achieve this?

A.In the SSL VPN portal, set the default bookmark to the application URL

B.Configure a firewall policy that allows traffic only to the application's IP address

C.Enable split tunneling under the SSL VPN settings

D.Under the SSL VPN portal, configure 'URL Access' to allow only https://internal-app.company.local

AnswerD

The URL Access feature under the SSL VPN portal provides a per-portal whitelist of web addresses that users are allowed to access through the reverse proxy. When you specify only https://internal-app.company.local, the FortiGate enforces that rule during proxy processing: any request to a URL that does not match the whitelist is denied with an error. This precisely meets the requirement because it is a proxy-level, application-aware access control, rather than a network-layer rule or a UI shortcut. It effectively prevents users from browsing to any other internal or external web host through the portal while allowing the specific internal application.

Why this answer

The 'URL Access' setting in the SSL VPN web mode portal allows the administrator to explicitly define which URLs users can access through the portal. By configuring an allow list with only https://internal-app.company.local, users are restricted to that specific internal web application, and all other URLs are blocked. This provides granular control over web-based resources in the SSL VPN portal without relying on network-layer restrictions.

Exam trap

The trap here is that candidates often confuse network-layer controls (firewall policies or split tunneling) with application-layer controls (URL Access), assuming that blocking traffic at the IP/port level is sufficient to restrict web-based access within an SSL VPN portal.

How to eliminate wrong answers

Option A is wrong because setting a default bookmark only pre-populates the user's portal with a link to the application; it does not restrict access to other URLs, so users could still navigate to other internal or external sites via the portal. Option B is wrong because a firewall policy controls traffic at the network layer (IP/port), not the application-layer URL access within the SSL VPN web mode portal; users could still access other web applications on the same IP or port if not explicitly blocked at the URL level. Option C is wrong because split tunneling controls whether client traffic goes through the VPN tunnel or directly to the internet for tunnel-mode VPNs, not for web mode portals; it does not restrict which URLs users can access within the portal.

Full explanation →

214

MCQmedium

A FortiGate administrator needs to ensure that all outbound DNS queries from internal clients are inspected for malicious domains. The administrator has a DNS filter profile configured. What additional configuration is required on the firewall policy to make the DNS filter effective?

A.Enable SSL deep inspection on the policy

B.Configure FortiGuard DNS filtering service on the FortiGate

C.Set the inspection mode to proxy-based

D.Apply the DNS filter profile to a firewall policy that matches DNS traffic (UDP/TCP port 53)

AnswerD

The DNS filter profile must be attached to a policy that handles DNS traffic; otherwise it is not applied.

Why this answer

A DNS filter profile must be explicitly applied to a firewall policy that matches DNS traffic (UDP/TCP port 53) to be effective. Without this association, the FortiGate will not inspect DNS queries against the configured DNS filter profile, even if the profile is defined globally or under Security Profiles.

Exam trap

The trap here is that candidates often assume configuring a DNS filter profile globally or under Security Profiles is sufficient, but FortiGate requires explicit policy attachment for the profile to take effect on traffic.

How to eliminate wrong answers

Option A is wrong because SSL deep inspection is not required for DNS filtering; DNS traffic is typically unencrypted, and enabling SSL inspection would add unnecessary overhead without improving DNS inspection. Option B is wrong because configuring the FortiGuard DNS filtering service is part of the DNS filter profile setup, not an additional configuration on the firewall policy; the policy itself needs the profile applied. Option C is wrong because while proxy-based inspection can support DNS filtering, flow-based inspection also supports DNS filtering in FortiOS 6.0 and later; the inspection mode is not a prerequisite for applying a DNS filter profile to a policy.

Full explanation →

215

MCQmedium

A.The web server's certificate is self-signed and FortiGate is rejecting the connection

B.The FortiGuard antivirus subscription has expired

C.The antivirus profile is configured for flow-based inspection instead of proxy-based

D.SSL/TLS deep inspection is not enabled on the firewall policy

AnswerD

To inspect HTTPS for malware, FortiGate must terminate the TLS session using an SSL/TLS deep inspection profile, which decrypts the payload, applies the antivirus profile, and then re-encrypts the traffic. Without this, the FortiGate only sees ciphertext and cannot apply antivirus signatures because the content is opaque. The firewall policy must explicitly reference an SSL inspection profile set to 'deep-inspection' (not just 'certificate-inspection') and clients must trust the FortiGate's CA to avoid handshake warnings. If this is not enabled, all HTTPS traffic bypasses antivirus scanning regardless of the configured antivirus profile.

Why this answer

D is correct because antivirus scanning of HTTPS traffic requires the firewall to decrypt the SSL/TLS-encrypted payload. Without SSL/TLS deep inspection enabled on the policy, FortiGate sees only encrypted packets and cannot inspect the content for viruses, even if an antivirus profile is applied. The admin must configure a deep inspection profile that includes SSL/TLS decryption to allow the antivirus engine to scan the decrypted traffic.

Exam trap

The trap here is that candidates often assume antivirus profiles can scan encrypted traffic automatically, but FortiGate cannot inspect encrypted payloads without SSL/TLS deep inspection enabled on the policy.

How to eliminate wrong answers

Option A is wrong because a self-signed certificate does not cause FortiGate to reject the connection by default; FortiGate will still forward the traffic, but without deep inspection, it cannot scan the encrypted content. Option B is wrong because an expired FortiGuard antivirus subscription would prevent signature updates but would not stop scanning of traffic that is already encrypted—the traffic would still be scanned if decrypted, but with outdated signatures. Option C is wrong because flow-based inspection can still scan HTTPS traffic if SSL/TLS deep inspection is enabled; the inspection mode (flow vs. proxy) affects how the scanning engine processes traffic, but both require decryption to inspect encrypted payloads.

Full explanation →

216

MCQmedium

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

A.Configure a single Central SNAT rule with multiple source subnets and a single IP pool

B.Create two firewall policies, each with its own IP pool, for the respective subnets

C.Use VIP for source NAT

D.Use a single policy with a dynamic IP pool that randomly assigns IPs

AnswerB

This allows granular control over which IP is used for each subnet.

Why this answer

The requirement is to map specific source subnets to different public IP addresses. In FortiGate, this is achieved by creating separate firewall policies for each subnet, each with its own IP pool configured for source NAT. A single Central SNAT rule with one IP pool cannot differentiate between subnets to assign different public IPs.

Exam trap

The trap here is that candidates often confuse IP pools (used for source NAT) with Virtual IPs (used for destination NAT), leading them to incorrectly select VIP for source NAT.

How to eliminate wrong answers

Option A is wrong because a single Central SNAT rule with one IP pool would apply the same public IP to all traffic matching the rule, regardless of source subnet, failing to meet the requirement for different public IPs per department. Option C is wrong because Virtual IP (VIP) is used for destination NAT (port forwarding), not source NAT; it translates incoming traffic's destination, not outgoing traffic's source. Option D is wrong because a dynamic IP pool randomly assigns IPs from a range, which does not guarantee that traffic from engineering always uses one specific public IP and marketing uses another; it would mix them.

Full explanation →

217

MCQmedium

A remote user connects via SSL VPN web mode but cannot access internal resources. The SSL VPN portal is configured with the default settings. What is the most likely reason?

A.The user must be authenticated via LDAP

B.The user has not installed the FortiClient VPN plugin

C.Web mode only allows access to specific bookmarks configured in the portal

D.The SSL VPN policy is missing a security profile

AnswerC

In SSL VPN web mode, the user's entire accessible domain is restricted to the bookmarks that the administrator has explicitly defined in the user's assigned portal. Without pre-configured bookmarks to internal URLs, the portal displays no resources, and the user cannot navigate to any internal application. This is exactly the symptom described: a remote user can connect and authenticate, but there are no portal bookmarks, so no access is granted.

Why this answer

In SSL VPN web mode, the FortiGate acts as a proxy, granting access only to pre-configured bookmarks (URLs or applications) defined in the SSL VPN portal. Default portal settings do not include any bookmarks, so even after successful authentication, the user sees an empty portal and cannot reach internal resources. This is by design, as web mode does not provide full network-layer access like tunnel mode does.

Exam trap

The trap here is that candidates often assume SSL VPN always provides full network access or that a missing security profile is the cause, but the NSE4 exam specifically tests the distinction between web mode (bookmark-based) and tunnel mode (full access).

How to eliminate wrong answers

Option A is wrong because authentication via LDAP is not a requirement for SSL VPN web mode; the user can be authenticated using any supported method (local, RADIUS, etc.) and the portal will still function. Option B is wrong because FortiClient VPN plugin is only required for tunnel mode (full network access) or for host-check features; web mode operates entirely through the browser without any client software. Option D is wrong because security profiles (AV, web filter, IPS) are applied to firewall policies, not directly to SSL VPN policies; the SSL VPN policy itself does not require a security profile to allow web-mode access.

Full explanation →

218

MCQhard

An administrator configures a dial-up IPsec VPN with IKEv2 to allow remote users to connect. The Phase 1 is set to use certificate-based authentication (PKI). Users can establish Phase 1, but Phase 2 fails with 'no proposal chosen'. The administrator checks the Phase 2 proposal: AES256-SHA256, and the remote network is 10.0.0.0/8 (the corporate LAN). What is the MOST likely cause?

A.The remote network in Phase 2 is set to 10.0.0.0/8

B.The remote network in Phase 2 is set to 0.0.0.0/0

C.The Phase 1 encryption algorithm is mismatched

D.The authentication type requires EAP instead of certificate

AnswerA

The remote network in Phase 2 should be 0.0.0.0/0 for dial-up, because the client's real IP is dynamic. Setting it to 10.0.0.0/8 means the FortiGate expects the client's IP to be in that range, which it is not.

Why this answer

The most likely cause is that the remote network (client subnet) in the Phase 2 configuration on the VPN gateway is set to 10.0.0.0/8 instead of the correct value (0.0.0.0/0) for dial-up clients. Since Phase 1 succeeds, authentication and encryption settings are correct. The 'no proposal chosen' error in Phase 2 indicates a traffic selector mismatch: the server expects the client's IP to be within the 10.0.0.0/8 range, but the client's actual IP typically falls outside that subnet.

Therefore, the Phase 2 negotiation fails.

Exam trap

The trap is that candidates often attribute Phase 2 failures to algorithm mismatches, but in IKEv2 dial-up VPNs, 'no proposal chosen' commonly results from an incorrect Phase 2 traffic selector. Specifically, the remote network (client subnet) on the server side must be set to 0.0.0.0/0 for dial-up clients, not the corporate LAN subnet.

How to eliminate wrong answers

Option B is wrong because setting the remote network to 0.0.0.0/0 would create a default route for all traffic, which is not the specific corporate LAN subnet and would still cause a Phase 2 mismatch if the gateway expects 10.0.0.0/8. Option C is wrong because Phase 1 is already established successfully, indicating that the encryption algorithms (including certificate-based authentication) are correctly matched; a Phase 1 mismatch would prevent Phase 1 from completing. Option D is wrong because certificate-based authentication (PKI) is explicitly configured and Phase 1 succeeds, so EAP is not required; EAP is typically used for extended authentication, not for basic IKEv2 Phase 1 with certificates.

Full explanation →

219

Multi-Selectmedium

A FortiGate admin is troubleshooting an issue where traffic from a specific internal host (10.0.1.50) to the internet is not being NATed as expected. The firewall policy has NAT enabled with an IP pool of type Overload. Which TWO conditions could cause the traffic to bypass the IP pool?

Select 2 answers

A.The firewall policy's NAT setting is set to 'disable'

B.The IP pool is configured for one-to-one NAT

C.The internal host is using a non-standard source port

D.A policy with a lower policy ID matches the traffic and has NAT enabled with a different IP pool or no pool

E.The IP pool is configured with a source filter that does not include 10.0.1.50

AnswersD, E

Policy matching stops at the first match; if a higher-priority policy matches, the intended policy is not evaluated.

Why this answer

FortiGate processes firewall policies in sequential order based on policy ID. If a policy with a lower ID matches the traffic and has NAT enabled with a different IP pool (or no pool), that policy will be applied first, causing the traffic to bypass the intended IP pool. Option E is correct because an IP pool of type Overload uses a source filter to determine which source addresses are eligible for NAT; if 10.0.1.50 is not included in that filter, the traffic will not use the pool.

Exam trap

The trap here is that candidates often overlook the sequential policy matching order and the source filter requirement, assuming that enabling NAT on a policy with an IP pool guarantees its use for all matching traffic.

Full explanation →

220

Multi-Selectmedium

Which TWO web filtering features can be used to block access to malicious websites? (Choose two.)

Select 2 answers

A.Static URL filtering

B.Application control

C.FortiGuard category-based filtering

D.Web rating override

E.DNS filter

AnswersC, D

Blocks categories like 'Malicious'.

Why this answer

FortiGuard category-based filtering (C) is correct because it leverages FortiGuard's cloud-based web rating database to categorize URLs and block access to known malicious sites, such as those hosting malware or phishing. Web rating override (D) is correct because it allows administrators to manually override the FortiGuard rating for specific URLs, enabling them to block a site that may not yet be categorized as malicious by FortiGuard. Both features directly control access to malicious websites based on URL reputation.

Exam trap

The trap here is that candidates often confuse DNS filter with web filtering, but DNS filter is a separate security feature (under DNS Filter profile) and is not considered a web filtering feature in the NSE4 exam; the question explicitly asks for 'web filtering features' as defined in the FortiGate Web Filter profile.

Full explanation →

221

Multi-Selecthard

Which THREE of the following are valid methods to exclude certain HTTPS traffic from SSL inspection on a FortiGate?

Select 3 answers

A.Adding the domain to the 'SSL Exempt Domains' list in the SSL/SSH inspection profile.

B.Setting the firewall policy action to 'accept' with no inspection.

C.Using a certificate category exemption (e.g., exempting 'Fortinet Trusted Certificate').

D.Using a web filter category exemption.

E.Adding the destination IP address to the 'SSL Exempt IPs' list in the SSL/SSH inspection profile.

AnswersA, C, E

Domain-based exemption is a supported method.

Why this answer

The 'SSL Exempt Domains' list in the SSL/SSH inspection profile allows you to specify domain names (e.g., *.example.com) that will bypass SSL inspection entirely. When FortiGate matches the SNI field in the ClientHello or the certificate CN/SAN against this list, it skips decryption and passes the traffic through without inspection, reducing overhead for trusted or non-critical domains.

Exam trap

The trap here is that candidates often confuse web filter category exemptions with SSL inspection exemptions, but web filter exemptions only affect URL filtering decisions, not the decryption process itself.

Full explanation →

222

MCQmedium

A FortiGate administrator is configuring a hub-and-spoke IPsec VPN. The hub has multiple Phase 2 selectors for each spoke. What is the recommended way to simplify configuration on the hub when adding new spokes?

A.Use a single Phase 2 selector with 0.0.0.0/0.0.0.0 for both local and remote

B.Configure each spoke in a separate VDOM

C.Use aggressive mode for Phase 1

D.Use policy-based VPN instead of route-based

AnswerA

Setting both local and remote Phase 2 selectors to 0.0.0.0/0 creates an any-to-any proxy ID, so all traffic routed into the tunnel interface is encrypted without needing a separate selector per subnet or per spoke. In a route-based VPN, the tunnel interface decouples routing from IPsec proxy IDs, so a single Phase 2 definition can be reused across every spoke; new spokes simply reuse the same selector and rely on routing to direct traffic. This is the standard FortiGate recommendation for hub-and-spoke because it avoids negotiation failures caused by mismatched local/remote subnet definitions and eliminates per-spoke Phase 2 configuration at the hub.

Why this answer

Using a single Phase 2 selector with 0.0.0.0/0.0.0.0 for both local and remote simplifies hub configuration because it allows the hub to accept traffic for any subnet from any spoke without needing to define specific selectors per spoke. This is recommended in hub-and-spoke topologies to avoid manual updates when adding new spokes, as the hub's Phase 2 configuration becomes generic and automatically matches all spoke traffic.

Exam trap

The trap here is that candidates often think policy-based VPNs are simpler for hub-and-spoke, but they actually require explicit selector pairs per spoke, making the hub configuration more complex and less scalable.

How to eliminate wrong answers

Option B is wrong because configuring each spoke in a separate VDOM adds unnecessary administrative overhead and complexity, and does not simplify the Phase 2 selector configuration on the hub. Option C is wrong because aggressive mode for Phase 1 is less secure than main mode (it sends identities in plaintext) and is not related to simplifying Phase 2 selectors; it is typically used for remote access with dynamic IPs, not hub-and-spoke simplification. Option D is wrong because policy-based VPNs require explicit firewall policies for each subnet pair, which actually increases configuration effort when adding new spokes, whereas route-based VPNs with a single Phase 2 selector are simpler for hub-and-spoke designs.

Full explanation →

223

Multi-Selecthard

A FortiGate admin is troubleshooting an IPsec VPN that fails to establish. The output of 'diagnose debug application ike -1' shows: 'IKE: No proposal chosen from x.x.x.x'. The admin checks the Phase1 configuration. Which of the following mismatches could cause this error? (Choose three.)

Select 3 answers

A.Diffie-Hellman group mismatch (e.g., group 2 vs group 14)

B.Pre-shared key mismatch

C.Lifetime mismatch (e.g., 86400 vs 3600)

D.Authentication method mismatch (e.g., SHA1 vs SHA256)

E.Encryption algorithm mismatch (e.g., AES128 vs AES256)

AnswersA, D, E

DH group is also part of the proposal.

Why this answer

The 'No proposal chosen' error indicates that the IKE SA parameters proposed by the initiator do not match any configured proposal on the responder. Since the error occurs during Phase 1, mismatches in mandatory parameters like Diffie-Hellman group, authentication method (hash algorithm), and encryption algorithm will directly cause this failure, as these are negotiated as part of the SA payload.

Exam trap

The trap here is that candidates often confuse Phase 1 proposal mismatches (which cause 'No proposal chosen') with Phase 1 authentication failures (caused by PSK mismatch), leading them to incorrectly select the pre-shared key option.

Full explanation →

224

MCQhard

You are troubleshooting an SSL VPN connection. The user can reach the SSL VPN portal but cannot ping or access any internal resources. The portal shows the user as authenticated. Which configuration is MOST likely missing?

A.There is no firewall policy allowing traffic from ssl.root to the internal network

B.Client certificate authentication is required but not provided

C.Split tunneling is disabled

D.The SSL VPN realm is not configured correctly

AnswerA

In Fortinet's SSL VPN design, the SSL VPN interface (typically ssl.root) is just a virtual interface; after authentication, the tunnel is up but traffic is still subject to normal firewall policy checks. Without a policy that matches source ssl.root and destination internal network with the appropriate action (accept), the FortiGate silently drops the packets. Thus users can authenticate and establish the tunnel, but cannot reach internal resources until an explicit policy is created, often with NAT and security profiles as needed.

Why this answer

The user can authenticate and reach the SSL VPN portal, which indicates that the SSL VPN tunnel itself is established and authentication is successful. However, the inability to ping or access internal resources despite being authenticated points to a missing firewall policy that explicitly permits traffic from the SSL VPN interface (ssl.root) to the internal network. Without this policy, the FortiGate will drop all traffic from the SSL VPN tunnel, even though the user is logged in.

Exam trap

The trap here is that candidates assume authentication success implies full network access, but FortiGate requires an explicit firewall policy for SSL VPN traffic, separate from the authentication and tunnel setup.

How to eliminate wrong answers

Option B is wrong because client certificate authentication is an additional security layer for the authentication phase; if it were required but not provided, the user would not be able to authenticate or reach the portal at all. Option C is wrong because split tunneling controls whether traffic for internal networks is sent through the VPN tunnel or directly to the internet; disabling split tunneling would actually force all traffic through the tunnel, which would not prevent access to internal resources once the tunnel is up. Option D is wrong because the SSL VPN realm configuration affects the portal page and authentication settings; if the realm were misconfigured, the user would likely not see the correct portal or would fail authentication, but the user is already authenticated and on the portal.

Full explanation →

225

MCQmedium

An administrator wants to configure SNMP on a FortiGate to allow a monitoring server 192.168.1.100 to poll read-only information. Which set of commands is correct?

A.config system snmp sysinfo set status enable set community public set trap-receiver 192.168.1.100 end

B.config system snmp community edit 1 set name public set query enable set query-port 161 set hosts 192.168.1.100 end

C.config system snmp set enable set community public set host 192.168.1.100 end

D.config system interface edit port1 set snmp-index 1 set allowaccess snmp end

AnswerB

Why this answer

SNMP read-only polling on FortiGate is configured under the `config system snmp community` hierarchy. The `set query enable` command allows SNMP GET requests, `set query-port 161` specifies the standard SNMP port, and `set hosts 192.168.1.100` restricts polling to that specific monitoring server. This matches the requirement for read-only access without configuring traps or enabling SNMP globally via the sysinfo context.

Exam trap

The trap here is that candidates often confuse the `config system snmp sysinfo` context (for system contact/location) with the community configuration context, or mistakenly think SNMP is enabled globally via a simple `set enable` command, when in fact the community must be explicitly created and enabled with `set query enable`.

How to eliminate wrong answers

Option A is wrong because `config system snmp sysinfo` is used to set system contact and location information, not to enable SNMP polling or define communities; `set community public` is invalid in that context, and `set trap-receiver` configures trap destinations, not polling hosts. Option C is wrong because `config system snmp` is not a valid configuration path on FortiGate; SNMP is configured under `config system snmp community` and `config system snmp sysinfo`, and `set enable` and `set community` are not valid commands at that level. Option D is wrong because `config system interface` with `set allowaccess snmp` only enables SNMP access on a specific interface, but it does not configure the SNMP community, query settings, or allowed hosts, which are required for the monitoring server to poll.

Full explanation →

Fortinet NSE 4 Network Security Professional NSE4 (NSE4) — Questions 151–225