Fortinet NSE 4 Network Security Professional NSE4 NSE4 Questions 226–282 | Page 4/4

226

MCQeasy

An administrator wants to authenticate VPN users against an external LDAP server. Which authentication method should be configured in the user group for the SSL VPN portal?

A.RADIUS

B.FSSO

C.Local

D.LDAP

AnswerD

LDAP authentication enables the FortiGate to validate VPN users by performing a direct bind to the LDAP server (such as Active Directory or OpenLDAP) using the user's distinguished name and password. The FortiGate can also retrieve group memberships during the authentication process, allowing LDAP-based groups to be used in firewall policies. This is the most straightforward and correct method when the authentication source is an LDAP server, as it avoids an extra RADIUS or other proxy layer.

Why this answer

To authenticate VPN users against an external LDAP server, the user group for the SSL VPN portal must be configured with the LDAP authentication method. This directs FortiGate to bind directly to the LDAP server (e.g., Active Directory or OpenLDAP) using the configured LDAP server object, performing a simple bind or SASL bind to verify user credentials. Other methods like RADIUS, FSSO, or Local would not leverage the LDAP server directly.

Exam trap

The trap here is that candidates often confuse 'LDAP' as a protocol with 'RADIUS' as a protocol, assuming both are interchangeable for external authentication, but FortiGate requires the LDAP method specifically when the authentication source is an LDAP directory server, not a RADIUS server.

How to eliminate wrong answers

Option A is wrong because RADIUS is a separate authentication protocol that uses a RADIUS server (e.g., FreeRADIUS or NPS) to proxy authentication, not a direct LDAP bind; it adds an intermediary and does not authenticate directly against LDAP. Option B is wrong because FSSO (Fortinet Single Sign-On) is used for transparent authentication based on Windows domain logon events, not for direct credential validation against an LDAP server for VPN access. Option C is wrong because Local authentication uses locally stored user accounts on the FortiGate, which bypasses any external LDAP server entirely.

Full explanation →

227

MCQmedium

A FortiGate administrator wants to configure a dial-up IPsec VPN where remote users connect using VPN clients with pre-shared key authentication. The company has recently experienced a data breach where the PSK was compromised. What is the best method to improve security without changing all clients immediately?

A.Switch to aggressive mode with a complex PSK

B.Enable XAuth with a second authentication factor using FortiToken

C.Increase the PSK length to 64 characters

D.Migrate to certificate-based authentication for Phase 1

AnswerD

Certificate-based Phase 1 authentication replaces the shared PSK with a unique asymmetric key pair per dial-up peer, binding each client's identity to its certificate. During IKE main mode, certificates enable mutual authentication without ever transmitting a shared secret in the clear, and compromised certificates can be individually revoked via a CRL or OCSP without affecting other peers. This eliminates the single-point-of-failure shared secret and is the correct way to harden a dial-up IPsec VPN.

Why this answer

Migrating to certificate-based authentication eliminates reliance on a static pre-shared key (PSK), which is inherently vulnerable to compromise. Certificates provide asymmetric cryptographic proof of identity, ensuring that even if a PSK is leaked, the attacker cannot authenticate without a valid certificate. This is the most robust long-term fix for PSK compromise in IPsec VPNs.

Exam trap

The trap here is that candidates often confuse user authentication (XAuth) with Phase 1 authentication, mistakenly believing that adding a second factor like FortiToken fixes the compromised PSK, when in fact the PSK is still used and vulnerable in the initial IKE exchange.

How to eliminate wrong answers

Option A is wrong because aggressive mode actually reduces security by sending the PSK in cleartext during Phase 1 negotiation, making it easier to capture and exploit. Option B is wrong because XAuth with FortiToken adds a second authentication factor for user identity, but it does not replace or secure the compromised PSK used in Phase 1; the PSK remains the weak link. Option C is wrong because increasing the PSK length to 64 characters only increases brute-force resistance, but does not address the fact that the PSK has already been compromised and is known to an attacker.

Full explanation →

228

MCQeasy

Which statement best describes the implicit deny policy at the end of a FortiGate policy list?

A.It denies all traffic that does not match any explicit policy, and it logs the denied traffic

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

C.It can be disabled or deleted by the admin

D.It is always present and denies any traffic that does not match an explicit allow policy

AnswerD

The implicit deny is always present as the last effective rule in the FortiGate policy list, regardless of how many explicit policies are configured. Any traffic that does not match an explicit allow policy is dropped by this default rule, ensuring that all unmatched packets are blocked. This is a mandatory security control that cannot be removed or repositioned, providing a safe default deny posture.

Why this answer

The implicit deny policy is a built-in, last-resort rule at the bottom of the FortiGate policy list that silently drops any traffic not matching an explicit allow policy. It cannot be moved, disabled, or deleted because it is a fundamental security mechanism ensuring that only explicitly permitted traffic is allowed through the firewall.

Exam trap

The trap here is that candidates often think the implicit deny can be configured or removed like an explicit policy, but FortiGate enforces it as an unchangeable, always-present rule that cannot be logged or repositioned.

How to eliminate wrong answers

Option A is wrong because the implicit deny policy does not log denied traffic by default; logging must be explicitly configured on an explicit deny policy. Option B is wrong because the implicit deny policy is fixed at the very end of the policy list and cannot be repositioned. Option C is wrong because the implicit deny policy is a permanent, non-removable safeguard that cannot be disabled or deleted by the administrator.

Full explanation →

229

MCQhard

An administrator configures SSL deep inspection with a CA certificate. Users accessing an internal site (internal.company.com) receive a certificate error. The administrator wants to avoid the error without disabling deep inspection. What should be done?

A.Replace the CA certificate with a self-signed one

B.Use certificate inspection instead of deep inspection

C.Disable certificate validation in the deep inspection profile

D.Add internal.company.com to the SSL/SSH inspection exemption list

AnswerD

Adding internal.company.com to the SSL/SSH inspection exemption list instructs the FortiGate to pass those sessions without decrypting or re-signing the certificate, so the client receives the original certificate issued by the company's internal PKI. This eliminates the certificate error because the client sees a chain it already trusts, while allowing deep inspection to continue for other traffic. It is the recommended approach for internal domains that have their own CA or for applications with certificate pinning that cannot tolerate interception.

Why this answer

Adding internal.company.com to the SSL/SSH inspection exemption list tells the FortiGate to bypass deep inspection for that specific site, allowing the internal CA certificate to be used without triggering a certificate error. This avoids the error while keeping deep inspection enabled for all other traffic, which is the administrator's goal.

Exam trap

The trap here is that candidates may think disabling certificate validation (Option C) is a quick fix, but that compromises security and is not the intended method to handle trusted internal sites; the correct approach is to use the exemption list to selectively bypass inspection.

How to eliminate wrong answers

Option A is wrong because replacing the CA certificate with a self-signed one would still cause certificate errors for clients that do not trust the self-signed CA, and it does not address the root cause of the mismatch between the internal site's certificate and the CA used for deep inspection. Option B is wrong because certificate inspection only examines the certificate metadata without decrypting traffic, which would not resolve the certificate error and would lose the security benefits of deep inspection. Option C is wrong because disabling certificate validation in the deep inspection profile would bypass all certificate checks, making the system vulnerable to man-in-the-middle attacks and defeating the purpose of deep inspection.

Full explanation →

230

MCQmedium

An administrator has configured the policy shown in the exhibit. Traffic to the web server at 10.0.1.10 over HTTPS is allowed, but users complain that they cannot access the web server's login page. The IPS sensor 'High_Security_Sensor' has a signature that blocks SQL injection attempts. The application list 'Block_Social_Media' blocks Facebook and Twitter. What is the most likely cause of the issue?

A.The IPS sensor is blocking the login page due to a false positive.

B.The firewall policy action is set to 'deny' but the exhibit shows 'accept'.

C.The HTTPS service is not correctly defined and blocking the traffic.

D.The application control profile is blocking the web application.

AnswerD

The application control profile is the only profile configured in the policy that can identify and block specific web applications by their signatures, even when the underlying HTTP/HTTPS service is valid. When a user attempts to access the login page, the FortiGate can classify the traffic as a known application and apply the profile's 'block' action, denying the request. This is a common cause of access failure when the base policy action is accept and HTTPS is correctly defined.

Why this answer

The policy explicitly allows HTTPS traffic to 10.0.1.10, but the application control profile 'Block_Social_Media' is applied. This profile blocks Facebook and Twitter, which are web-based applications. If the web server's login page is served over HTTPS and is incorrectly classified by the FortiGate as a social media application (e.g., due to shared CDN or similar traffic patterns), the application control profile will block it, preventing user access despite the firewall policy allowing the service.

Exam trap

The trap here is that candidates assume the IPS sensor is the cause of the block, but the question specifies the IPS sensor only blocks SQL injection attempts, not login pages, while the application control profile explicitly blocks social media applications that could be misclassifying the web server's traffic.

How to eliminate wrong answers

Option A is wrong because the IPS sensor 'High_Security_Sensor' has a signature that blocks SQL injection attempts, not login pages; a false positive for SQL injection would block specific HTTP requests containing malicious patterns, not the entire login page. Option B is wrong because the exhibit shows the policy action as 'accept', and the question states traffic is allowed; a 'deny' action would block all traffic, not just the login page. Option C is wrong because HTTPS is a well-defined service (TCP/443) and the policy explicitly allows it; if the service were misdefined, all HTTPS traffic would be blocked, not just the login page.

Full explanation →

231

MCQmedium

A network administrator notices that traffic from a specific internal host is not being inspected by the application control profile applied to the firewall policy. The policy is configured with proxy-based inspection and the application control profile includes a rule to block 'Facebook'. The administrator confirms the host can still access Facebook. What is the MOST likely cause?

A.The host is accessing Facebook over HTTPS and the policy does not have SSL/TLS deep inspection enabled.

B.The firewall policy is using flow-based inspection instead of proxy-based.

C.The application control profile is configured with 'deep inspection' disabled.

