Scenario practice questions

The web filter profile has an incorrect FortiGuard category override

Why it fails: A FortiGuard category override changes the action for an entire category, not for a single website. If the website's category is permitted by default and the override is not explicitly set to block, it cannot be responsible for blocking that URL. Moreover, any category-based override would affect all sites in that category, not a single specific website, which contradicts the symptom described.

The antivirus profile is blocking the website

Why it fails: Antivirus profiles in FortiOS inspect file content and block malware downloads, not individual websites by URL or domain. The AV engine cannot make an allow/block decision based on the requested hostname; it only acts after data reaches the FortiGate. If the site simply served HTML, the AV profile would have no basis to block the HTTP request itself, so this is not a plausible cause.

DNS filter is blocking the domain

Why it fails: A DNS filter blocks domains by intercepting DNS queries and dropping the resolution, so the client receives no IP address and the HTTP request never reaches the FortiGate's web filter. If the DNS filter were blocking the domain, the user would see a DNS resolution failure rather than a web-filter block page. The fact that the issue is observed in HTTP traffic to a specific site suggests that the request was successfully routed to the web filter, ruling out DNS filtering as the cause.

Enable aggressive mode

Why it fails: Enabling aggressive mode changes the Phase 1 IKE exchange to send identity and pre-shared-key hashes in fewer packets, which can help when clients have dynamic IPs, but it is not a mandatory setting for dialup IPsec. FortiGate dialup Phase 1 configurations also support main mode, since the remote gateway wildcard 0.0.0.0 lets the responder accept any initiator and learn the peer's IP from the IKE source address. Thus, aggressive mode is an optional tunable, not a prerequisite for a dialup VPN.

Configure a static route to the remote users' subnet

Why it fails: A static route to the remote users' subnet is not part of Phase 1 configuration and cannot be predefined, because dialup remote users typically receive an IP address from a dynamically assigned pool via mode-config after the tunnel is up. In route-based IPsec, a static route is added pointing to the local tunnel interface—never to the remote gateway—and a dialup setup deliberately avoids hard-coding remote subnets that are unknown until connection time. Therefore, this option is outside the scope of dialup Phase 1 and is not a valid prerequisite.

Set the remote gateway to a specific IP address

Why it fails: Setting the remote gateway to a specific IP address would force the dialup VPN to accept connections only from that exact source IP, which defeats the purpose of a dialup VPN for mobile or remote users whose addresses frequently change. The FortiGate uses 0.0.0.0 as a wildcard specifically to avoid this restriction; a specific IP is appropriate for a fixed site-to-site tunnel, not a dialup server that must serve an arbitrary set of clients. This option would break dialup connectivity rather than enable it.

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

Why it fails: An IP pool is a source NAT object that lets you translate the source address of outbound traffic to a specific IP or range other than the egress interface's own address. In this scenario, the FortiGate's outgoing interface already has the public IP 198.51.100.1, and no requirement exists to use a different or additional source IP, so creating an IP pool adds unnecessary complexity. Without a pool, enabling NAT on the policy will automatically use the interface IP, which fully satisfies the requirement.

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

Why it fails: A Virtual IP (VIP) is used for destination NAT, translating an incoming packet's destination address from a public IP to a private internal server, such as a web server backend. It does not affect the source address of outbound packets, so it cannot perform the source NAT required in this policy. Since the scenario involves outbound traffic (implied by the need for source NAT), referencing a VIP would misapply a DNAT object and fail to achieve the intended translation.

Configure Central SNAT and a matching rule

Why it fails: Configuring Central SNAT would manage source NAT rules in a dedicated table, separate from the firewall policy itself. This approach fails the scenario because the question asks for the NAT configuration *applied to the policy*, implying policy-based NAT where the NAT action is defined directly within the firewall rule. Central SNAT is tempting as it performs source NAT, and it is the correct choice when an administrator prefers a centralised, ordered list of NAT rules, independent of individual firewall policies, for consistent management across multiple rules.

Central NAT policy to force the traffic out of WAN2

Why it fails: Central NAT controls source and destination address translation, not egress interface selection; it cannot force traffic out of WAN2. It is tempting because NAT policies are configured per outgoing interface, and would be correct if the requirement were to apply consistent translation rules across multiple VDOMs.

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

Why it fails: A static route to 203.0.113.0/24 cannot match on destination port, so it would divert all traffic to that subnet via WAN2, not just port 443. It is tempting because static routes do steer specific destinations, and would be correct if only the destination subnet needed redirecting regardless of port.

