NSE4 Practice Test 4 — 25 Questions

Question 1

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

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

SSL/TLS deep inspection is not enabled on the firewall policy. HTTPS traffic is encrypted with SSL/TLS, so an antivirus profile cannot inspect the payload unless the firewall can decrypt the traffic. Even with antivirus enabled in the policy, without SSL/TLS deep inspection (also called SSL inspection or HTTPS decryption), FortiGate only sees encrypted packets and cannot scan for malware. Therefore, the most likely reason is that SSL/TLS deep inspection is not enabled on the firewall policy.

Answer

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

Answer

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

Answer

The FortiGuard antivirus subscription has expired

Question 2

A FortiGate administrator is configuring a route-based IPsec VPN between two FortiGate devices. After setting up the tunnel and firewall policies, traffic does not flow. The administrator runs 'diagnose vpn tunnel list' and sees the tunnel is up. 'get router info routing-table all' shows routes on both sides. However, pings from the local network to the remote network fail. What is the MOST likely cause?

Accepted Answer

The firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed. The tunnel is up and routes are present, indicating Phase 1 and Phase 2 negotiations succeeded. The most likely cause is that the firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed. In a route-based VPN, the policy must have the incoming interface as the source (e.g., internal) and the outgoing interface as the destination (e.g., the VPN tunnel interface). Reversing these prevents traffic from being matched, even though the tunnel is established.

Answer

The pre-shared key is incorrect

Answer

The remote FortiGate's static route points to the wrong local subnet

Answer

The Phase 2 proposal uses different encryption algorithms on each side

Question 3

A FortiGate admin creates a new firewall policy with source address object 'Internal_Net' and destination 'All'. After saving, traffic from 'Internal_Net' is not matching the new policy but instead matches an older policy with a broader source. What is the MOST likely cause?

Accepted Answer

The new policy is placed below the older policy in the policy list. A FortiGate firewall evaluates policies sequentially from top to bottom, applying the first match. If the new policy is placed below an older policy with a broader source definition, traffic from 'Internal_Net' will match the older policy first and never reach the new policy. Therefore, option B is the correct answer.

Answer

The source address object 'Internal_Net' has an incorrect subnet mask

Answer

The new policy is disabled

Answer

Traffic shaping is applied to the new policy and is interfering

Question 4

An admin runs the command 'diagnose firewall iprope list 100000' and sees the following output:
id=2000000000 action=deny flag=0x0 src-interface=any dst-interface=any proto=0 src-addr=0.0.0.0-255.255.255.255 dst-addr=0.0.0.0-255.255.255.255
What does this entry represent?

Accepted Answer

The implicit deny policy at the end of the policy list. The output shows an entry with id=2000000000, action=deny, and source/destination addresses covering all possible IPs (0.0.0.0-255.255.255.255). In FortiGate, the implicit deny policy is automatically inserted at the end of the policy list with a high ID (typically 2000000000) and matches any traffic that hasn't been permitted by earlier policies. This is not a user-created policy but the built-in default deny rule.

Answer

A loopback interface policy

Answer

A user-created deny policy that blocks all traffic

Answer

A NAT policy that translates all addresses

Question 5

A FortiGate admin has configured a firewall policy allowing traffic from the internal network (10.0.1.0/24) to the internet (any). Users report that they cannot access a specific website (203.0.113.5). The admin runs 'diagnose firewall fqdn list' and sees that the FQDN object used in a policy above the allow policy resolves to an IP that includes 203.0.113.5. What is the MOST likely cause?

Accepted Answer

The FQDN object resolved to the IP after the policy was created, but the policy lookup uses the cached IP and matches before the allow policy. The FQDN object in a policy above the allow policy resolved to an IP that includes 203.0.113.5. FortiGate performs policy lookup based on cached IP addresses for FQDN objects. Since the FQDN object's cached IP now matches the destination IP of the website, traffic hits the higher-priority policy (which likely denies or otherwise blocks the traffic) before reaching the allow policy. This is why users cannot access the website despite the allow policy existing.

Answer

The destination NAT on the allow policy is misconfigured

Answer

The FortiGate's DNS server is not resolving the FQDN correctly

Answer

The antivirus profile on the allow policy is blocking the website

Question 6

A company requires two-factor authentication for SSL VPN access. They already have an LDAP server for user credentials. Which TWO components are necessary to implement this?

Accepted Answer