D.The application control profile is applied only to outgoing traffic, but the host is using a proxy.

AnswerA

Application control cannot inspect encrypted application signatures without SSL deep inspection to decrypt the traffic.

Why this answer

The most likely cause is that the host is accessing Facebook over HTTPS, and the firewall policy does not have SSL/TLS deep inspection enabled. Without deep inspection, the firewall cannot decrypt the HTTPS traffic to inspect the application layer payload, so the application control profile cannot identify or block 'Facebook' traffic. Proxy-based inspection requires decryption to match application signatures for encrypted traffic.

Exam trap

The trap here is that candidates may confuse 'application control' with 'web filtering' or assume that proxy-based inspection alone can inspect encrypted traffic, overlooking the requirement for SSL/TLS deep inspection to be explicitly enabled.

How to eliminate wrong answers

Option B is wrong because the question explicitly states the policy is configured with proxy-based inspection, so flow-based inspection is not in use. Option C is wrong because 'deep inspection' in the context of application control profiles refers to SSL/TLS decryption, not a separate toggle; disabling it would prevent inspection of encrypted traffic, but the profile itself does not have a 'deep inspection' setting—this is a misnomer. Option D is wrong because the application control profile is applied to the firewall policy, which inspects traffic regardless of direction; if the host is using a proxy, the firewall would still see the traffic and apply the profile, but the issue is the inability to inspect encrypted traffic without decryption.

Full explanation →

232

MCQeasy

An administrator wants to ensure that traffic to a specific web server always exits through a particular ISP link, regardless of route changes. Which feature should be configured?

A.Equal-cost multi-path (ECMP) routing

B.Policy-based routing (PBR)

C.Static route with higher distance

D.SD-WAN with load balancing

AnswerB

Policy routes allow forwarding decisions based on source/destination, overriding the routing table.

Why this answer

Policy-based routing (PBR) allows you to override the routing table by applying a route map to match traffic (e.g., source/destination IP, port) and explicitly set the next-hop interface or ISP link. This ensures traffic to the specific web server always exits through the designated ISP, regardless of dynamic route changes or the routing table's default behavior.

Exam trap

The trap here is that candidates confuse PBR with static routing or SD-WAN load balancing, thinking that a static route with a higher distance or SD-WAN can force traffic to a specific link, but only PBR provides the granular match-and-set logic to override the routing table for specific traffic flows regardless of route changes.

How to eliminate wrong answers

Option A is wrong because ECMP distributes traffic across multiple equal-cost paths for load balancing, not for pinning traffic to a specific link. Option C is wrong because a static route with a higher distance (administrative distance) acts as a backup route and only takes effect when the primary route is unavailable, not for forcing traffic to a particular link when the primary route is active. Option D is wrong because SD-WAN with load balancing distributes traffic across multiple WAN links based on policies or performance metrics, which does not guarantee that all traffic to a specific web server always uses the same ISP link.

Full explanation →

233

MCQeasy

A FortiGate has been configured with two WAN interfaces (wan1, wan2) in an SD-WAN zone. The administrator wants to ensure that traffic for a specific internal server uses only wan1. What is the most appropriate method?

A.Disable wan2 in the SD-WAN zone

B.Use policy routing with a higher priority for wan1

C.Configure a static route with a higher distance for wan2

D.Create an SD-WAN rule to match the server's traffic and set the preferred member to wan1

AnswerD

Creating an SD-WAN rule that matches the server's traffic (e.g., by destination IP address) and setting the preferred member to wan1 is the correct solution because SD-WAN rules are evaluated after policy routes and allow granular, application-aware egress selection. The preferred member setting ensures that wan1 is used for matching sessions, while other traffic can still be load-balanced or failed over across the WAN interfaces based on SD-WAN health-check and performance SLA. This approach is the recommended, flexible, and maintainable way to steer specific traffic in a Fortinet SD-WAN design.

Why this answer

SD-WAN rules allow granular traffic steering based on application, source, or destination. By creating an SD-WAN rule that matches the traffic destined for the internal server and setting the preferred member to wan1, the FortiGate will use SD-WAN's policy-based routing to ensure that traffic egresses exclusively via wan1, while other traffic can still use both WAN interfaces as per other rules.

Exam trap

The trap here is that candidates often confuse policy routing (Option B) with SD-WAN rules, not realizing that SD-WAN rules are the proper mechanism for per-traffic member selection within an SD-WAN zone, and that policy routing operates at a different layer and can override SD-WAN behavior if not carefully managed.

How to eliminate wrong answers

Option A is wrong because disabling wan2 in the SD-WAN zone removes it from all load-balancing and failover, which is overly broad and not a targeted solution for a single server's traffic. Option B is wrong because policy routing (PBR) operates independently of SD-WAN and can create conflicts; SD-WAN rules are the intended method for per-traffic member selection within an SD-WAN zone. Option C is wrong because configuring a static route with a higher distance for wan2 affects all traffic using that route, not just the specific server's traffic, and static routes do not integrate with SD-WAN's application-aware steering.

Full explanation →

234

MCQmedium

A FortiGate administrator receives reports that some users are receiving spam emails despite an email filter profile being applied to the SMTP traffic. The email filter profile has 'spam' action set to 'discard'. What is the most likely reason spam is still reaching users?

A.The internal email server receives email directly from the internet without passing through the FortiGate

B.The spam dictionary is not updated with latest spam signatures

C.The email filter profile is not configured to scan outbound emails

D.The email filter profile is applied to the wrong policy direction (inbound vs outbound)

AnswerA

If the internal mail server's MX record points to a public IP that is reachable directly from the internet (i.e., not behind the FortiGate), SMTP packets will never traverse the firewall. Since the FortiGate can only inspect traffic that physically passes through its interfaces, the email filter profile—regardless of how it is configured—will never see these messages. This is the definitive root cause: the FortiGate is completely out of the data path for inbound SMTP, so no email filtering can occur.

Why this answer

If the internal email server receives email directly from the internet without passing through the FortiGate, the email filter profile applied to SMTP traffic on the FortiGate will never inspect those messages. The FortiGate can only filter traffic that actually traverses it; any email routed around the FortiGate bypasses all security profiles entirely.

Exam trap

The trap here is that candidates often assume the email filter profile is correctly applied and focus on configuration details (like dictionary updates or policy direction), rather than verifying whether the traffic actually passes through the FortiGate at the network level.

How to eliminate wrong answers

Option B is wrong because the spam action is set to 'discard', which relies on the FortiGate's real-time spam detection (e.g., FortiGuard AntiSpam, heuristics, or RBL checks), not a static dictionary; an outdated dictionary would reduce detection accuracy but would not cause all spam to pass through. Option C is wrong because the issue is about spam reaching users from external sources, not outbound emails; outbound scanning is irrelevant to incoming spam delivery. Option D is wrong because the email filter profile is applied to SMTP traffic, and the direction (inbound vs outbound) is already implied by the traffic flow; if the profile were applied to the wrong direction, it would not inspect the traffic at all, but the question states the profile is applied to SMTP traffic, so the more fundamental issue is that the traffic never reaches the FortiGate.

Full explanation →

235

MCQeasy

A FortiGate administrator needs to ensure that all internal users (10.0.0.0/8) accessing the internet use a single public IP address 203.0.113.10 for source NAT. Which NAT configuration should be used?

A.Create a Central SNAT rule with a Dynamic IP Pool using overload

B.Enable NAT on the outgoing interface policy without an IP pool

C.Create a policy-based NAT rule with fixed port range

D.Configure a VIP with port forwarding

AnswerA

A Central SNAT rule with a Dynamic IP Pool in overload mode references a configured pool of public addresses and applies source network address translation independently of firewall policies. Overload (PAT) creates a unique mapping of internal IP:port to the selected public IP:port, allowing many internal users to share a single public address. This is the appropriate method when the required public IP is not the interface IP and must be shared by all internal clients.

Why this answer

Central SNAT with a Dynamic IP Pool using overload (Port Address Translation) allows all internal users in 10.0.0.0/8 to share a single public IP (203.0.113.10) by dynamically mapping multiple private source IPs and ports to unique source ports on the public IP. This is the standard method for many-to-one NAT, ensuring all outbound internet traffic appears from the same public address.

Exam trap

The trap here is that candidates often confuse enabling NAT on the interface policy (Option B) with using a specific IP pool, not realizing that interface NAT uses the interface's own IP and cannot force a different public address without an explicit IP pool.

How to eliminate wrong answers

Option B is wrong because enabling NAT on the outgoing interface policy without an IP pool uses the interface's own IP address (typically the WAN IP) for source NAT, not a specific public IP like 203.0.113.10, and may not guarantee a single IP if the interface has multiple addresses. Option C is wrong because a policy-based NAT rule with fixed port range would restrict the number of concurrent sessions to the size of the port range, causing connection failures under load, and is not designed for many-to-one overload NAT. Option D is wrong because a VIP with port forwarding is used for inbound destination NAT (port mapping to internal servers), not for outbound source NAT from internal users to the internet.

Full explanation →

236

MCQmedium

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

A.The source interface on the policy is set to the WAN interface instead of the internal interface

B.Central NAT is enabled and overriding the policy-based NAT

C.The policy has a schedule applied that is currently inactive

D.The policy is placed after the implicit deny rule

AnswerA

If the source interface is wrong, the traffic will not match this policy. The administrator may have a different policy (or the implicit allow) allowing the traffic, but the logs show the implicit deny is being hit because the correct policy is not matched.

Why this answer

If the source interface on the firewall policy is set to the WAN interface instead of the internal interface, traffic arriving from the internal network (10.0.0.0/8) on the internal interface will not match that policy. The FortiGate then falls through to the implicit deny policy (ID 0), which logs and drops the session. Since HTTP traffic is still reaching the internet, it suggests that another mechanism (such as a default route or NAT) is allowing the traffic, but the policy matching fails due to the interface mismatch.

Exam trap

The trap here is that candidates assume a policy with correct source/destination addresses will match regardless of the interface setting, but FortiOS strictly enforces interface matching, and a mismatch causes the policy to be ignored, leading to the implicit deny being hit.

