SD-WAN Best Practices

This section describes different best practices for SD-WAN configuration.

VPN - Link Selection

Best Practice - Always configure the Link Selection in the Security Gateway object. If the SD-WAN service on the Security Gateway goes down for some reason, this makes sure the Security Gateway uses the applicable interface for Site-to-Site VPN.

When two or more Security Gateways with enabled SD-WAN participate in the same Site-to-Site VPN Community, these Security Gateways automatically initiate Site-to-Site VPN tunnels between their SD-WAN interfaces.

These Security Gateways ignore the configuration in SmartConsole > Security Gateway object > IPsec VPN > Link Selection, and select the interfaces based on the WAN Link Mapping configuration.
When a Security Gateway with enabled SD-WAN participate in the same Site-to-Site VPN Community with a Security Gateway without SD-WAN, these Security Gateways use the configuration in SmartConsole > Security Gateway object > IPsec VPN > Link Selection.

SD-WAN Policy - Rule Matching

Best Practices:

Make sure that:
- Traffic that should go through SD-WAN, matches the correct SD-WAN Policy rule and behavior.
- Traffic that should not go through SD-WAN, does not match a Local Breakout rule, so it goes through the operating system routing.
In a rule with the Local Breakout behavior:
- Do not use "Any" in the Destination column.
- Do not use any object that can match non-Internet traffic (inter-VLAN communication, traffic to next hop gateways, traffic in DMZ networks, and so on) in the Destination column because the Security Gateway would send the matched non-Internet traffic directly to its ISPs.
In a rule with the Backhaul behavior:
- Do not use "Any" in the Destination column.
- Do not use any object that can match non-Internet traffic (inter-VLAN communication, traffic to next hop gateways, traffic in DMZ networks, and so on) in the Destination column because the Security Gateway would send the matched non-Internet traffic directly to its ISPs.
Configure rules with the Overlay - VPN behavior above rules with the Local Breakout behavior.
Do not use the "Internet" object in rules.

This object cannot differentiate between an actual Internet traffic, Overlay - VPN traffic, or a cleartext traffic that is routed through an MPLS next hop router.

Note - The Security Gateway always matches the original connection direction, even for a return traffic.

The Security Gateway matches the first applicable rule in SD-WAN Policy and stops processing the rules.

The SD-WAN Policy rules that use the Breakout behavior work similar to Policy-Based Routing (PBR). During the routing process, the Security Gateway first applies these rules and overrides the operating system routes when these rules match (including the directly connected networks).

SD-WAN Rule	Guidelines and Security Gateway Behavior
Rule with the Overlay - VPN behavior	Rules with the Overlay - VPN behavior must appear above rules with the Local Breakout behavior. If the Security Gateway with enabled SD-WAN has to encrypt the traffic, and the VPN peer is also a Security Gateway with enabled SD-WAN, then the Security Gateway routes the traffic based on the rule steering behavior. If the Security Gateway with enabled SD-WAN has to encrypt the traffic, and the VPN peer is a Security Gateway without enabled SD-WAN, then the Security Gateway routes the traffic based on the configured Link Selection in the Security Gateway object. If the Security Gateway with enabled SD-WAN does not have to encrypt the traffic, the Security Gateway routes the traffic based on the operating system routing table.
Rule with the Local Breakout behavior	Make sure the Security Gateway does not match the Overlay - VPN traffic to rules with the Local Breakout behavior. This is necessary to avoid an issue where the Security Gateway cannot use all WAN Links, but still encrypts the traffic. The Security Gateway sends the cleartext traffic to its ISPs based on your steering configuration. Make sure the Security Gateway matches only the applicable outbound Internet traffic to rules with the Local Breakout behavior. Make sure the Security Gateway does not match cleartext non-Internet traffic (inter-VLAN communication, traffic to next hop gateways, traffic in DMZ networks, and so on).
Rule with the Backhaul behavior	The Branch Security Gateway encrypts the traffic and sends it to the Center Security Gateway over a Site-to-Site VPN tunnel. The Center Security Gateway sends this traffic to the Internet as a Local Breakout. The Center Security Gateway does not send the traffic to the Internet, if the traffic is designated the Center Security Gateway. This traffic behaves as Overlay - VPN.

SD-WAN Policy - ICMP Probing

Best Practice - In rules with the Overlay - VPN behavior, you must include all SD-WAN interfaces of all SD-WAN Security Gateways and their NATed IP addresses (if configured).

