NSE6-SDW-AD-7-6: Fortinet NSE 6 - SD-WAN 7.6 Enterprise AdministratorDemo

FortiManager model-device CSV imports require a Device Blueprint assignment for each device, in addition to serial number and name. For ZTP, every per-device metadata mapping used to define an IP address or gateway must be populated; otherwise FortiManager cannot render a complete device-specific interface configuration. Metadata not used for IP addressing is optional unless the assigned configuration explicitly consumes it. FortiManager Administration Guide: Import model devices from a CSV file

FortiGate applies policy-route precedence as policy-based routes, followed by ISDB routes, then SD-WAN routes. Traffic not resolved by those mechanisms proceeds to the routing table, where a BGP route can be selected according to normal route selection. Fortinet: Policy routes

A dynamic Phase 1 IPsec interface configured with peertype any is the hub-side configuration that accepts dialup connections from spokes. Enabling auto-discovery-sender on that hub enables it to send ADVPN shortcut offers. Fortinet’s ADVPN hub examples use this same combination of settings.

The corporate SD-WAN rule matches this source and corporate destination and lists member sequence numbers 3, 4, and 5. The policy-route output maps those members in order to HUB1-VPN3, HUB1-VPN2, and HUB1-VPN1. In SLA mode, when eligible links have equal cost, FortiGate uses interface preference order; therefore HUB1-VPN3 is selected while all links remain stable.

An ADVPN spoke can receive remote health-check information from another spoke. The remote health check info(3) field and the three entries under Remote information, each identified by a remote gateway, show health metrics for the remote spoke’s hub tunnels. This indicates a spoke receiving health-check measures for another spoke’s tunnels.

Cloud on-ramp optimizes access to cloud workloads and applications by using an optimized path to the cloud. Remote breakout backhauls internet-bound branch traffic to a hub, allowing traffic inspection to be centralized and reducing local security-management requirements. Direct internet access is local breakout, rather than a mechanism for centralized inspection.

Passive WAN health measurement derives jitter, latency, and packet-loss information from TCP sessions that pass through a firewall policy with passive measurement enabled. With Facebook and YouTube specified in the SD-WAN rule, FortiGate calculates the member’s SLA performance from the relevant application metrics; the rule-level metric is the average for those applications. Passive detection uses live traffic rather than marking a link dead solely because the specified application traffic is absent.

The gateway field contains the unresolved metadata variable $(sdwan_port1_gw) rather than a valid IPv4 address. The metadata variable must be defined and mapped to a valid value for branch1_fgt (or an applicable device group/default mapping). FortiManager supports per-device metadata-variable mappings specifically so shared templates can render device-specific values.

MSSP-premises hub blueprints keep all customer locations as spokes, allowing direct Internet access at each spoke and efficient spoke-to-spoke traffic through ADVPN shortcuts. The multitenant implementation uses a shared MSSP hub with one VDOM per customer, while the no-multitenancy implementation provides dedicated customer hubs at the MSSP premises. A customer-premises hub design instead suits deployments in which spoke-to-hub traffic predominates and spoke-to-spoke traffic is only occasional.

SD-WAN service rule 3 matches the specified source subnet and destination address. Its fib tie-breaker selects the eligible member whose routing-table entry provides the best prefix match for the destination. The specific route for 10.2.5.254 is 10.2.5.0/24 through HUB1-VPN3, so FortiGate steers the traffic through HUB1-VPN3.

In SLA mode, SD-WAN prioritizes interfaces according to the configured SLA settings. With SLA comparison by health-check order, HUB1-VPN3 is preferred because its sla(0x3) status shows that it satisfies both configured SLA checks, while HUB1-VPN2 satisfies only one and HUB1-VPN1 satisfies none. The rule is not in load-balance mode.

FortiManager SD-WAN overlay orchestration generates CLI, BGP, and IPsec provisioning templates for the branch (spoke) devices. The IPsec template creates the spoke-to-hub overlay tunnels, the BGP template provides dynamic routing configuration, and the CLI template supplies the remaining device-specific overlay configuration. A static-route template can be integrated when selected, but it is not one of the standard three generated spoke templates.

An interface that is an SD-WAN member cannot be referenced directly in a firewall policy. The policy using port1 directly conflicts with port1 being an SD-WAN member in the template, so the policy package cannot be installed. Firewall policies can instead reference an SD-WAN zone. Fortinet: SD-WAN zones and interface members

A policy route with protocol=17 matches UDP, and its destination range 10.22.0.0–10.22.0.255 is the 10.22.0.0/24 subnet. SD-WAN route-policy entries are identified by vwl_service; the displayed application control fields show that application categories are being used as SD-WAN rule destinations. FortiGate load-balancing output explicitly includes a load-balance indicator and hash mode, neither of which appears in these entries.

The matching SD-WAN service includes the source range 10.0.1.0–10.0.1.255 and destination range 128.66.0.0–128.66.255.255. Both selected members, port7 and port8, satisfy the SLA, and the service uses round-robin SLA load balancing. FortiGate therefore distributes matching traffic across port7 and port8.

FortiManager policies can select an SD-WAN zone as a source or destination interface, but they cannot select an individual SD-WAN interface member. HUB1-VPN1 is a member of the HUB1 SD-WAN zone, so policy 3 must use HUB1 as its destination interface.

A CLI template group can contain multiple CLI-template members, including different CLI-template types, and its members are applied in their listed top-to-bottom order. A provisioning template group can also include one template from each supported type, including both a system template and an SD-WAN template. FortiManager documents CLI and Jinja as the CLI-template script types, and lists system and SD-WAN among the template types permitted in a group.

Application-based SD-WAN matching uses an ISDB cache entry keyed by the destination IP address, protocol, and destination port. A GoToMeeting session whose 3-tuple is absent from that cache cannot initially match the application steering rule and is processed by the implicit rule. Following application detection, FortiGate must refresh and re-evaluate the session’s routing information; if that refresh does not occur, the session continues on the path selected by the implicit rule. The Collaboration application category already provides a configured match for GoToMeeting, and successful application identification does not establish a requirement for full SSL inspection.

A single SD-WAN topology can include FortiGate spoke devices that use different SD-Branch extensions. SD-WAN hubs should be dedicated FortiGate devices without extensions because they provide the central overlay-termination and routing functions; adding extension-management duties to those hubs increases complexity and can affect scalability and performance.

FortiGate evaluates SD-WAN rules in their configured order. The earlier matching service applies to this source address, and that service has the selected WAN members port2 and port1; consequently, the traffic is steered using port1 or port2.

In FortiGate VPN event logs, advpnsc=1 identifies an ADVPN shortcut tunnel, whereas advpnsc=0 identifies a tunnel that is not an ADVPN shortcut. The HUB1-VPN1_0 entry has advpnsc=1.

An SD-WAN member-priority change marks affected existing sessions as dirty for reevaluation. With snat-route-change enabled, SNAT sessions perform a new route lookup after a routing change and apply the newly selected SNAT path. Since port1 becomes preferred when port2’s priority is raised to 20, SNAT session gateway information is updated from port2 to port1.

For a multi-region SD-WAN design that uses ADVPN within each region and does not require direct ADVPN shortcuts across regions, eBGP is preferred between the regional hubs. Regional gateways exchange summarized regional routes over eBGP, while branch-to-branch ADVPN traffic remains within the region. Fortinet’s inter-region connectivity guidance explicitly identifies eBGP as preferred when cross-regional ADVPN is not required.