How to eliminate wrong answers

Option B is wrong because Central NAT (centralized NAT policies) does not cause the implicit deny policy to be used; it only affects how NAT is applied, not the firewall policy matching itself. Option C is wrong because an inactive schedule would cause the policy to not match, but the logs would show the policy ID of the scheduled policy (not ID 0) if it were present, and the traffic would still be denied by the implicit deny; however, the question states users can browse the web, which would not happen if the only applicable policy had an inactive schedule. Option D is wrong because the implicit deny rule is always the last rule in the policy list; a policy placed after it is impossible in FortiOS, as the implicit deny is a built-in rule that cannot be reordered.

Full explanation →

237

MCQhard

During a firmware upgrade, the admin uploads the image via the GUI and clicks 'Upgrade'. The FortiGate reboots but comes up with the old firmware. What is the MOST likely cause?

A.The firmware image file is corrupted or not compatible with the platform

B.The FortiGate was in HA mode and the peer did not upgrade

C.The admin did not reboot after the upgrade

D.The admin forgot to save the configuration before upgrading

AnswerA

Corrupted or incompatible images cause upgrade failure; the FortiGate reverts to previous firmware.

Why this answer

When a FortiGate reboots after an upgrade but loads the old firmware, the most likely cause is that the uploaded firmware image was corrupted or incompatible with the platform. The FortiGate verifies the image integrity (e.g., checksum) during the upgrade process; if the image fails validation, the system will not commit the new firmware and will fall back to the previous version stored in the secondary boot partition. This ensures the device remains operational even if the upgrade image is invalid.

Exam trap

The trap here is that candidates often assume a failed upgrade is due to a missing reboot or HA misconfiguration, but Fortinet specifically designs the upgrade process to automatically reboot and validate the image, making image corruption or incompatibility the primary cause when the old firmware reappears.

How to eliminate wrong answers

Option B is wrong because in an HA cluster, the upgrade process is coordinated; if the peer does not upgrade, the primary would either fail to upgrade or the cluster would split, but the FortiGate would not reboot to the old firmware on its own—it would typically remain on the new firmware or fail to complete the upgrade. Option C is wrong because the admin explicitly clicked 'Upgrade', which triggers an automatic reboot; no separate manual reboot is required, and the issue is that the device came up with old firmware, not that it didn't reboot. Option D is wrong because configuration is stored separately from firmware; forgetting to save the config does not affect which firmware version loads after reboot—the config is saved automatically before upgrade or can be restored, but it does not cause the old firmware to load.

Full explanation →

238

MCQhard

An administrator notices that a specific application (e.g., Skype) is not being detected by the application control profile. The profile includes the 'Skype' application signature but traffic is passing through without being logged as Skype. What is the most likely reason?

A.The application control profile is set to 'Monitor' mode

B.The traffic is using a non-standard port

C.The application signature is outdated

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

AnswerD

Skype uses encryption. Without deep inspection, FortiGate cannot decrypt the traffic to inspect the application layer.

Why this answer

The most likely reason is that SSL deep inspection is not enabled on the firewall policy. When Skype traffic is encrypted (which is common for modern Skype versions), the FortiGate cannot inspect the payload to match the application signature. Without SSL deep inspection, the firewall sees only encrypted packets and cannot identify the application as Skype, even if the signature is present in the profile.

Exam trap

The trap here is that candidates often assume application control works purely on port numbers or that 'Monitor' mode disables detection, but FortiGate's application control is port-agnostic and requires SSL deep inspection for encrypted traffic to be identified.

How to eliminate wrong answers

Option A is wrong because 'Monitor' mode only logs the traffic without blocking it, but it does not prevent detection; if the signature matches, the traffic would still be logged as Skype. Option B is wrong because application control signatures in FortiGate are designed to detect applications regardless of port, using deep packet inspection (DPI) and behavioral analysis, so non-standard ports do not prevent detection. Option C is wrong because while an outdated signature could miss new versions, the question states the signature is present, and the issue is that traffic passes without being logged, indicating a deeper inspection problem rather than a signature version issue.

Full explanation →

239

MCQmedium

A FortiGate administrator has configured a route-based IPsec VPN. After Phase 2 is up, traffic is not passing. The administrator verifies that the firewall policy allows traffic and the routes are correct. What should the administrator check next?

A.The static route uses the VPN interface as the outgoing interface

B.The remote gateway's IP address is reachable

C.The pre-shared key is correct

D.The Phase 2 proposal includes the correct local and remote subnets

AnswerA

In a route-based VPN, the virtual IPsec interface serves as the tunnel endpoint, and the static route must specify that interface as the outgoing interface for the remote subnet. Without this route, the FortiGate has no entry in its routing table to direct traffic into the IPsec tunnel, even if Phase 1 and Phase 2 SAs are fully established. The route triggers the actual forwarding decision, causing the kernel to encapsulate and encrypt matching traffic over the tunnel.

Why this answer

In a route-based IPsec VPN, traffic is routed to the VPN tunnel interface (e.g., 'to_remote'). Even if firewall policies and static routes exist, the static route must explicitly use the VPN interface as the outgoing interface. If the static route points to a different interface or a next-hop IP instead of the tunnel interface, the kernel will not forward traffic into the IPsec tunnel, causing Phase 2 to be up but no traffic to pass.

This is a common misconfiguration that breaks the route-based VPN model.

Exam trap

The trap here is that candidates assume Phase 2 being up guarantees traffic flow, overlooking that route-based VPNs require the static route to explicitly use the tunnel interface as the outgoing interface, not just any valid next-hop.

How to eliminate wrong answers

Option B is wrong because the remote gateway's IP address being reachable is a prerequisite for Phase 1 (IKE) to establish, not a cause for traffic failure after Phase 2 is up. Option C is wrong because an incorrect pre-shared key would prevent Phase 1 from completing, but the question states Phase 2 is up, meaning Phase 1 and authentication succeeded. Option D is wrong because if the Phase 2 proposal included incorrect local or remote subnets, Phase 2 would not come up; since Phase 2 is up, the proposal is correct, and the issue lies in how traffic is routed to the tunnel.

Full explanation →

240

Multi-Selecthard

A FortiGate administrator is setting up a new FortiGate and needs to integrate it with FortiAnalyzer and FortiManager. Which THREE statements are correct regarding this integration?

Select 3 answers

A.FortiAnalyzer can generate reports based on the logs received from FortiGate.

B.FortiManager can be used to manage multiple FortiGate devices from a central console.

C.FortiAnalyzer can push configuration changes to the FortiGate.

D.FortiGate uses the FGFM protocol to communicate with FortiAnalyzer.

E.FortiAnalyzer can receive logs from the FortiGate for centralized logging and analysis.

AnswersA, B, E

FortiAnalyzer provides reporting capabilities.

Why this answer

FortiAnalyzer is designed to receive logs from FortiGate devices and use them to generate comprehensive reports. The FortiGate sends logs via syslog or the FGFM protocol, and FortiAnalyzer stores them in its SQL database, allowing administrators to create scheduled or on-demand reports for compliance, traffic analysis, and security events.

Exam trap

The trap here is that candidates often confuse the roles of FortiAnalyzer and FortiManager, assuming FortiAnalyzer can manage configurations or that FGFM is used for both, when in fact FGFM is the FortiGate-FortiManager protocol, while FortiAnalyzer uses syslog or FGFM only for log forwarding.

Full explanation →

241

MCQmedium

A FortiGate administrator configures a captive portal on a VDOM to authenticate users connecting to a guest SSID. The authentication method is set to LDAP. Users can reach the captive portal login page, but after entering valid credentials, they receive an authentication failure. The LDAP server is reachable from the FortiGate. What is the MOST likely cause?

A.The user is not a member of the configured user group

B.The captive portal is using HTTP instead of HTTPS

C.The captive portal interface is not in the same VDOM as the LDAP server

D.The LDAP server requires TLS and FortiGate is using plain LDAP

AnswerA

FortiGate uses LDAP for credential validation, but the firewall policy specifies a particular user group that must contain the authenticated account. After the LDAP bind succeeds, FortiGate performs a group lookup against the configured group; if the user is not a member, the captive portal rejects the login even though the password was correct. This is an authorization failure rather than an authentication failure, and it is the classic cause of a captive portal rejecting valid LDAP creds.

Why this answer

The most likely cause is that the user is not a member of the configured user group. In FortiGate, when LDAP authentication is used for a captive portal, the FortiGate first verifies the user's credentials against the LDAP server. Even if the credentials are valid, the FortiGate then checks whether the authenticated user belongs to a specific user group that is permitted to access the captive portal.

If the user is not a member of that group, the authentication fails, even though the LDAP server itself accepts the credentials.

Exam trap

The trap here is that candidates often assume LDAP authentication failure is always due to connectivity or protocol issues (like TLS or HTTP), but FortiGate's group membership enforcement is a distinct step that can cause failure even with valid credentials and a reachable server.

How to eliminate wrong answers

Option B is wrong because using HTTP instead of HTTPS for the captive portal would not cause an authentication failure after valid credentials are entered; it would only expose credentials in transit but not prevent successful authentication. Option C is wrong because the captive portal interface and the LDAP server do not need to be in the same VDOM; the LDAP server is reachable from the FortiGate, and VDOM separation does not affect LDAP authentication as long as routing permits. Option D is wrong because if the LDAP server required TLS and the FortiGate used plain LDAP, the connection would fail entirely, and the user would not even reach the captive portal login page or receive an authentication failure after entering credentials; instead, a timeout or connection error would occur.

Full explanation →

242

MCQeasy

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

A.Certificate inspection decrypts the traffic but does not check the certificate.

B.Deep inspection is less secure than certificate inspection.

C.Certificate inspection only validates the server certificate, while deep inspection decrypts and inspects the entire TLS session content.

D.Both methods provide the same level of inspection.

AnswerC