FortiToken hardware or mobile tokens. FortiToken hardware or mobile tokens provide the second factor (something you have) required for two-factor authentication. The LDAP server supplies the first factor (something you know) via user credentials. Together, they satisfy the two-factor requirement for SSL VPN access on FortiGate.

Answer

FortiAuthenticator

Answer

RADIUS server

Answer

Certificate Authority (CA)

Question 7

A company is deploying FortiGate for outbound web filtering. They want to block users from accessing social media sites during business hours, but still allow access to cloud-based productivity tools like Office 365. Which approach should the administrator use to meet this requirement?

Accepted Answer

Configure an application control profile with rules to block social media applications and allow Office 365 applications.. Application control is the correct approach because it can identify and control applications like social media and Office 365 based on their unique signatures, regardless of the ports or protocols they use. Unlike URL filtering or port blocking, application control can differentiate between Office 365 traffic and social media traffic even when both use HTTPS on TCP 443, allowing the administrator to block social media while permitting cloud productivity tools.

Answer

Create a firewall policy to block all traffic to ports commonly used by social media (e.g., TCP 443).

Answer

Use a web filter profile to block URLs containing 'facebook' or 'twitter'.

Answer

Implement a DNS filter to block DNS queries for social media domains.

Question 8

An organization has a FortiGate with two internet connections (WAN1 and WAN2). They want traffic to a specific web service (203.0.113.50 port 443) to always exit via WAN2. All other internet traffic should use WAN1. Which feature should be used to achieve this?

Accepted Answer

Policy-based routing (PBR) configured with a policy matching the destination and service. Policy-based routing (PBR) allows you to override the routing table based on match criteria such as source/destination IP, port, or protocol. In this scenario, you create a PBR policy that matches destination 203.0.113.50 and service TCP/443, then sets the next-hop to the WAN2 gateway. This ensures that only traffic to that specific web service exits via WAN2, while all other traffic follows the default route via WAN1.

Answer

Central NAT policy to force the traffic out of WAN2

Answer

Static route with a higher priority for WAN2 to 203.0.113.0/24

Answer

SD-WAN with a strategy of 'Best Quality'

Question 9

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

Accepted Answer

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

Answer

The application control profile is not enabled on the firewall policy

Answer

The application signature for Skype is outdated

Answer

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

Question 10

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?

Accepted Answer

Migrate to certificate-based authentication for Phase 1. 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.

Answer

Switch to aggressive mode with a complex PSK

Answer

Enable XAuth with a second authentication factor using FortiToken

Answer

Increase the PSK length to 64 characters

Question 11

An admin configures a firewall policy to allow SMTP traffic from a mail server to the internet with NAT enabled. External recipients report that the email source IP is the FortiGate's external interface IP. The admin wants the source to be a specific IP from a pool. What should the admin configure?

Accepted Answer

In the firewall policy, enable NAT and specify the IP pool as a fixed port range or overload. The admin wants the source IP of outbound SMTP traffic to be a specific IP from a pool rather than the FortiGate's external interface IP. In a firewall policy with NAT enabled, you can specify an IP pool to override the default source NAT behavior. The IP pool can be configured as Fixed Port Range or Overload (PAT) to translate the mail server's source IP to a desired address from the pool, ensuring external recipients see that specific IP.

Answer

Create a central SNAT policy with the source as the mail server and the translated IP as the desired address

Answer

Use a VIP with port forwarding to translate the source

Answer

Enable NAT on the policy and set the IP pool configuration to use a dynamic IP pool

Question 12

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

Accepted Answer

Route-based VPN allows the use of dynamic routing protocols over the tunnel. 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.

Answer

Route-based VPN requires fewer firewall policies

Answer

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

Answer

Route-based VPN supports higher encryption algorithms

Question 13

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

Accepted Answer

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

Answer

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

Answer

The Phase 1 encryption algorithm is mismatched

Answer

The authentication type requires EAP instead of certificate

Question 14

An administrator needs to configure a hub-and-spoke IPsec VPN topology. Which TWO settings must be configured on the hub FortiGate to allow spokes to communicate with each other through the hub?

Accepted Answer

Set Phase 2 selectors to 0.0.0.0/0 on the hub's side.. In a hub-and-spoke IPsec VPN topology, the hub must have Phase 2 selectors set to 0.0.0.0/0 (any-to-any) so that it can negotiate a single IPsec SA that covers all possible spoke-to-spoke traffic. This allows the hub to decrypt traffic from one spoke and re-encrypt it for another spoke without requiring separate Phase 2 selectors for each spoke pair. Additionally, firewall policies on the hub must explicitly permit traffic between the spoke networks, as the hub acts as a router forwarding inter-spoke traffic.

