Fortinet NSE 7 - Enterprise Firewall 7.0 Free Sample Questions

The OSPF ExStart state indicates that the devices have established two-way communication but are failing to exchange database description (DBD) packets. A common reason for this failure on broadcast networks is an MTU mismatch between the interfaces, which prevents the larger DBD packets from being successfully exchanged. Mismatched area IDs or router IDs would prevent the adjacency from even reaching the ExStart state, and mismatched hello timers would result in a state flapping between Down and Init or 2-Way.

For ADVPN to function, the advpn option must be enabled in the IPsec Phase 1 configuration on all participating spokes. If it's disabled on the new spoke, it will not attempt to create dynamic shortcut tunnels.

The auto-discovery-sender setting on a spoke's Phase 1 allows it to initiate shortcut offers to other spokes. If this is disabled, the spoke cannot trigger the creation of a spoke-to-spoke tunnel, which matches the described symptom.

BGP Graceful Restart allows a BGP speaker to inform its neighbors of its impending restart (or in this case, a failover). The neighbors will then retain the routes learned from the restarting speaker for a specified period, preventing the forwarding table from being cleared. This allows traffic to continue flowing while the BGP sessions are re-established on the newly active cluster member, minimizing disruption. session-pickup is for user sessions, not control plane protocols like BGP.

When snat-route-change is disabled (the default setting), FortiOS does not re-evaluate the route for existing sessions when the routing table changes. The session is tied to its original egress interface and next-hop. Therefore, the existing session will continue to use Route 1, even though it is no longer the preferred route, until the session naturally concludes or times out. New sessions would use the new best route (Route 2).

A 'commit failure' typically means that FortiManager successfully sent the configuration to the FortiGate, but the FortiGate itself rejected the configuration when trying to commit it to its running config. This is often due to a syntax error, a reference to a non-existent object (like an interface or address object that doesn't exist on that specific FortiGate), or a feature that is not supported by the device's specific hardware model or license.

Creating a targeted exemption is the most precise way to mitigate a false positive. It allows the signature to remain active for all other traffic while permitting the specific, legitimate traffic flow that was being incorrectly blocked.

Changing the signature's action to 'Monitor' allows the traffic to pass but continues to generate logs. This is a good troubleshooting step to confirm the traffic is legitimate and to assess the impact of the signature without causing a service disruption.

The statement is false because it confuses the settings for BGP and OSPF. When using OSPF with ADVPN, net-device must be enabled on the hub for the spokes so that the hub advertises its own IP as the next hop. Conversely, when using BGP with ADVPN, net-device must be disabled so the hub preserves the original spoke's IP as the next hop, which is required for NHRP to resolve the address and build the shortcut tunnel.

The message check-is-not-forward failed on policy 0 is the specific debug flow output that indicates the packet did not match any configured firewall policy and was therefore dropped by the invisible, default 'implicit deny' rule (Policy ID 0). This means no explicit policy allowed the traffic to be forwarded.

The ipsengine process load is directly related to the number and complexity of signatures it must evaluate for each packet. A common cause of high CPU is an overly broad IPS sensor. The most effective first step is to tune the sensor by removing signatures that are not relevant to the protected environment (e.g., signatures for servers if only clients are behind the policy, or signatures for operating systems not in use). This reduces the inspection workload without disabling the feature entirely.

For a route-based VPN, the FortiGate needs a route in its routing table to direct traffic destined for the remote network into the tunnel interface. Without this route, the FortiGate does not know where to send the packets.

Even with a correct route, traffic will be dropped by the implicit deny rule unless there is a firewall policy explicitly allowing the traffic flow from the source interface (e.g., LAN) to the destination interface (the IPsec tunnel). A corresponding policy is also needed for the return traffic.