Certificate inspection validates the server certificate — chain of trust, expiration, and hostname — but passes the TLS session through without decrypting it. Deep inspection (full SSL/TLS inspection) performs a man-in-the-middle: it terminates the client connection, decrypts the session, inspects the contents, then initiates a new TLS connection to the server and re-encrypts the traffic. This allows deep inspection to detect threats inside the payload rather than simply checking the outer certificate.

Why this answer

Certificate inspection only validates the server certificate's authenticity (e.g., checking the certificate chain, expiration, and revocation status) without decrypting the actual TLS session. In contrast, full SSL deep inspection performs a man-in-the-middle decryption by re-encrypting traffic with a FortiGate-generated certificate, allowing the firewall to inspect the entire payload for threats like malware or data leakage. This distinction is critical for understanding how FortiGate applies security profiles to encrypted traffic.

Exam trap

The trap here is that candidates often confuse 'certificate inspection' with 'deep inspection' because both involve SSL/TLS, but certificate inspection never decrypts the payload, making it a common misconception that it provides the same security level.

How to eliminate wrong answers

Option A is wrong because certificate inspection does not decrypt the traffic; it only examines the certificate metadata during the TLS handshake. Option B is wrong because deep inspection is more secure than certificate inspection, as it provides full visibility into encrypted content, whereas certificate inspection leaves the payload encrypted and unexamined. Option D is wrong because the two methods offer fundamentally different levels of inspection: certificate inspection is lightweight and does not decrypt, while deep inspection fully decrypts and inspects the session.

Full explanation →

243

MCQmedium

A FortiGate is configured with two ISPs (WAN1 and WAN2) and uses SD-WAN for load balancing. The administrator notices that traffic to a critical SaaS application is being sent over the slower link. What should the administrator do to ensure this traffic uses the faster link?

A.Create an SD-WAN rule to match the SaaS application's destination and set preferred member to the faster link.

B.Remove the slower link from the SD-WAN interface.

C.Increase the bandwidth on the slower link.

D.Configure policy-based routing for the SaaS application.

AnswerA

An SD-WAN rule configured with an application match for the SaaS traffic and a preferred member set to the faster link is the correct approach because SD-WAN rules can steer traffic based on Layer 7 application signatures and dynamic link performance metrics. The preferred member acts as a tie-breaker, forcing the traffic to use the specified interface as long as it meets the SD-WAN health-check SLA (latency, jitter, packet loss), while still allowing automatic failover to the backup link if the preferred link degrades. This preserves redundancy and ensures the SaaS application consistently uses the best-performing path.

Why this answer

SD-WAN rules allow you to define traffic steering policies based on application or destination, and setting a preferred member explicitly directs matching traffic to the faster link. This overrides the default load-balancing algorithm, ensuring critical SaaS traffic uses the optimal path without affecting other traffic.

Exam trap

The trap here is that candidates often confuse SD-WAN rules with policy-based routing, thinking PBR can achieve the same result, but PBR lacks SD-WAN's application awareness, SLA monitoring, and seamless failover integration.

How to eliminate wrong answers

Option B is wrong because removing the slower link from the SD-WAN interface would eliminate redundancy and failover capability, not solve the traffic steering issue. Option C is wrong because increasing bandwidth on the slower link does not change the SD-WAN load-balancing decision; the traffic would still be sent to that link based on the current algorithm. Option D is wrong because policy-based routing (PBR) is a static routing mechanism that does not integrate with SD-WAN's dynamic path selection, performance SLA monitoring, or application-based steering, and it can conflict with SD-WAN rules.

Full explanation →

244

Multi-Selecthard

A company has multiple branch offices connected via IPsec VPN in a hub-and-spoke topology. They want to enable direct communication between branch offices without routing traffic through the hub. Which THREE configurations are required on the hub FortiGate? (Choose three.)

Select 3 answers

A.Enable 'forward traffic' in Phase 1 settings

B.Static routes for each branch's subnet pointing to the respective VPN interface

C.Phase 2 selectors that include both branch subnets in one proposal

D.Disable anti-replay on all tunnels

E.A firewall policy allowing traffic between the VPN interfaces

AnswersB, C, E

The hub needs routes to forward traffic between spokes.

Why this answer

Static routes for each branch's subnet pointing to the respective VPN interface are required on the hub FortiGate so that the hub knows how to forward traffic destined for one branch's subnet out the correct IPsec tunnel to the other branch. Without these routes, the hub would have no path to the remote branch subnets and would drop the traffic, preventing direct branch-to-branch communication.

Exam trap

The trap here is that candidates often think only firewall policies are needed, forgetting that without static routes and proper Phase 2 selectors, the hub cannot route or encrypt traffic between branches, even with permissive policies.

Full explanation →

245

MCQmedium

A network administrator needs to configure a FortiGate to allow administrative access from a specific management subnet only. Which configuration step should be taken?

A.Create a local-in policy to permit traffic from the management subnet.

B.Disable administrative access on all interfaces except the management interface.

C.Configure an inbound firewall policy allowing HTTPS from the management subnet to the FortiGate's interface IP.

D.Under system > admin > settings, restrict administrative access to trusted hosts.

AnswerD

Why this answer

The 'Trusted Hosts' feature under System > Admin > Settings allows you to restrict administrative access (HTTPS, SSH, Telnet, etc.) to specific source IP addresses or subnets. This is the intended method for limiting management access to a management subnet without affecting other traffic or interface configurations.

Exam trap

The trap here is that candidates often confuse local-in policies with trusted hosts, thinking that a local-in policy is the primary method for restricting management access, when in fact trusted hosts is the simpler and correct approach for source-based restriction.

How to eliminate wrong answers

Option A is wrong because a local-in policy filters traffic destined to the FortiGate itself, but it is typically used for advanced traffic shaping or rate limiting, not for restricting administrative access based on source subnet; using it for this purpose would be overly complex and not the standard practice. Option B is wrong because disabling administrative access on all interfaces except the management interface does not restrict access by source IP; it only limits which interfaces can be used for management, but any host on the management subnet could still access the FortiGate from that interface. Option C is wrong because an inbound firewall policy controls traffic passing through the FortiGate (forward traffic), not traffic destined to the FortiGate itself (local-in traffic); administrative access is governed by local-in policies or trusted hosts, not by standard firewall policies.

Full explanation →

246

MCQhard

A FortiGate admin configures a firewall policy to allow outbound HTTP traffic and applies a web filter profile. The admin notices that some users can access a known malicious URL while others are blocked. All users are in the same source subnet (10.0.1.0/24). What is the MOST likely cause of this inconsistent behavior?

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

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

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

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

AnswerD

This is the correct answer because FortiGate firewall policies are matched in order of policy ID (and any explicit sequencing), and the first matching policy is enforced. If a higher-priority policy (lower policy ID) matches certain users' traffic (e.g., based on source IP, user group, or interface) and that policy lacks a web filter profile, those users bypass the intended filtering entirely, while others match the intended lower-priority policy that has the restrictive web filter profile.

Why this answer

When multiple firewall policies match traffic from the same source subnet, FortiGate uses the first matching policy in order (lowest policy ID). If a higher-priority policy with a different web filter profile matches some users' traffic (e.g., based on source port or application), those users will have different filtering behavior. This is a classic policy ordering issue where the intended web filter profile is not applied consistently to all users in the same subnet.

Exam trap

The trap here is that candidates assume all traffic from the same subnet is treated identically, overlooking that FortiGate policy matching is first-match and can differentiate based on other attributes like source port or user identity, leading to inconsistent profile application.

How to eliminate wrong answers

Option A is wrong because FortiGate does not use an external proxy server for web filtering by default; it uses local proxy-based inspection or flow-based inspection, and caching is not a factor in inconsistent web filter results. Option B is wrong because FortiGuard ratings are consistent per URL and do not vary per user; if the rating is inconsistent, it would affect all users equally, not selectively. Option C is wrong because FQDN resolution in firewall policies is performed by the FortiGate itself, not per user; DNS load balancing would return different IPs to the FortiGate, but the FortiGate resolves the FQDN once and uses that single IP for policy matching, so it cannot cause per-user differences.

Full explanation →

247

MCQmedium

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

A.The URL filter requires deep inspection to be enabled

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

248

MCQmedium

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

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

B.Disable the signature in the IPS sensor configuration.

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

249

Multi-Selectmedium

A FortiGate administrator needs to configure NTP to ensure accurate time on the device. Which two steps are required? (Choose two.)

Select 2 answers

A.Enable the 'Sync on Save' option

B.Specify at least one NTP server address

C.Enable NTP under System > Settings

D.Configure a firewall policy to allow NTP traffic (UDP 123)

E.Set the time zone to the local time zone

AnswersB, C

At least one server is required for synchronization.

Why this answer

To configure NTP on a FortiGate, you must enable the NTP service under System > Settings (option C) and specify at least one NTP server address (option B) so the device can synchronize its clock. Without enabling the service, the NTP client process does not run, and without a server address, there is no source to query. Option A (Sync on Save) is unrelated to NTP; it refers to configuration changes.

Option D (firewall policy) is not required because the FortiGate's NTP client uses the management interface and bypasses regular firewall policies. Option E (set time zone) is not a required step for NTP synchronization, though it may be configured separately.

Exam trap

The trap is that candidates may think a firewall policy is necessary for NTP traffic, but FortiGate's own NTP client uses the management interface and does not require a policy. Additionally, some may confuse 'Sync on Save' with NTP, but that option is related to configuration changes, not time synchronization.

Full explanation →

250

MCQhard

An administrator wants to inspect SSL traffic to a specific finance application that uses a custom port (9443) and a self-signed certificate. Which configuration is required?

A.Configure certificate inspection on the policy.

B.Disable SSL inspection for that application.

C.Use deep inspection and add the application's self-signed certificate to the FortiGate's trusted CA list.

D.Use flow-based inspection with certificate inspection.

AnswerC

Deep inspection decrypts and re-encrypts; trusted CA list allows self-signed certs.

Why this answer