The Security Gateway sends the ICMP Echo Requests to its SD-WAN peer regardless of the SD-WAN Policy rules - the Security Gateway automatically sends this probing traffic from the applicable VPN interface.

The Security Gateway receives the ICMP Echo Replies from its SD-WAN peer based on the SD-WAN Policy rules.

Therefore, this asymmetric scenario is possible:

The Security Gateway "GW1" sends the ICMP Echo Requests through "ISP1" of "GW1" to the peer Security Gateway "GW2" through "ISP1" of "GW2".
The Security Gateway "GW2" sends the ICMP Echo Replies through "ISP2" of "GW2" to the Security Gateway "GW1" through "ISP1" of "GW1".

The SD-WAN Wizard creates these default SD-WAN Policy rules:

Source	Destination	Services & Applications	Behavior
`Any`	`Private Networks`	`Any`	Overlay - VPN
`Any`	`Public Networks`	`Any`	Backhaul

The purpose of the rule "Any > Private Networks > Overlay - VPN" is also to match all encrypted traffic to all private IP addresses (for example, MPLS interfaces) of all Security Gateways and to apply the Overlay - VPN behavior to this traffic.
The purpose of the rule "Any > Public Networks > Backhaul" is also to match all encrypted traffic to the public IP addresses of all Security Gateways and to apply the Backhaul behavior to this traffic.

If it is necessary to change the default Local Breakout rule from the Backhaul behavior to the Breakout behavior, you must create this explicit rule:

Source	Destination	Services & Applications	Behavior
All your overlay external IP addresses of all Security Gateways	All your overlay external IP addresses of all Security Gateways	`icmp-proto`	Overlay - VPN

Important - If your SD-WAN Security Gateway is a Virtual Machine in a cloud (a CloudGuard Network Security Gateway), and its next hop does not respond to ICMP Echo Requests, then you must disable the SD-WAN ICMP Probing on this CloudGuard Network Security Gateway:

Connect to the command line on the CloudGuard Network Security Gateway.
Log in to the Expert mode.

If the file $FWDIR/conf/sdwan/sdwan_steering_params.json exists, create a backup copy.

Otherwise, create this file.

Run this long command:

if [ -f $FWDIR/conf/sdwan/sdwan_steering_params.json] ; then echo "Creating the backup ..." ; cp -v $FWDIR/conf/sdwan/sdwan_steering_params.json{,BKP} ; else echo "Creating the file ..." ; touch $FWDIR/conf/sdwan/sdwan_steering_params.json ; stat $FWDIR/conf/sdwan/sdwan_steering_params.json ; done

Edit the $FWDIR/conf/sdwan/sdwan_steering_params.json file:

vi $FWDIR/conf/sdwan/sdwan_steering_params.json

Add these lines:

{
    "sdw_nexthop_probe_enabled" : 0
}

Save the changes in the file and exit the editor.

Restart the SD-WAN service:

sdwan_steering_stop ; sdwan_steering_start

SD-WAN Policy - Public IP Addresses

The Security Gateway applies the default breakout rules to all Public Networks (using the Zone object "Public Networks").

Best Practices:

If you use public IP addresses inside your organization (for example, in your Internal network, DMZ network, Voice network, Overlay network, VPN network, Private line, Remote site), then to prevent the Security Gateway from matching traffic to these subnets on a rule with the Local Breakout behavior, add these public subnet objects in the Destination column in a rule with the Overlay - VPN behavior.

This makes sure the connection falls back to the operating system routing.
If you use the public NATed IP addresses for inbound traffic, then add these public NATed IP addresses in the Destination column in a rule with the Overlay - VPN behavior.
If there is a Host object with a static NATed IP addresses, and you use this NAT IP addresses for outbound traffic, then add a rule that contains the steering behavior, in which only the ISP applicable for this associated NAT is configured.

Routes

Best Practice - If the Security Gateway has a private line (for example, MPLS), which is part of the overlay, then configure routes that send traffic for all the overlay destination networks to the MPLS next hop.

In this case, even if all ISP links are down, and no active default route exist in the operating system kernel, the specific route on the private MPLS makes sure that the Overlay - VPN traffic continues to work over the private MPLS SD-WAN interface. Without an active route to the destination, the packet is lost in the routing table, before the VPN encryption takes place.