SD-WAN with a strategy of 'Best Quality'

Why it fails: Best Quality selects the link by measured latency, jitter and packet loss, so WAN2 is not guaranteed for 203.0.113.50:443 and WAN1 may win. It is tempting because SD-WAN steers traffic across multiple links, and would be correct if the goal were dynamic per-link quality selection rather than a fixed exit.

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

Why it fails: Port forwarding on the VIP controls destination address and port translation, leaving the source IP untouched. If the internal server expects a different port, the firewall would translate the destination port accordingly, but the source address would still reflect the original client or the FortiGate's egress IP depending on policy NAT. Thus, port mismatch explains connection failures, not the altered source IP observed by the server.

The VIP is using a different public IP than expected

Why it fails: This option contradicts the scenario's premise, since external users can successfully reach the server through the configured public IP. If the VIP were bound to a different public IP, the expected destination would not be reachable, and the traffic would never arrive at the server. Even if the VIP had an incorrect IP, it would not cause source address rewriting; source IP modification is governed solely by the firewall policy's NAT settings.

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

Why it fails: Asymmetric routing occurs when reply traffic returns via a different path, which can cause state timeouts or dropped packets but does not alter the source IP recorded on incoming packets. If NAT were disabled, the server would still see the client's original IP even with misconfigured routing, because routing decisions don't modify the source address field. The observed source IP change is a direct result of policy NAT, not a routing anomaly.

The IP pool is exhausted and no more translations are available

Why it fails: The IP pool being exhausted would cause all new outbound connection attempts to fail, not just those from a particular application, and it would affect any destination. Even with overload (PAT), the limiting factor is frequently the range of source ports, not the number of IP addresses; however, a single app like SIP or FTP would not be singled out by an exhausted pool. Hence, this is not a valid explanation for an application-specific NAT requirement.

The route to the destination is missing

Why it fails: A missing route to the destination would prevent the firewall from even sending a packet toward the target, resulting in a total connectivity failure for every session, not selective application breakage. NAT and routing are independent layers; a policy-based NAT rule cannot compensate for a routing blackhole. Therefore, this would not explain why only certain applications require a fixed port range.

The firewall policy does not have NAT enabled

Why it fails: In FortiOS central NAT mode, translation is controlled by separate NAT policy rules, and the 'NAT' toggle on the firewall policy is not used; it is irrelevant to the translation process. If the firewall policy does not have NAT enabled, it does not mean central NAT is disabled—the central NAT policy still applies. Therefore, this is not a reason to think policy-based NAT is needed; the NAT configuration is already independent.

Load-balanced cluster

Why it fails: FortiGate does not offer a separate HA mode called 'load-balanced cluster'; load balancing is only a scheduling option within active-active HA, where every cluster member actively forwards traffic and new sessions are distributed among them. Since the observed cluster has a standby unit rather than all members actively forwarding, it cannot be in a load-balanced configuration, because load-balanced operation requires all units to be active and handling traffic simultaneously.

Standalone

Why it fails: Standalone is not an HA mode at all; it describes a single FortiGate unit operating independently with no HA peer, no heartbeat interface, and no automatic failover capability. The administrator is observing an HA cluster, which by definition consists of multiple FortiGate units exchanging heartbeat messages and maintaining cluster roles, so 'standalone' is categorically impossible for a functioning HA deployment.

Active-active

Why it fails: Active-active HA is a FortiGate HA mode in which both cluster units are active and process data traffic concurrently, using a scheduling algorithm such as least-connection, source-IP hash, or round-robin to distribute new sessions across the members. In the described cluster, one unit is in standby and only one unit handles traffic, which directly contradicts active-active's core requirement that all cluster members be active; active-active is a distinct mode from active-passive, and the observed standby role identifies the cluster as active-passive.

Subnet object

Why it fails: A subnet object defines a contiguous range of IP addresses using CIDR notation (e.g., 192.168.1.0/24), making it a static, broad match for any host within that range. It cannot resolve a domain name or track the IP of a single server that may change over time. If the server's IP changes, the administrator would need to manually update the subnet object, which is inflexible compared to an FQDN object.

Wildcard FQDN object

Why it fails: A wildcard FQDN object matches one or more domains sharing a common suffix, such as *.example.com, and is used to cover a group of dynamic subdomains. It does not resolve to a single, specific server IP, and its pattern matching could inadvertently include unintentional subdomains. For allowing traffic to one unique server, a regular FQDN object is required because it binds the policy to an exact hostname rather than a wildcard pattern.