Deep inspection is required to decrypt and inspect SSL traffic using a self-signed certificate on a non-standard port. The FortiGate must trust the application's self-signed certificate by adding it to the trusted CA list; otherwise, the deep inspection proxy will fail to validate the certificate and drop the connection. Certificate inspection (Option A) only checks the certificate metadata without decrypting the payload, so it cannot inspect the actual application traffic.

Exam trap

The trap here is that candidates often confuse certificate inspection with deep inspection, assuming certificate inspection can decrypt traffic, when in fact only deep inspection performs full decryption and is required for self-signed certificates on non-standard ports.

How to eliminate wrong answers

Option A is wrong because certificate inspection only validates the certificate chain and does not decrypt the SSL payload, so it cannot inspect the content of the finance application traffic. Option B is wrong because disabling SSL inspection would allow unencrypted traffic to pass without any inspection, defeating the administrator's goal of inspecting SSL traffic. Option D is wrong because flow-based inspection with certificate inspection still does not decrypt the traffic; deep inspection (proxy-based) is required to decrypt and inspect traffic with a self-signed certificate.

Full explanation →

251

Multi-Selectmedium

An organization wants to implement data leak prevention (DLP) to detect when credit card numbers are sent via email (SMTP) and webmail (HTTPS). The FortiGate is using proxy-based inspection. Which THREE configurations are necessary? (Choose three.)

Select 3 answers

A.Set the inspection mode to flow-based for better performance.

B.Configure the antivirus profile to scan email attachments.

C.Create a DLP sensor with a rule to match credit card patterns.

D.Apply the DLP sensor to a firewall policy that handles SMTP and HTTPS traffic.

E.Enable SSL/TLS deep inspection on the firewall policy to inspect HTTPS.

AnswersC, D, E

The DLP sensor defines what to detect.

Why this answer

A DLP sensor is the FortiGate component that defines the data patterns to detect, such as credit card numbers. The sensor must be configured with a rule that uses a predefined or custom pattern to match the sensitive data.

Exam trap

The trap here is that candidates often confuse antivirus profiles with DLP sensors, thinking antivirus can detect data patterns, or they assume flow-based inspection is required for performance, ignoring that proxy-based inspection is necessary for DLP to function on encrypted traffic.

Full explanation →

252

MCQhard

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

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

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

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

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

AnswerB

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

253

MCQeasy

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

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

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

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

D.Policies are evaluated randomly to balance load

AnswerA

FortiGate firewall policies are evaluated sequentially from the top of the policy list. The first policy whose source, destination, service, and other matching criteria align with the session's attributes is selected and enforced. Because evaluation stops at the first match, placing more specific rules above broader ones is critical for proper traffic control.

Why this answer

FortiGate uses a top-down sequential search for policy matching. When a packet arrives, the firewall starts at the top of the policy list and evaluates each policy in order until it finds one where all configured criteria (source, destination, service, schedule, etc.) match. The first matching policy is then applied, and no further policies are checked.

This is the fundamental behavior of FortiGate's firewall policy lookup.

Exam trap

The trap here is that candidates often confuse FortiGate's sequential top-down evaluation with other firewall platforms (like Cisco ASA) that use a priority-based or implicit-rule model, leading them to incorrectly select Option B or C.

How to eliminate wrong answers

Option B is wrong because FortiGate does not assign a numeric priority to each policy; the order in the policy list (sequence number) determines the evaluation order, not a separate priority field. Option C is wrong because FortiGate evaluates policies from top to bottom, not bottom to top; the last matching policy would never be used unless it is the first match from the top. Option D is wrong because FortiGate does not use random selection for policy matching; it strictly follows the sequential top-down order to ensure deterministic and predictable traffic handling.

Full explanation →

254

MCQmedium

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

A.The web filter profile has an incorrect action configured

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

C.The FortiGuard web filtering license has expired

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

AnswerD

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

255

MCQeasy

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

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

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

C.A method to group multiple firewall policies

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

AnswerA

VIP maps external (public) addresses to internal (private) destinations, enabling inbound access.

Why this answer

A Virtual IP (VIP) in FortiGate is used for Destination NAT (DNAT), translating an incoming public IP address and port to a private IP address and port. This allows external hosts to access internal servers (e.g., web servers) using a public IP, while the server remains on a private RFC 1918 address. The VIP object is referenced in a firewall policy to permit the inbound traffic and perform the translation.

Exam trap

The trap here is confusing Virtual IP (Destination NAT) with IP Pool (Source NAT), as both involve address translation but serve opposite traffic directions; candidates often pick Option B thinking VIP is for outbound translation.

How to eliminate wrong answers

Option B is wrong because it describes Source NAT (SNAT) or IP Pool, not a Virtual IP; SNAT translates private source IPs to a public IP for outbound traffic. Option C is wrong because grouping multiple firewall policies is done using policy packages or policy groups, not a Virtual IP. Option D is wrong because load balancing traffic across multiple WAN interfaces is achieved using SD-WAN or ECMP routing, not a Virtual IP; VIPs can be used for server load balancing (SLB) but not for balancing across WAN interfaces.

Full explanation →

256

MCQeasy

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

A.Certificate inspection decrypts traffic; deep inspection does not

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

C.Deep inspection is faster than certificate inspection

D.Both provide the same level of security

AnswerB

Certificate inspection examines the certificate for validity, while deep inspection performs a man-in-the-middle decryption.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

257

MCQhard

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

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

B.IPS profile to block file uploads to cloud services

C.DNS filter to block Google Drive domain

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

AnswerA

Application control can identify and block Google Drive traffic even over HTTPS, but only if deep inspection decrypts the traffic to read application signatures.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

258

MCQhard

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

259

MCQhard

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

260

MCQhard

An administrator configures a firewall policy with a schedule object that is set to 'Available: Mon-Fri 09:00-17:00'. At 10:00 AM on Saturday, users report they cannot access the resource. The administrator checks the policy list and sees the policy is enabled. What is the MOST likely reason?

A.The FortiGate's system time is incorrect

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

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

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

AnswerD

The schedule object defined as 'Mon-Fri 09:00-17:00' explicitly restricts allowed days to Monday through Friday. On Saturday, the current time falls outside the schedule's active period, so the policy's schedule condition is not met. Consequently, the FortiGate skips this policy and evaluates subsequent policies, eventually hitting the implicit deny rule that drops the traffic. This is a standard behavior: a firewall policy with a time-based schedule is inactive outside its defined window.

Why this answer

The schedule object is configured to allow traffic only from Monday to Friday, 09:00-17:00. Since Saturday is outside this range, the firewall policy will deny or not match the traffic, even though the policy is enabled. This is the most direct and likely reason for the access failure.

Exam trap

The trap here is that candidates may overlook the schedule's day-of-week restriction and assume the policy is simply 'enabled' means it should work, failing to recognize that a schedule object can limit traffic to specific days and times, making the policy inactive outside those windows.

How to eliminate wrong answers

Option A is wrong because an incorrect system time would affect all schedule-based policies, but the issue is specifically tied to the day of the week (Saturday), not a time drift; moreover, the administrator would likely notice other time-related anomalies. Option B is wrong because a deny policy with higher priority would block traffic regardless of the schedule, but the question states the policy is enabled and the schedule is the only configured restriction; there is no indication of a conflicting deny rule. Option C is wrong because the schedule object is correctly applied to the policy (the administrator sees the policy in the list with the schedule), and the issue is that the schedule itself does not include Saturday, not that it is misapplied.

Full explanation →

261

MCQmedium

A FortiGate administrator is configuring IPsec VPN between two sites. The Phase 1 negotiation fails with the error 'no proposal chosen'. Which two settings must match on both VPN peers?

A.Pre-shared key and local ID

B.Dead peer detection interval and retry count

C.Remote gateway IP and Phase 2 selectors

D.Encryption algorithm and authentication algorithm

AnswerD

The "no proposal chosen" error is FortiGate's way of reporting that the IKE Phase 1 SA proposal could not be matched with the remote peer. The proposal is constructed from the encryption algorithm (e.g., AES256-GCM, AES256-CBC), the authentication/integrity algorithm (e.g., SHA-256, SHA-1), the Diffie-Hellman group, and in some cases the pseudo-random function (PRF). If any of these parameters differ between peers, the IKE SA negotiation fails with "no proposal chosen" during the SA payload exchange. Correcting the encryption and authentication algorithms so that both peers share at least one common proposal is the direct and expected remedy for this exact error.

Why this answer

The 'no proposal chosen' error during IPsec Phase 1 negotiation indicates that the two VPN peers cannot agree on a common set of security parameters for the IKE (Internet Key Exchange) SA. The encryption algorithm (e.g., AES-256, 3DES) and authentication algorithm (e.g., SHA-256, MD5) are mandatory components of the Phase 1 proposal; if they do not match on both peers, the IKE negotiation fails immediately.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 parameters, mistakenly thinking that mismatched Phase 2 selectors (option C) or pre-shared keys (option A) cause the 'no proposal chosen' error, when in fact it is specifically a Phase 1 proposal mismatch involving encryption and authentication algorithms.

How to eliminate wrong answers

Option A is wrong because the pre-shared key is used for authentication in Phase 1, but a mismatch would typically cause an authentication failure (e.g., 'invalid cookie' or 'authentication failed'), not a 'no proposal chosen' error; the local ID is optional and only matters when using aggressive mode or ID-based authentication. Option B is wrong because dead peer detection (DPD) interval and retry count are keepalive mechanisms that operate after the tunnel is established; they do not affect the initial proposal negotiation. Option C is wrong because the remote gateway IP is used to establish the connection endpoint, but a mismatch would prevent the peers from reaching each other, not cause a proposal mismatch; Phase 2 selectors (traffic selectors) are negotiated after Phase 1 is complete, so they are irrelevant to the Phase 1 'no proposal chosen' error.

Full explanation →

262

MCQmedium

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

A.Disable certificate validation in the SSL inspection profile

B.Create a separate firewall policy without SSL inspection

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

263

MCQhard

