FCSS_EFW_AD-7-4 Practice Questions

From the OSPF status output, the key information is:

● "This router is an ASBR" → This means the FortiGate is acting as an Autonomous System Boundary

Router (ASBR).

● An ASBR is responsible for injecting external routing information into OSPF from another routing

protocol (such as BGP, static routes, or connected networks).

The diagram shows a multi-area OSPF network where:

● FortiGate A is in OSPF Area 0 (Backbone area).

● FortiGate B is in OSPF Area 0.0.0.1 and is connected to an RIP network.

To ensure that OSPF Area 0 (0.0.0.0) learns routes from the external RIP network, FortiGate B must

redistribute RIP routes into OSPF.

Steps to achieve this:

1. Enable route redistribution on FortiGate B to inject RIP-learned routes into OSPF.

2. This allows OSPF Area 0.0.0.1 to forward RIP routes to OSPF Area 0 (0.0.0.0), making the external

network visible.

neighbor-group:

● This command is used to group multiple BGP neighbors with the same configuration, reducing

redundant configuration.

● Instead of defining individual BGP settings for each spoke, the administrator can create a

neighbor-group and apply the same policies, reducing manual work.

neighbor-range:

● This command allows the configuration of a range of neighbor IPs dynamically, reducing the need

to manually define each spoke neighbor.

● It automatically adds BGP neighbors that match a given prefix, simplifying deployment.

In the given ADVPN (Auto-Discovery VPN) topology, BGP is being used to dynamically establish

routes between spokes. The neighbor-range configuration is crucial for simplifying BGP peer setup by

automatically assigning neighbors based on their IP range.

set neighbor-group advpn

● The neighbor-group parameter is used to apply pre-defined settings (such as AS number) to

dynamically discovered BGP neighbors.

● The advpn neighbor-group is already defined in the configuration, and assigning it to the neighbor-

range ensures consistent BGP settings for all spoke neighbors.

set prefix 172.16.1.0 255.255.255.0

● This command allows dynamic BGP peer discovery by defining a range of potential neighbor IPs

(172.16.1.1 - 172.16.1.255).

● Since each spoke has a unique /32 IP within this subnet, this ensures that any spoke within the

172.16.1.0/24 range can automatically establish a BGP session with the hub.

When using IPsec VPNs and VXLAN, additional headers are added to packets, which can exceed the

default 1500-byte MTU. This can lead to fragmentation issues, dropped packets, or degraded

performance.

To resolve this, the MTU (Maximum Transmission Unit) should be adjusted only if all devices in the

network path support it. Otherwise, some devices may still drop or fragment packets, leading to

continued issues.

Why adjusting MTU helps:

● VXLAN adds a 50-byte overhead to packets.

● IPsec adds additional encapsulation (ESP, GRE, etc.), increasing the packet size.

● If packets exceed the MTU, they may be fragmented or dropped, causing intermittent connectivity

issues.

● Lowering the MTU on interfaces ensures packets stay within the supported size limit across all

network devices.

The MAC address e0:23:ff:fc:00:86 follows the format used in FortiGate High Availability (HA)

clusters. When FortiGate devices are in an HA configuration, they use virtual MAC addresses for

failover and redundancy purposes.

The suspicious packet is related to a cluster that has VDOMs enabled:

FortiGate devices with Virtual Domains (VDOMs) enabled use specific MAC address ranges to

differentiate HA-related traffic. This MAC address is likely part of that mechanism.

The suspicious packet is related to a cluster with a group-id value lower than 255:

FortiGate HA clusters assign virtual MAC addresses based on the group ID. The last octet (00:86)

corresponds to a group ID that is below 255, confirming this option.

When multiple remote sites connect to the same hub using overlapping subnets, FortiGate needs to

determine which route should be used for traffic forwarding. The route-overlap setting in IPsec Phase

2 allows FortiGate to handle this scenario by deciding whether to keep the existing route (use-old) or

replace it with a new route (use-new).

In an ECMP (Equal-Cost Multi-Path) routing setup, both routes should be retained and balanced, but

FortiGate does not support ECMP directly over overlapping routes in IPsec Phase 2. Instead, an

administrator must decide which connection takes precedence using route-overlap settings.

When FortiGate processes the first packets of a session, it follows a sequence of steps to determine

how the traffic should be handled before establishing a session. The initial step involves:

● Access Control List (ACL) checks: Determines if the traffic should be allowed or blocked based on

predefined security rules.

● Hardware Packet Engine (HPE) inspections: Ensures that packet headers are valid and comply with

protocol standards.

● IP Integrity Header Checking: Verifies if the IP headers are intact and not malformed or spoofed.

Once these security inspections are completed and the session is validated, FortiGate then installs

the session in hardware (if offloading is enabled) or processes it in software.

The best way to automate a firewall policy using a daily updated list of IP addresses is by using an

external connector from Threat Feeds. This allows FortiGate to dynamically retrieve real-time threat

intelligence from external sources and apply it directly to security policies.

By configuring Threat Feeds, the administrator can:

● Automatically update firewall policies with the latest malicious IPs daily.

● Block traffic from those IPs in real-time without manual intervention.

● Integrate with FortiGuard, third-party threat intelligence sources, or custom feeds (CSV,

STIX/TAXII, etc.).

The exhibit shows an active-passive HA (high availability) cluster with two virtual clusters, where

FortiGate_A is the primary device for both Core1 and Core2. If the goal is to have FortiGate_B take

over Core2 traffic, its priority must be higher than FortiGate_A for Virtual Cluster 2.

Currently, FortiGate_A has a priority of 150 for Core2, while FortiGate_B has 128. Increasing

FortiGate_B’s priority to 200 ensures it becomes the primary for Virtual Cluster 2, taking over the

Core2 VDOM traffic while keeping Core1 traffic on FortiGate_A.

Disabling override would prevent forced failovers but wouldn’t change the role distribution.

Adjusting the load-balancing method is irrelevant in an active-passive setup, as it only applies to

active-active configurations.