Geography object

Why it fails: A geography object filters traffic based on the source or destination country, region, or continent using geolocation data, not on a specific host's IP address or hostname. It cannot identify one particular server unless that server is the only one in its country, which is impractical and risky. This object type is intended for broad geographic access control, not for granular host-level traffic enforcement.

Create a VIP for the cloud service

Why it fails: A Virtual IP (VIP) is an inbound destination NAT object that maps an external/public address to an internal server's private address. It does not participate in outbound path selection, so it cannot be used to force traffic destined to a cloud service out a specific WAN interface. Since the cloud service is external and the FortiGate is the source, VIP semantics are entirely inapplicable.

Configure static routes with different distances

Why it fails: Configuring static routes with different administrative distances for the same destination provides failover, not policy-based access. The routing table always prefers the route with the lowest distance, so only one route is active at a time unless equal-cost multipath is configured. Static routes cannot match on source IP, protocol, or specific destination port, so they cannot steer a particular cloud service's traffic to a chosen WAN while leaving other traffic on the default path.

Use SD-WAN rules to load balance

Why it fails: SD-WAN rules can indeed steer traffic by destination, but they are designed for dynamic, policy-based load balancing and require the WAN interfaces to be members of an SD-WAN zone with performance SLAs and health checks. For a simple static requirement — send this specific cloud service's traffic out port1 — using SD-WAN adds unnecessary configuration complexity and isn't the most direct routing method. PBR gives the same outcome with a simpler, purely routing-based rule.

The firewall policies on the hub do not allow traffic between the spoke networks

Why it fails: If the firewall policies on the hub were the root cause, the inter-spoke traffic would be denied consistently, regardless of reboot state, and the hub would log denials. However, the issue here is that the hub cannot route the traffic to the next spoke, which is a forwarding problem, not a policy problem. Firewall policies are a necessary condition for any traffic to be allowed, but without routes, the packet is never even looked up against a policy because it fails the routing lookup.

The spokes have mismatched IKE versions

Why it fails: Mismatched IKE versions between the spokes and the hub would prevent the Phase 1 negotiation from completing, so none of the IPsec tunnels would come up at all. This would cause a total loss of connectivity, including spoke-to-hub traffic, not merely an inter-spoke communication failure after reboot. Since the spokes can still communicate with the hub, the IKE parameters, including version, must be correctly negotiated.

The hub's IPsec Phase1 is not configured for DPD

Why it fails: DPD (Dead Peer Detection) is used to detect whether the remote VPN peer is still reachable, typically by sending liveness probes. Not enabling DPD on the hub does not affect the forwarding plane or the routing table; it only means that dead peers are not detected quickly. A reboot would re-establish the tunnels, and DPD settings are not involved in the routing decision between spokes, so this cannot be the cause of the inter-spoke failure.

Enable XAuth for user authentication.

Why it fails: XAuth provides an additional user authentication step after IKE Phase 1, but it does not allocate tunnel addresses or send down DNS/WINS settings. For basic dialup IPsec connectivity, the gateway only needs a Phase 1 proposal (e.g., PSK/certificates) and Phase 2 proxy IDs; XAuth is optional. Omitting XAuth does not prevent remote clients from establishing a tunnel if mode-cfg and an IP pool are correctly configured.

Enable Dead Peer Detection.

Why it fails: Dead Peer Detection is a keepalive mechanism that detects when the remote peer becomes unreachable, allowing the gateway to expire idle security associations. It is a reliability enhancement, not a provisioning step, and does not affect whether a client receives an IP address or can connect. If DPD is disabled, the VPN still works, though stale SAs may linger longer.

Enable NAT traversal.

Why it fails: NAT traversal is needed only when the remote client is behind a NAT device that changes the UDP source port or address of IKE packets. With direct Internet connections, NAT-T is not required, so enabling it does not guarantee client addressing or configuration. The absence of NAT-T does not block a dialup client that is not behind NAT, and its presence does not replace the need for mode-cfg.

Configure a VIP for source NAT

Why it fails: A Virtual IP (VIP) is designed for destination NAT: it translates an incoming packet's destination address from a public IP to a private server address. It does not alter the source address of outbound traffic, so configuring a VIP for source NAT would have no effect on hiding internal IPs. Since the goal is to hide internal sources on egress, a VIP is the wrong tool.

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