A FortiGate has policy-based NAT enabled. The admin wants to translate the source IP of internal users to the interface IP for internet traffic. The firewall policy has NAT enabled. However, traffic from the internal network to the internet shows the original source IP instead of the interface IP. What is the MOST likely reason?

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

B.The destination is a VIP that disables NAT

C.The NGFW mode is set to profile-based

D.The policy is configured in proxy inspection mode

AnswerA

Central NAT is enabled and overrides the per-policy NAT setting. When central NAT is enabled in FortiOS, the per-policy NAT flag is ignored, and NAT is controlled exclusively by central NAT rules (source IP pools and destination VIPs). This means even if the policy shows NAT as enabled, the actual address translation is determined by the central NAT table, not the policy. Therefore, the admin would need to check the central NAT configuration to verify why NAT is not taking effect.

Why this answer

When policy-based NAT is enabled, the per-policy NAT setting should translate the source IP to the interface IP. However, if Central NAT is also enabled, it takes precedence and overrides the per-policy NAT configuration. Central NAT uses its own rules (e.g., IP pools) and can prevent the interface IP translation from being applied, leaving the original source IP unchanged.

Exam trap

The trap here is that candidates assume per-policy NAT always works when enabled, but FortiGate's Central NAT feature can silently override it, making it appear as if NAT is broken.

How to eliminate wrong answers

Option B is wrong because a VIP (Virtual IP) is used for destination NAT (port forwarding) and does not disable source NAT; in fact, VIPs often require source NAT to be enabled for return traffic. Option C is wrong because NGFW mode (profile-based vs. policy-based) affects inspection features like IPS and application control, not the NAT operation or precedence. Option D is wrong because proxy inspection mode changes how traffic is inspected (e.g., SSL inspection) but does not disable or override the per-policy NAT setting.

Full explanation →

264

MCQmedium

An administrator configures a firewall policy with a schedule that allows traffic only during business hours (Monday to Friday, 09:00-18:00). At 17:55 on a Friday, a user establishes an SSH session that is still active at 18:05. What happens to the session when the schedule ends?

A.The session is immediately terminated at 18:00

B.The session continues until it ends naturally

C.The session is allowed but new sessions are blocked

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

AnswerB

FortiGate does not interrupt established sessions when a schedule ends; the session remains active until it closes.

Why this answer

FortiGate firewall policies control the establishment of new sessions based on the schedule. Once a session is established, it is tracked in the session table and continues to be forwarded even if the schedule ends, until the session naturally terminates or times out. This behavior ensures that ongoing traffic is not abruptly disrupted when a schedule expires.

Exam trap

The trap here is that candidates assume schedules enforce a hard cutoff on all traffic, but FortiGate only applies schedules to new session initiation, not to already established sessions.

How to eliminate wrong answers

Option A is wrong because FortiGate does not immediately terminate active sessions when a schedule ends; it only blocks new session establishments. Option C is wrong because it describes the actual behavior (new sessions blocked, existing sessions continue), but the question asks what happens to the already active session, which continues until it ends naturally, not just 'allowed'—the session is not simply allowed; it continues without interruption. Option D is wrong because there is no 60-second grace period for session termination after a schedule ends; sessions persist based on their own idle timeout or until they finish naturally.

Full explanation →

265

MCQeasy

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

A.Encode traffic to prevent attacks

B.Parse and normalize protocol traffic to improve detection accuracy

C.Rate-limit traffic based on protocol

D.Decrypt SSL traffic for inspection

AnswerB

Decoders help identify protocol-specific attacks.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

266

MCQmedium

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

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

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

C.Ensure the users have the correct client software installed

D.Check the FortiGate's DNS settings

AnswerA

Correct. The firewall policy must explicitly permit traffic from the SSL VPN zone to the internal zone.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

267

MCQeasy

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

A.Log and drop

B.Redirect to authentication

C.Accept

D.Deny

AnswerD

Traffic that does not match any policy is implicitly denied.

Why this answer

FortiGate firewall policies operate on a 'first-match' basis, and if no policy matches the traffic, the default action is to deny the traffic. This is a fundamental security principle to ensure that only explicitly permitted traffic is allowed through the firewall. The implicit deny rule is automatically applied at the end of the policy list and cannot be removed or modified.

Exam trap

The trap here is that candidates may confuse the default action of a firewall with the default action of a router (which forwards traffic) or assume that FortiGate logs all denied traffic by default, but neither is true; the implicit deny is silent unless explicitly configured to log.

How to eliminate wrong answers

Option A is wrong because 'Log and drop' is not a default action; logging is only performed if a policy explicitly enables logging, and the implicit deny does not generate logs by default. Option B is wrong because 'Redirect to authentication' is a feature of authentication policies or captive portal configurations, not the default action for unmatched traffic. Option C is wrong because 'Accept' would violate the security model of a firewall, which must block all traffic unless explicitly allowed; accepting unmatched traffic would create a security vulnerability.

Full explanation →

268

MCQmedium

An administrator has configured an SSL VPN. Remote users can connect and authenticate but cannot access internal resources. The SSL VPN policy allows all traffic from the SSL VPN interface to internal servers. What is the MOST likely missing configuration?

A.The remote user's client does not support split tunneling

B.The firewall policy allowing traffic from SSL VPN interface to internal network is missing

C.The authentication timeout is too short

D.The SSL VPN portal does not have the correct bookmark configured

AnswerB

Even with SSL VPN configured, traffic must be allowed by a firewall policy from the SSL VPN interface to the destination.

Why this answer

The most likely missing configuration is a firewall policy that explicitly permits traffic from the SSL VPN interface (e.g., ssl.root) to the internal network. Even with an SSL VPN policy allowing traffic, FortiGate requires a separate firewall policy to control and allow the decrypted traffic to reach internal resources. Without this policy, packets are dropped by the implicit deny rule.

Exam trap

The trap here is that candidates often confuse the SSL VPN policy (which controls authentication and portal access) with the firewall policy (which controls traffic forwarding), assuming the SSL VPN policy alone is sufficient to allow traffic to internal resources.

How to eliminate wrong answers

Option A is wrong because split tunneling controls whether client traffic goes through the VPN tunnel or directly to the internet; it does not affect the ability to access internal resources once connected. Option C is wrong because an authentication timeout that is too short would cause the user to be disconnected or re-authenticated, not prevent access to internal resources while still being connected. Option D is wrong because bookmarks are used in web-mode SSL VPN to provide easy links to specific web applications; they are not required for tunnel-mode access to internal resources.

Full explanation →

269

MCQmedium

A network administrator notices that after configuring a new static route on a FortiGate, traffic to a remote subnet is still being forwarded via the default route. The administrator confirms the static route is present in the routing table with a lower distance than the default route. What is the MOST likely cause?

A.The static route is disabled by a firewall policy.

B.The static route is configured with a higher priority than the default route.

C.The static route's destination subnet overlaps with a directly connected subnet.

D.The static route's gateway is not reachable via any interface.

AnswerD

If the next-hop gateway is unreachable (no ARP entry or interface down), the route will not be installed in the routing table, and traffic will use the default route.

Why this answer

If the gateway specified in the static route is not reachable via any interface (e.g., the next-hop IP is not on a directly connected subnet or there is no ARP resolution), FortiGate will not install the route in the forwarding information base (FIB). The route may appear in the routing table but will be marked as inactive, causing traffic to still use the default route with a higher distance. FortiGate requires the next-hop to be reachable on a directly connected interface for the static route to be active.

Exam trap

The trap here is that candidates assume a static route with a lower administrative distance will always override the default route, but they overlook the critical requirement that the next-hop must be directly reachable for the route to be active in FortiGate's routing table.

How to eliminate wrong answers

Option A is wrong because firewall policies do not disable static routes; they control traffic flow based on source/destination, not route activation. Option B is wrong because 'priority' in FortiGate is synonymous with administrative distance, and the question states the static route has a lower distance (higher priority) than the default route, so this would not cause the issue. Option C is wrong because overlapping with a directly connected subnet would cause the static route to be ignored only if the destination is more specific; however, the question states the traffic is still using the default route, not the directly connected route, so this is not the cause.

Full explanation →

270

Multi-Selectmedium

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

Select 3 answers

A.Security level (authPriv or authNoPriv)

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

C.SNMP view definition for the user

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

E.SNMP user with username and authentication password

AnswersA, B, E

Security level defines whether authentication and privacy are used.

Why this answer

SNMPv3 requires a security level to define whether authentication and encryption are used. The security level (authPriv or authNoPriv) determines the operational mode for the user, making it a mandatory configuration element. Without specifying the security level, the FortiGate cannot enforce the appropriate authentication and privacy policies for SNMPv3 communications.

Exam trap

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

Full explanation →

271

MCQhard

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

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

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

C.PBR is not supported on FortiGate.

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

AnswerA

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

272

MCQmedium

A network administrator creates a firewall policy allowing HTTP traffic from the internal network to a web server in the DMZ. Users report that they cannot access the web server. The administrator runs 'diagnose firewall iprope list' and sees the policy is present. What is the MOST likely cause of the issue?

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

B.The firewall policy has an incorrect source interface

C.The policy is disabled

D.The web server is not responding to HTTP requests

AnswerA

In FortiGate, policy matching uses a first-match model: the firewall processes rules in ascending policy ID order and stops at the first rule whose source, destination, and service match the session. If a deny policy with a lower ID (i.e., positioned earlier in the policy list) matches the same HTTP traffic as the intended allow policy, that deny will drop the packets and the allow policy will never be reached. This shadowing behavior is the most probable cause, and it can be confirmed by placing the allow rule above the deny or by comparing policy IDs in the `get firewall policy` output.

Why this answer

The 'diagnose firewall iprope list' command confirms the allow policy exists in the FortiGate's kernel policy list, meaning it is present and enabled. However, FortiGate evaluates policies in sequential order based on policy ID (lowest first), so a deny policy with a lower ID that matches the same traffic (e.g., from internal to DMZ) will be hit first, blocking the HTTP request before the allow policy can be evaluated. This is the most likely cause because the policy is present but not being matched due to ordering.

Exam trap