Answer

Enable NAT on the hub's tunnel interface.

Answer

Configure the hub as a DNS server for the spokes.

Answer

Configure IKEv2 instead of IKEv1 on all tunnels.

Question 15

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?

Accepted Answer

The next-hop IP is not directly connected to any FortiGate interface. 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.

Answer

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

Answer

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

Answer

The remote gateway is down

Question 16

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?

Accepted Answer

The firewall policy has NAT enabled, which changes the source IP to the FortiGate's egress interface IP. 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.

Answer

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

Answer

The VIP is using a different public IP than expected

Answer

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

Question 17

A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. Phase 1 is up, but Phase 2 fails to establish. The debug command 'diagnose vpn ike log' shows: 'no suitable proposal found'. What is the most likely cause?

Accepted Answer

Phase 2 encryption or authentication algorithms do not match on both sides.. The 'no suitable proposal found' error in Phase 2 of an IPsec VPN tunnel indicates that the Phase 2 parameters (encryption algorithm, authentication algorithm, or PFS settings) do not match between the two FortiGate peers. Since Phase 1 is up, the IKE SA is established, meaning pre-shared keys, remote gateway reachability, and basic firewall policies for IKE traffic are correct. The mismatch specifically occurs in the Phase 2 proposal negotiation, where each side sends its supported transforms and the responder cannot find a common set.

Answer

The firewall policy allowing IPsec traffic is missing.

Answer

The remote gateway IP address is unreachable.

Answer

The pre-shared key is incorrect.

Question 18

A FortiGate is configured with FSSO using a DC agent. Users authenticate to the domain, but the firewall policy using FSSO groups is not matching traffic. The admin runs 'diagnose debug authd fsso list' and sees user entries. However, the traffic is being denied by the default deny policy. What is the most likely issue?

Accepted Answer

The session was established before the user logged in and is not updated with the user identity. When a user logs in after a session is already established, the FortiGate does not automatically update that session with the user's identity. The 'diagnose debug authd fsso list' shows the user is authenticated, but the existing session still lacks the FSSO group information, causing it to match the default deny policy instead of the FSSO-based policy.

Answer

The FSSO session timeout is too short

Answer

The firewall policy has the wrong schedule applied

Answer

The user is not a member of the correct FSSO group in Active Directory

Question 19

A network administrator configures an IPsec VPN between two FortiGate devices. Phase 1 completes successfully, but Phase 2 fails to establish. The administrator runs 'diagnose vpn ike log' and sees the error 'proposal mismatch'. What is the MOST likely cause?

Accepted Answer

The Phase 2 local and remote subnets do not match on both ends. The error 'proposal mismatch' in the Phase 2 IKE log indicates that the IPsec security associations (SAs) proposed by one FortiGate do not match the configured Phase 2 parameters on the other. Since Phase 1 completed successfully, the IKE version and pre-shared key are already validated. The mismatch specifically refers to the local and remote subnet definitions, encryption algorithms, or authentication methods in the Phase 2 selectors. Therefore, the most likely cause is that the Phase 2 local and remote subnets are not correctly mirrored on both ends.

Answer

The IKE version is mismatched (IKEv1 vs IKEv2)

Answer

The pre-shared key is incorrect

Answer

The firewall policies are blocking IKE traffic on UDP port 500

Question 20

An admin wants to block all traffic from the internet to a specific internal server except for the IP address 203.0.113.50. Which firewall policy configuration achieves this using the principle of least privilege?

Accepted Answer

Create a deny policy from internet to server with any source, then an allow policy from source 203.0.113.50 to the server above it. It follows the principle of least privilege by explicitly denying all traffic from the internet to the internal server (with a deny policy using any source), then placing an explicit allow policy above it for source 203.0.113.50. In FortiGate firewall policy processing, policies are evaluated top-down, so the more specific allow rule for the trusted source is matched first, while the broader deny rule below it blocks all other internet traffic. This ensures only the permitted IP address can reach the server, and all other traffic is explicitly blocked.

Answer

Configure a VIP with restricted source

Answer

Use a local-in policy to block the server IP

Answer

Create a single allow policy from source 203.0.113.50 to the server and rely on implicit deny for all other traffic