To address the previous article on the matter, I’m going to illustrate all configuration steps. In order to do so, I created a virtual lab where I simulated a multi-location enterprise topology that includes 4 Branches, a Head Quarter and a Data Center. Each Branch is equipped with two Internet connectivity as well as the Data Center and HQ.
The topology I used in this case is the Dual-HUB & SPOKE, as Branches have VPN connections toward the HQ and the Data Center, but not directly between them. Thus, the traffic between the Branches will be established through one of the two HUBs.
This topology allows the redundancy necessary to guarantee constant continuity of service, even in case of failure of one of the hubs, or congestion of one of the two Branch connections. Additionally, with the implementation of a Disaster Recovery strategy, it is possible to guarantee Business Continuity also in case of disaster.
In this simulation, I configured static ipsec vpn tunnels; however, another option is to use ADVPN technology to establish dynamic shortcuts between spoke, and dynamic routing protocols to announce local networks to neighbors.
The firmware version used in the POC is FortiOS 6.4.0, which introduces new important features regarding the SD-WAN:
https://docs.fortinet.com/document/fortigate/6.4.0/new-features/830751/sd-wan
Once the basic network parameters of the various hosts have been configured, it is possible to implement the SDWAN configuration:
HUB configuration sequence
1. VPN
It is essential to create a VPN tunnel from both WAN interfaces towards each Branch.
2. Static Routes
A single default route via SD-WAN is configured.
3. Overlay
We assigned to VPN interfaces an IP in a point-to-point overlay network. In this case we consider /24 networks even though a could be enough /30. This step is essential to designate the IP sources of the SD-WAN (performance SLA) health check, when aiming to include the VPN interfaces in the virtual-wan-link.
4. SD-WAN Interface
All VPN interfaces and the two WANs (port1 and port2) have to be added to the virtual interface by assigning the correct gateways from the SD-WAN.
5. SLA Performance
It is then time for the health check or SLA performance configuration. It is important to configure one or more ping servers for each branch; this specific case employs the remote firewalls inside interface. However, it is possible to either employ a loopback interface or a host within the LAN. It’s essential that servers always respond to probe packets, as a fail would determine the exceeding of the SLA performance thresholds with the consequent trig of the elimination of the routes from the FIB. For this reason, the best practice suggests to configure more than one Detect Server in a production environment. More protocols are available for more defined probe packets as required, but in most cases, ping is adequate for the purpose. However, not all protocols are available from the GUI, following is the full list:
The following step is to configure the server, the protocol and the participating interfaces for each branch; in order to then insert the VPN tunnels that end towards the relevant remote Firewall. Consequently, it is to insert a target SLA (in this case 25ms Latency Threshold, 10 ms Jitter threshold and 2% Packet loss Threshold). Instead, the other parameters benefit of the default values.
6. SD-WAN Rules
SD-WAN Rules are routing rules that make use of the health checks defined above. There is an implicit rule that by default balances the traffic according to the ip source, which can be edited to modify the balancing algorithm and then configure weights or thresholds for a fine tuning.
SD-WAN Rules act like Policy Based Routing and are processed top-down. This means that an incoming packet will be routed according to the first SDWAN rule it matches. In case it does not match any defined rule, the packet will be processed using the implicit rule. I’ll provide here a sample configuration of rules towards each branch by using source and destination networks and other additional parameters. It is possible to include use the application or the internet service as destination, and radius users, tacacs+, ldap, or local to have a more spread control as source. The strategies concerning path includes:
- Manual – It allows to force routing on an interface without depending on target SLA or SLA performance.
- Best Quality – This parameter is based on the performance of the links, the first link inserted (in this case Branch1-WAN1) will be used as long as its latency/jitter/packet loss will be up to 10% worse than the second link, at which point the latter will take over. The 10% threshold is a default value, however it can be configured through CLI.
- Lowest Cost (SLA) – This parameter defines the outgoing interface according to different factors. First is to establish a target SLA defined in the Performance SLAs, and interfaces that do not meet this target are discarded. Secondly, the cost is taken into account, which by default equals 0 but it can be configured otherwise. It is important to mention that the interface with the lowest cost will be preferred among those that meet the target SLA. The third factor concerns the preference. The first interface in order of insertion is the one with the highest preference that, hence, will “win” in case of same cost.
- Maximize Bandwidth (SLA) – This parameter allows to balance round robin sessions between links affected by the same target SLA. In this specific case, cost and preference are not considered.
In the following sample, I employ the Best Quality strategy with Latency as Quality Criteria:
7. Firewall Policy
Firewall policies allow traffic to and from the DC, and between branches. A total of 4 rules are needed:
- from Port3 to SDWAN for traffic from DC to Branch;
- from SDWAN to Port3 for traffic from Branch to DC;
- SDWAN to SDWAN for Branch to Branch traffic;
- Port3 to SDWAN with SNAT on the output interface address for Internet browsing.
- The output interface can be either port1 or port2 according to the latency as defined in the SDWAN rule.
SPOKE configuration sequence
1. VPN
On each branch we create 4 VPN ipsec tunnels: for each WAN interface a VPN tunnel to the DC and one to the HQ.
2. Static Routes
A single default route via SD-WAN is configured.
3. Overlay
We configure the ip in point-to-point VPN overlay networks as in HUBs:
4. SD-WAN Interface
All VPN interfaces and the two WANs (port1 and port2) have to be added to the virtual interface by assigning the correct gateways from the SD-WAN.
5. SLA Performance
We configure three Performance SLAs: it is then time for the SLA performance configuration. The first one will have as Detect Server a public server (e.g.: DNS Google 8.8.8) and will be used to measure latency, jitter and packet loss of the two WANs; the other two will have the HUBs inside interface ip as Detect, or of the LAN servers or loopback interfaces as previously configured. It’s essential that servers always respond to probe packets, as a fail would determine the exceeding of the SLA performance thresholds with the consequent trig of the elimination of the routes from the FIB. For this reason, the best practice suggests to configure more than one Detect Server in a production environment.
6. SD-WAN Rules
The next step is to define four SDWAN Rules: one for traffic to DC, one for traffic to HQ, one for traffic to branches and one for Internet traffic. Moreover, in this case too we configure all rules according to the “Latency” Criteria:
NB: as you can see from the image, a useful new feature of FortiOS 6.4 is the flag that indicates the interface in use by the rule.
7. Firewall Policy
The final step in the configuration process involves the definition of three Firewall policies on each Branch.
- From SDWAN to Port3 for the traffic coming from the remote branches and the two HUBs
- From Port3 to SDWAN for traffic to the two HUBs and remote Branches
- From Port3 to SDWAN for internet browsing with SNAT on the output interface address.
- The output interface can be either port1 or port2 depending on the latency as defined in the SDWAN rule.
In the next article we will perform practical tests of failover and functionality of the SD-WAN based on the configurations implemented and described above.