The trap here is that candidates assume 'policy is present' means it is working, but FortiGate's policy order (lowest ID first) means a lower-ID deny policy can override a higher-ID allow policy even if both match the same traffic.

How to eliminate wrong answers

Option B is wrong because an incorrect source interface would cause the policy not to match at all, but the 'diagnose firewall iprope list' output would not show the policy as present for that traffic flow; the administrator would see no matching entry. Option C is wrong because a disabled policy would not appear in the 'diagnose firewall iprope list' output at all, yet the administrator sees it present. Option D is wrong because the web server not responding would result in a timeout or connection reset, but the firewall would still allow the traffic (the policy would match), and the issue would be reported differently; the 'diagnose firewall iprope list' check would not be the first troubleshooting step for a server-side problem.

Full explanation →

273

MCQmedium

A network administrator notices that HTTP traffic to a specific website is being blocked by the web filter profile, but the website is categorized as 'General – Personal' in FortiGuard, which is allowed. What could cause this block?

A.The web filter profile has an incorrect FortiGuard category override

B.The antivirus profile is blocking the website

C.A URL filter entry is blocking the specific website

D.DNS filter is blocking the domain

AnswerC

URL filter entries are local, rule-based patterns evaluated before FortiGuard category lookup. If a block entry matches the specific domain or URL, the session is dropped immediately, regardless of the category's default action. This is why a single website can be blocked while other sites in the same FortiGuard category remain accessible, as described in the scenario.

Why this answer

A URL filter entry can explicitly block a specific website regardless of its FortiGuard category. Even if the category 'General – Personal' is allowed in the web filter profile, a more specific URL filter rule with a higher priority (lower order number) can override the category-based action. This is a common scenario where an administrator creates a custom URL block for a particular domain or URL pattern, which takes precedence over the FortiGuard category lookup.

Exam trap

The trap here is that candidates often assume the FortiGuard category is the sole determinant of web access, forgetting that URL filter entries have higher precedence and can block individual sites even when their category is permitted.

How to eliminate wrong answers

Option A is wrong because a FortiGuard category override would change the category assigned to the website, but if the override incorrectly set it to a blocked category, the traffic would be blocked for that reason—however, the question states the category is allowed, so an override would not cause a block unless it changed the category to a blocked one, which is not indicated. Option B is wrong because antivirus profiles inspect file downloads and HTTP content for malware, not the initial HTTP request to a website; they would not block the website itself unless a virus was detected in a downloaded file, which is not mentioned. Option D is wrong because DNS filter blocks domains at the DNS query level, preventing resolution entirely, but the question indicates HTTP traffic is blocked, implying the DNS query succeeded and the TCP connection was attempted, so a DNS filter block would manifest as a DNS resolution failure, not an HTTP block.

Full explanation →

274

MCQeasy

What is the primary difference between flow-based and proxy-based Antivirus inspection on a FortiGate?

A.Flow-based inspection is only available on hardware models with CP8

B.Proxy-based inspection reassembles the file before scanning, while flow-based scans as the file passes through

C.Proxy-based inspection uses fewer resources than flow-based

D.Flow-based inspection supports virus outbreak detection, but proxy-based does not

AnswerB

This is the key architectural difference: proxy mode buffers the whole object, flow mode streams.

Why this answer

The primary difference is that proxy-based antivirus inspection fully reassembles the file in memory before scanning, allowing for more thorough detection of threats like polymorphic viruses and archives. Flow-based inspection scans data as it passes through the FortiGate in a single pass, using pattern matching without full file reassembly, which reduces latency but may miss threats that require file-level analysis.

Exam trap

The trap here is that candidates often assume proxy-based is always more resource-efficient because it is 'thorough,' but in reality, proxy-based consumes more memory and CPU due to file buffering and reassembly, while flow-based is optimized for performance.

How to eliminate wrong answers

Option A is wrong because flow-based inspection is not limited to hardware models with CP8; it is available on all FortiGate models and leverages CP8/CP9 accelerators for performance but does not require them. Option C is wrong because proxy-based inspection typically uses more resources (memory and CPU) due to file reassembly and buffering, while flow-based is designed for lower resource consumption. Option D is wrong because both flow-based and proxy-based inspection support virus outbreak detection through FortiGuard updates; the difference is in the scanning method, not feature support.

Full explanation →

275

MCQmedium

A network administrator is configuring a new FortiGate and needs to ensure that all traffic from the internal network to the internet is source NATed to the public IP address on port1. The default route points to port1. Which configuration step is required to achieve this?

A.Configure a static route to the internet with NAT enabled

B.Enable NAT on the firewall policy from internal to internet

C.Set the interface port1 to NAT mode in its settings

D.Create an IP pool with the public IP and reference it in the policy

AnswerB

In FortiGate, source NAT is performed by enabling the NAT option on the firewall policy that matches the internal-to-internet traffic. This setting causes the FortiGate to masquerade the source IP of each packet with the IP address assigned to the egress interface, which is typically the public IP of the WAN port. This is the standard and correct method for allowing internal users to share a single public IP address when accessing the internet.

Why this answer

Source NAT (SNAT) on a FortiGate is configured at the firewall policy level, not on the interface or via a static route. By enabling NAT on the firewall policy from the internal network to the internet, the FortiGate automatically translates the source IP of traffic egressing port1 to the interface's primary IP address (the public IP). This is the standard method for implementing source NAT in FortiOS, as defined in the FortiGate Administration Guide.

Exam trap

The trap here is that candidates often confuse NAT configuration with interface settings or static routes, mistakenly thinking NAT must be enabled on the egress interface or as part of the route, whereas FortiOS applies NAT exclusively at the firewall policy level.

How to eliminate wrong answers

Option A is wrong because static routes in FortiOS do not have a NAT toggle; NAT is not a property of a route but of a firewall policy. Option C is wrong because interfaces in FortiOS do not have a 'NAT mode' setting; NAT is applied per policy, not per interface. Option D is wrong because an IP pool is only required when you need to translate to a specific IP address that is not the interface IP (e.g., for load balancing or PAT with a pool), but the question states the public IP is on port1, so the default interface NAT (enabled in the policy) suffices without an IP pool.

Full explanation →

276

MCQhard

An administrator configures a VLAN interface on a FortiGate's physical port with the IP 192.168.10.1/24. The VLAN ID is 10. The administrator connects a switch port configured as an access port (untagged) in VLAN 10. The devices on the switch cannot ping the FortiGate's VLAN interface. What is the most likely cause?

A.The switch port should be configured as a trunk port allowing VLAN 10

B.The FortiGate's physical port is not set to the same VLAN ID

C.The FortiGate's administrative access is not enabled on the VLAN interface

D.The FortiGate's VLAN interface is not assigned to any VDOM

AnswerA

The switch port must send tagged frames (trunk) for the FortiGate VLAN interface to recognize them.

Why this answer

The switch port is configured as an access port, which sends frames untagged. However, the FortiGate's VLAN interface expects to receive 802.1Q-tagged frames because the VLAN is defined as a subinterface on the physical port. For the FortiGate to process traffic for VLAN 10, the switch port must be configured as a trunk (or tagged) port that sends frames with the VLAN 10 tag.

An access port strips the tag, so the FortiGate never sees the VLAN 10 traffic.

Exam trap

The trap here is that candidates often confuse access/trunk port behavior with VLAN interface configuration on firewalls, mistakenly thinking an access port is sufficient because the VLAN ID matches, when in fact the FortiGate requires tagged frames for subinterfaces.

How to eliminate wrong answers

Option B is wrong because the FortiGate's physical port does not have a VLAN ID setting; VLANs are defined as subinterfaces, and the VLAN ID is set on the VLAN interface itself, not on the physical port. Option C is wrong because administrative access (e.g., HTTPS, SSH, ping) is a separate setting that controls management protocols, not basic IP connectivity; the devices cannot ping due to a Layer 2 tagging mismatch, not because ping is disabled. Option D is wrong because VDOM assignment is only relevant in multi-tenant or virtualized FortiGate configurations; by default, all interfaces belong to the root VDOM, and the VLAN interface would still be reachable if the tagging were correct.

Full explanation →

277

MCQeasy

What is the primary advantage of using route-based IPsec VPN over policy-based IPsec VPN?

A.Route-based VPN allows the use of dynamic routing protocols over the tunnel

B.Route-based VPN requires fewer firewall policies

C.Route-based VPN is easier to configure for hub-and-spoke

D.Route-based VPN supports higher encryption algorithms

AnswerA

Route-based IPsec VPN creates a virtual tunnel interface, allowing the underlying IPsec connection to participate in dynamic routing protocols such as OSPF, EIGRP, or BGP. This enables automatic route advertisement and convergence, eliminating the need for static proxy-IDs for each destination network, and making large-scale, redundant VPN topologies far more practical to deploy and maintain.

Why this answer

Route-based IPsec VPNs create a virtual tunnel interface (e.g., `tunnel` or `ipsec` interface) that acts as a logical routing endpoint. This allows the tunnel to participate in dynamic routing protocols like OSPF or BGP, enabling automatic route advertisement and failover across the VPN. Policy-based VPNs, in contrast, rely on static security policies that match traffic based on source/destination addresses and ports, which cannot be dynamically updated by routing protocols.

Exam trap

The trap here is that candidates often confuse 'fewer firewall policies' (Option B) as the primary advantage, but the NSE4 exam emphasizes that the key differentiator is the ability to use dynamic routing protocols over the tunnel, which is not possible with policy-based VPNs.

How to eliminate wrong answers

Option B is wrong because route-based VPNs typically require fewer firewall policies only in the sense that traffic is matched via routing rather than per-flow policies, but this is not the primary advantage; the core benefit is dynamic routing. Option C is wrong because while route-based VPNs can simplify hub-and-spoke topologies, this is a consequence of dynamic routing support, not the primary advantage; policy-based VPNs can also be used for hub-and-spoke with manual configuration. Option D is wrong because both route-based and policy-based VPNs support the same encryption algorithms (e.g., AES-256, SHA-256) as defined by the IPsec proposal; the choice of algorithm is independent of the VPN type.

