Design considerations

This solution uses the FortiCloud Overlay-as-a-Service (OaaS) application to configure an SD-WAN overlay with the FortiGates that the application is configured to connect with.

In this design, the SD-WAN gateway (or sometimes referred to as the hub) acts as a connector to provide connectivity between SD-WAN remote sites. The SD-WAN gateway is located in the cloud, namely, within the FortiCloud infrastructure managed by Fortinet Inc..

OCVPN hub-spoke with ADVPN shortcut architecture

OCVPN supports a hub-and-spoke with ADVPN shortcut network topology. See Hub-spoke OCVPN with ADVPN shortcut.

Traditionally referred to as hub and spoke, this design is the fundamental building block of our solution. In this design, the SD-WAN Gateway (sometimes referred to as the hub or Primary Hub in the diagram) acts as a headend into the business application or private workload. SD-WAN gateways can be located in a single datacenter or central office, and typically provide connectivity for remote locations.

This architecture uses the BGP per overlay method for its routing design. See BGP per overlay.

This example topology will be used to demonstrate deployment procedures to migrate this SD-WAN deployment from OCVPN to OaaS. In the topology, 10.254.0.0/16 is the default reserved subnet used for IP addressing of overlays.

Migrating from OCVPN to OaaS

To migrate from OCVPN to OaaS, it is important to convert the OCVPN hub-spoke with ADVPN shortcut network topology into an OaaS network topology that works in a similar way.

OaaS supports a different hub-spoke architecture than the OCVPN hub-spoke architecture:

• Datacenter LAN is implemented behind a spoke instead of behind a hub (Primary Hub).

• LAN interfaces on the hub do not contain any customer resources or services.

• The hub is maintained by Fortinet Inc. within the FortiCloud infrastructure.

Nevertheless, the OaaS hub-spoke architecture achieves the same functionality as the OCVPN hub-spoke architecture, namely, that spokes (branches) can access resources on the hub (datacenter) and that spokes can access other spokes directly. With the OaaS hub-spoke architecture, spoke-to-datacenter and spoke-to-spoke access are both achieved by using ADVPN shortcut tunnels.

OaaS SD-WAN geo-redundant, dual hub architecture

OaaS supports a geo-redundant, dual hub architecture for a single SD-WAN region where the SD-WAN overlay hub is powered by FortiOS and managed by FortiCloud, and your branch FortiGates and datacenter FortiGates are configured as spokes within this overlay.

This architecture uses the BGP on loopback method for its routing design. See BGP on loopback.

OaaS can configure an overlay for the hub-and-spoke topology using ADVPN and two geo-located hubs which work the same way as the OCVPN network topology presented above:

The example network topology corresponds to the single datacenter (active-passive gateway) design using the IPsec overlay design of one-to-one overlay mapping per underlay. For more details on these topics, see the SD-WAN Architectures for Enterprise guide.

In the above hub-and-spoke topology, the SD-WAN overlay hub is powered by FortiOS and deployed in FortiCloud where a primary hub and a secondary hub are configured for overlay redundancy. The single datacenter FortiGate and branch FortiGate are configured as spokes within this overlay.

OaaS relies on the FortiCloud management tunnel to FortiGates for retrieving interface information and for installing configuration settings orchestrated from OaaS.

By default, OaaS has reserved 10.200.0.0/16 by default for overlay IP addressing of all spokes and this network should not be used in either the LAN subnets or WAN network. If there is conflict, this reserved subnet can be modified in the Settings view within the OaaS portal.

Each FortiGate has a distinct LAN subnet and a loopback interface with an IP address within the 10.200.0.0/24 subnet.

As part of the orchestration process on each spoke, OaaS creates a performance SLA from the spoke to the hub using a health check server within the reserved overlay subnet and then uses this performance SLA to configure a lowest cost (SLA) SD-WAN rule.