Why it fails: Policy-based routing (PBR) selects a next-hop or outgoing interface based on packet attributes, but it performs no address translation whatsoever. Directing traffic to an external NAT device would require that device to actually perform the translation, and the FortiGate itself would still need a separate NAT configuration. This approach adds network complexity and does not solve the requirement of hiding internal IPs on the FortiGate, so it is incorrect.

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

Why it fails: A one-to-one IP pool reserves a unique public IP address for each internal source IP, meaning every internal host is mapped to a distinct external address. This approach does hide the original private IP, but it consumes a public IP per concurrent host and does not provide the 'many-to-one' address hiding that is typically intended. For simply hiding all internal IPs behind a single egress address, a one-to-one pool is wasteful and unnecessarily restrictive.

Both units must have the same hostname.

Why it fails: The FortiGate hostname is a purely administrative label and is not used in HA negotiations or synchronization. HA members identify each other by serial number and HA group ID, not hostname, so two units can have different hostnames and the cluster will still function. In fact, FortiGate may even overwrite hostnames to match the primary, but that is a side effect, not a requirement.

Both units must be in NAT/Route mode.

Why it fails: Operating in NAT/Route mode is not a requirement for FortiGate HA. HA works in both NAT/Route and Transparent mode, provided all cluster members are configured in the same mode. A mixed-mode cluster is invalid, but NAT/Route mode alone is not mandatory—a transparent-mode cluster also supports HA failover and session synchronization.

The HA priority must be set to 0 on both units.

Why it fails: Setting HA priority to 0 on both units would not be a valid configuration; priority values range from 0 to 255, and the higher the priority, the more likely the unit becomes the primary. If both units have identical priority, the cluster falls back to comparing serial numbers, which is not a reliable way to configure preferred failover behavior. The correct practice is to set different priorities on each unit, not 0 on both.

NAT/Route mode

Why it fails: NAT/Route mode makes the FortiGate a Layer 3 router: it forwards packets based on IP routing tables, requires different IP subnets on each interface, and typically applies NAT boundary functions. It does not bridge traffic at Layer 2, so it cannot provide transparent insertion into an existing segment. Because the question calls for a transparent bridging capability, NAT/Route mode is incorrect for that reason.

HA mode

Why it fails: HA mode is a high-availability feature that pairs two FortiGates into a cluster for redundancy and failover, either active-passive or active-active. It is not an operating mode for packet forwarding; rather, it is a deployment scenario that can run on top of either Transparent or NAT/Route mode. Therefore, HA mode cannot be selected as the bridging operating mode because it does not define how traffic is bridged or routed.

VLAN mode

Why it fails: FortiOS does not include a separate 'VLAN mode'; VLANs are configured as subinterfaces or tagged interfaces within either Transparent or NAT/Route mode. While you can create 802.1Q VLANs to segment traffic, that is a feature, not a standalone operating mode. This option is incorrect because it conflates the ability to handle VLAN tags with a distinct forwarding mode that does not actually exist.

The LDAP server is unreachable

Why it fails: The fnbamd debug log explicitly records "successful contact" with the LDAP server, meaning the FortiGate resolved the server name, reached it over the network, and received a response—likely a connection acknowledgment or an LDAP greeting. If the server were unreachable, the debug output would instead show repeated connection timeouts, 'no response', or a failure to establish a socket, not a successful contact followed by an authentication attempt. Thus, the option is directly contradicted by the evidence in the log.

The LDAP bind user password is incorrect

Why it fails: When the LDAP bind user (the service account FortiGate uses to search the directory) has an incorrect password, the initial bind phase fails immediately, preventing any subsequent query or user authentication. The debug output shows that FortiGate not only contacted the server but also proceeded to attempt user authentication, which proves the service account bind succeeded and the server accepted those credentials. A bad bind password would produce an error much earlier in the sequence, before any specific user's credentials are validated.

The LDAP schema does not match what FortiGate expects

Why it fails: An LDAP schema mismatch typically surfaces as failures to map directory attributes (for example, missing sAMAccountName, memberOf, or group objects), generating errors like 'attribute not found' or 'cannot retrieve user groups', rather than a clean 'authentication failed' response. The debug output shows the server accepted the user DN and password attempt, which indicates the server could locate the user object and evaluate the credentials; a schema problem would not affect the basic LDAP bind operation that verifies the password. Therefore, schema mismatch does not explain a specific user authentication failure after successful contact.