Full explanation →

278

MCQhard

A FortiGate administrator configures a policy-based NAT using an IP pool with type 'Fixed Port Range' for internal users accessing a specific external server. Users report that after some time, they cannot establish new connections to the server. 'diagnose ip pool list' shows many entries with 'used_port=65535'. What is the MOST likely cause?

A.The external server is rate-limiting connections

B.The firewall policy has a timeout setting that is too low

C.The IP pool has run out of IP addresses

D.The fixed port range is too small, causing port exhaustion

AnswerD

Fixed port range NAT assigns a block of ports to each source IP. If the range is small (e.g., 1 port), it fills quickly and blocks new sessions. The 'used_port=65535' indicates the last port in a range is in use.

Why this answer

The 'Fixed Port Range' IP pool type allocates a specific range of ports per IP address for NAT translations. When all ports in the range are exhausted (indicated by 'used_port=65535'), no new connections can be established, causing the reported issue. This is classic port exhaustion, making D correct.

Exam trap

The trap here is that candidates may confuse IP address exhaustion (Option C) with port exhaustion, but the diagnostic output clearly shows IP addresses are still available while ports are maxed out, pointing directly to the fixed port range being too small.

How to eliminate wrong answers

Option A is wrong because the external server rate-limiting would affect all users equally and would not cause the specific symptom of 'used_port=65535' entries in the IP pool list. Option B is wrong because a low firewall policy timeout would cause connections to be dropped prematurely, not prevent new connections from being established due to port exhaustion. Option C is wrong because the 'diagnose ip pool list' output shows many entries with 'used_port=65535', indicating that IP addresses are still available but all ports within the fixed range are in use, not that IP addresses have run out.

Full explanation →

279

MCQhard

An administrator is configuring a VIP to map a public IP to an internal server. The server hosts both HTTP and HTTPS services. The admin creates a VIP with port forwarding for port 80 to internal port 80, and another VIP for port 443 to internal port 443. Both VIPs use the same public IP. Users can access HTTP but not HTTPS. What is the most likely issue?

A.The firewall policy for HTTPS traffic is missing or has incorrect destination

B.The server's HTTPS service is not running

C.VIPs cannot share the same public IP address

D.The HTTPS VIP is configured with the wrong internal port

AnswerA

In FortiGate, VIPs only perform destination NAT; they do not implicitly permit traffic. A firewall policy must explicitly allow HTTPS traffic with the destination set to the VIP object, and the service must include HTTPS (or port 443). If the existing policy only allows HTTP to the same VIP, HTTPS packets are dropped due to no matching policy, so the connection never reaches the server.

Why this answer

The most likely issue is that the firewall policy for HTTPS traffic is missing or has an incorrect destination. Even with a correctly configured VIP, traffic must be allowed by a firewall policy that matches the destination (the VIP's public IP and port 443) and the action must be set to ACCEPT. Without this policy, the FortiGate will drop the HTTPS packets, while HTTP traffic works because its corresponding policy exists.

Exam trap

The trap here is that candidates assume a correctly configured VIP automatically allows traffic, but FortiGate requires an explicit firewall policy to permit the translated traffic, and the exam tests this separation of NAT and policy functions.

How to eliminate wrong answers

Option B is wrong because if the server's HTTPS service were not running, the admin would typically see connection refused or timeout errors, not a complete lack of access; the issue is at the firewall level, not the server. Option C is wrong because FortiGate VIPs can share the same public IP address as long as they use different ports (e.g., 80 and 443), which is a standard port-based VIP configuration. Option D is wrong because the admin explicitly configured the HTTPS VIP with internal port 443, which is correct for HTTPS; if the internal port were wrong, the traffic would reach the server but on the wrong port, causing a different failure mode.

Full explanation →

280

MCQmedium

After upgrading FortiGate firmware from 6.0 to 7.2, an administrator notices that a static route pointing to a next-hop IP 10.0.0.1 is no longer working. The route is present in the configuration but the FortiGate shows it as 'not active'. What is the MOST likely cause?

A.FortiGate now requires a default administrative distance of 10 for static routes

B.The route was deleted during the upgrade and needs to be re-added

C.The next-hop IP is not directly connected to any FortiGate interface

D.The remote gateway is down

AnswerC

FortiGate static routes require the next-hop IP (gateway) to be on a directly connected subnet of the outgoing interface. If the gateway is not directly connected to any FortiGate interface, the route cannot be resolved via ARP or neighbor discovery, so FortiGate marks the route as inactive and does not install it in the forwarding table. This is the most common and specific cause of an inactive static route after a configuration change or upgrade that alters interface IPs or subnet masks.

Why this answer

In FortiOS 7.2, a static route is considered 'active' only if the next-hop IP is reachable via a directly connected interface. If the next-hop IP 10.0.0.1 is not on a directly connected subnet, the route will be present in the configuration but marked as 'not active'. This is a fundamental routing principle: the next hop must be directly reachable (i.e., the router must have an ARP entry for it) for the route to be installed in the routing table.

Exam trap

The trap here is that candidates often assume a static route will be active as long as the configuration is present and the remote gateway is reachable, but FortiGate (and most routers) require the next-hop IP to be directly connected for the route to be installed in the routing table.

How to eliminate wrong answers

Option A is wrong because the default administrative distance for static routes in FortiOS remains 10 (unchanged from 6.0 to 7.2), and administrative distance does not affect whether a route is 'active'—it only influences route selection among multiple routes to the same destination. Option B is wrong because the route is still present in the configuration, so it was not deleted during the upgrade; the issue is that it is not active, not that it is missing. Option D is wrong because the remote gateway being down would cause the route to be present but possibly inactive only if the next hop is directly connected; if the next hop is not directly connected, the route would be inactive regardless of the remote gateway's state.

Full explanation →

281

MCQhard

An admin configures a VIP to map a public IP to an internal server. The firewall policy uses the VIP as the destination. External users can access the server, but the server's logs show the source IP as the FortiGate's internal interface IP instead of the original client IP. Why is this happening?

A.The VIP is configured with port forwarding and the server is expecting a different port

B.The VIP is using a different public IP than expected

C.The firewall policy has NAT enabled, which changes the source IP to the FortiGate's egress interface IP

D.The server's routing is misconfigured and traffic is returning via a different path

AnswerC

When the firewall policy matching the VIP traffic has NAT enabled, FortiGate replaces the original source IP with the IP of the egress interface used to forward the packet. This source NAT (SNAT) hides the client's real address, so the internal server logs show the FortiGate's interface IP as the connection source. This is the standard behavior, explaining why the admin observes the FortiGate IP instead of the client's public IP.

Why this answer

When a firewall policy has NAT enabled (typically 'Enable NAT' or 'Use Outgoing Interface Address'), the FortiGate performs source NAT (SNAT) on the traffic, replacing the original client source IP with the IP of its egress interface (the internal interface in this scenario). This is standard behavior for source NAT, which hides the original client IP from the internal server, causing the server logs to show the FortiGate's internal interface IP instead of the actual client IP.

Exam trap

The trap here is that candidates often assume NAT only applies to outbound traffic, but FortiGate policies apply NAT bidirectionally unless explicitly disabled, causing the source IP to be overwritten even for inbound VIP traffic.

How to eliminate wrong answers

Option A is wrong because port forwarding configuration on the VIP does not affect source IP preservation; it only translates destination ports, and the server expecting a different port would cause connectivity failure, not a source IP mismatch. Option B is wrong because using a different public IP than expected would result in the server not receiving traffic at all or traffic being dropped, not in the server seeing the FortiGate's internal IP as the source. Option D is wrong because misconfigured server routing causing asymmetric return traffic would typically lead to dropped connections or timeouts, not to the server logging the FortiGate's internal IP as the source; the source IP seen by the server is determined by the inbound packet's source address, which is already modified by NAT before the server processes it.

Full explanation →

282

MCQhard

A company uses FortiGate with firewall policies to control access between internal VLANs. Users in VLAN 10 report they can access internet but cannot reach a server in VLAN 20 on port 443. The server is reachable from other VLANs. The administrator checks the firewall policy configuration: there is a policy from VLAN10 to VLAN20 allowing HTTPS, with NAT disabled and logging enabled. The policy has a schedule set to 'Always'. The administrator also checks that there are no overlapping policies. What is the most likely cause?

A.NAT is disabled, so the server cannot send replies back.

B.The policy order is incorrect; a deny policy above is blocking traffic.

C.A security profile applied to the policy is blocking the HTTPS traffic.

D.The schedule is configured incorrectly and the policy is inactive during the current time.

AnswerC

A security profile (e.g., SSL inspection or application control) applied to the firewall policy can intercept HTTPS sessions and enforce actions like blocking based on certificate validation failure, URL category, or application signature. If the server presents an untrusted or expired certificate, the SSL inspection profile may block the HTTPS handshake while allowing other traffic, which matches the symptom of only HTTPS being affected.

Why this answer

Security profiles (such as web filtering, application control, or SSL inspection) applied to a firewall policy can inspect and block HTTPS traffic even when the policy itself allows the service. Since the server is reachable from other VLANs and the policy explicitly permits HTTPS with NAT disabled and logging enabled, the most likely cause is that a security profile is dropping or denying the traffic.

Exam trap

The trap here is that candidates often assume a policy allowing a service with NAT disabled is sufficient for reachability, overlooking that security profiles can independently block traffic at a higher layer, especially for HTTPS where inspection is required.

How to eliminate wrong answers

Option A is wrong because NAT is not required for reachability between internal VLANs; the server can send replies directly to the client's private IP address without NAT. Option B is wrong because the administrator has already confirmed there are no overlapping policies, so a deny policy above cannot be blocking traffic. Option D is wrong because the schedule is set to 'Always', meaning the policy is active at all times, and the users can access the internet, confirming the policy is not inactive.

Full explanation →

Fortinet NSE 4 Network Security Professional NSE4 (NSE4) — Questions 226–282