Guidelines for Planning and Configuring SD-WAN

Example topology:

A DMZ network behind the Security Gateway must use a public IP address.

If yes, then follow the applicable scenario.

Scenario 1

If all these conditions occur:

1. Your Security Gateway runs:

   • R82 and higher

   • R81.20 Jumbo Hotfix Accumulator Take 79 and higher

   • Quantum Spark R81.10.15 and higher

2. You use public IP addresses in your internal networks.

3. These "internal" public IP addresses are:

   • Part of the VPN Domain, or

   • Part of the local networks that are connected directly to the Security Gateway.

Then it is not necessary to configure a bypass rule anymore in the SD-WAN Policy.

Use these Dynamic Objects in your SD-WAN Policy:

• My VPN Domain - in the "Overlay - VPN" rules

• Peer VPN Domain - in the "Overlay - VPN" rules

• SD-WAN Internet - in the "Local Breakout" rules

Explanations:

• The Dynamic Objects My VPN Domain and Peer VPN Domain will include public subnets inside the VPN Encryption Domain for overlay rules.

• The Dynamic Object SD-WAN Internet will exclude public IP addresses that are part of the VPN Encryption Domain, or belong to the Security Gateway interfaces.

  Currently, the Dynamic Object SD-WAN Internet does not exclude public subnets that are routed to a different next hop on the Security Gateway and are not connected directly to the Security Gateway.

• For more information about these Dynamic Objects, see Dynamic Objects in SD-WAN Policy.

Scenario 2

If all these conditions occur:

1. Your Security Gateway runs:

   • R82 and higher

   • R81.20 Jumbo Hotfix Accumulator Take 79 and higher

   • Quantum Spark R81.10.15 and higher

2. You use public IP addresses in your internal networks.

3. These "internal" public IP addresses are not part of the VPN Domain.

4. These "internal" public IP addresses are not part of the local networks that are connected directly to the Security Gateway.

Then:

1. In SmartConsole, create a simple Network Group object that contains all such "internal" public IP addresses (for example, call it "Public_IPs_Group") and install the Access Control policy.

2. In Infinity Portal, configure this bypass rule at the top of the SD-WAN Policy (see Configuring SD-WAN Policy):

   #	Name	Source	Destination	Services & Applications	Behavior
   1	Routing for "internal" public IPs	Any	Public_IPs_Group	Any	Default overlay

Scenario 3

If your Security Gateway runs:

• R81.20 Jumbo Hotfix Accumulator Take 76 and lower

• Quantum Spark Gateway from R81.10.05 to R81.10.10

Then:

1. In SmartConsole, create a simple Network Group object that contains all such "internal" public IP addresses (for example, call it "Public_IPs_Group") and install the Access Control policy.

2. In Infinity Portal, configure this bypass rule at the top of the SD-WAN Policy (see Configuring SD-WAN Policy):

   #	Name	Source	Destination	Services & Applications	Behavior
   1	Routing for "internal" public IPs	Any	Public_IPs_Group	Any	Default overlay

If yes, then do you have an internal / DMZ server that has to be accessible from the Internet over multiple ISP links?

• If yes, then:

  • If the server has to be accessible only through one ISP link at a time (ISP links that provide an Active / Backup access):

    These are the possible workarounds:

    1. Configure your default routes with probing, with the desired priority, in this way:

       1. The inbound traffic has to arrive to the internal server at its public IP address that belongs to the main ISP link (best priority).

       2. If the inbound connection through the main ISP link fails, then the inbound traffic has to arrive to the internal server at its public IP address that belongs to the next ISP link (next in priority). See an example configuration of static routes in sk156812.

    2. Use Policy Based Routing (PBR) for the internal server only, with the above default routes with probing.

    The lower the route priority number, the higher the route precedence.

  • If the server has to be accessible over different ISP links that provide a parallel access:

    1. The Security Gateway must run:

       • R82 and higher

       • R81.20 Jumbo Hotfix Accumulator Take 79 and higher

       • Quantum Spark R81.10.15 and higher

    2. Configure the Symmetric Packet Return as described in SD-WAN Symmetric Packet Return.

• If no, then:

  As a possible workaround, use Policy Based Routing (PBR) rules on the Security Gateway that configure a different next hop to Internet for each internal server. For outbound redundancy, you can configure multiple next hops with probing.

  • In the PBR rules, in the Action section, select the option Table (Gaia Portal shows the value Main Table).

  • Use the PBR rule priority lower than 100, so it takes precedence over SD-WAN rules.

These are the possible workarounds for inbound traffic to the Security Gateway itself (Remote Access VPN, Mobile Access, and so on):

• Use the workarounds from the sub-section If the server has to be accessible only through one ISP link at a time (ISP links that provide an Active / Backup access): with different default route priorities.

• Wait for the symmetric return feature to support connections to the Local Security Gateway.

If yes, then:

Do you need redundancy for this outbound NAT traffic between your ISP links?

• If yes, then:

  Can you change the outbound Hide NAT configuration to "Hide behind the gateway"?

  • If yes, then:

    In SmartConsole do these steps:

    1. In the applicable objects change your Hide NAT configuration to "Hide behind the gateway".

    2. In the NAT policy, delete the Manual NAT rules.

    3. Install the Access Control policy.

  • If no, then:

    SeeSD-WAN NAT for ISP.

• If no, then:

  In Infinity Portal, create this rule at the top of the SD-WAN Policy (see Configuring SD-WAN Policy):

  #	Name	Source	Destination	Services & Applications	Behavior
  1	Outbound Hide NAT	Network object with the real IP address	SD-WAN Internet	Any	Use a Steering Behavior object that uses only the ISP link that is related to the NAT IP address (go to Steering Candidates > Specific WAN Links)

If yes, then:

Replace all these Manual Hide NAT rules with the Automatic NAT configuration:

1. Edit the corresponding Network objects > click the NAT page > select "Hide behind the gateway" > click OK.

2. In the NAT policy, delete these Manual Hide NAT rules.

3. Install the Access Control policy.

By design, Manual NAT rules with the Security Gateway object selected in the "Translated source" column, use only the main IP address of the Security Gateway object for Hide NAT and do not use the corresponding Security Gateway's outgoing interface.

If yes, then:

• If your Security Gateway runs:

  • R82 and higher

  • R81.20 Jumbo Hotfix Accumulator Take 79 and higher

  • Quantum Spark R81.10.15 and higher

  Then make sure to add the applicable Dynamic Object My VPN Domain or Peer VPN Domain to the SD-WAN Policy rules that use the Steering Behavior of type "Overlay - VPN".

  The Dynamic Objects My VPN Domain and Peer VPN Domain will include public subnets inside the VPN Encryption Domain for overlay rules.

  For more information about these Dynamic Objects, see Dynamic Objects in SD-WAN Policy.

  Alternatively, make sure to add the public subnets to the SD-WAN Policy rules that use the Steering Behavior of type "Overlay - VPN".

• If your Security Gateway runs:

  • R81.20 Jumbo Hotfix Accumulator Take 76 and lower

  • Quantum Spark Gateway from R81.10.05 to R81.10.10

  Then make sure to add the public subnets to the SD-WAN Policy rules that use the Steering Behavior of type "Overlay - VPN".

If yes, then:

You must configure the Security Gateway object as an object with "Dynamic Address" (DAIP).

The DAIP configuration has limitations.

See SD-WAN Configuration for DAIP Security Gateways.

If yes, then:

• Is your MPLS router connected directly to your core switch, and not directly to the Security Gateway?

  To use MPLS connection as an SD-WAN interface, the MPLS router / line has to be connected directly to the Check Point Security Gateway at a Layer 3 level.

• Do you have Point-to-Point / Layer 2 connectivity between some peer VPN Gateways?

  Roadmap - Support for Point-to-Point / Layer 2 connectivity is on the roadmap.

  Workaround: Connect a separate Layer 3 device between the VPN Peers and use it as the next hop for the peer VPN Gateways.

• Do you need to send the SD-WAN Overlay traffic over a private line as non-encrypted (clear text)?

  This feature is not supported.

If yes, then:

Support for Route-Based VPN with Dynamic Routing is available in.

• R82 and higher

• R81.20 Jumbo Hotfix Accumulator Take 79 and higher

• Quantum Spark R81.10.15 and higher

Workaround:

For peer VPN Gateways that must use Route-Based VPN, enable SD-WAN only on one of the two peer VPN Gateways.

For additional information, see SD-WAN and Route-Based VPN.

If yes, then:

Workarounds:

1. Use Implicit MEP with Source NAT.

   See the Site to Site VPN Administration Guide for your version.

2. Separate your subnets between the Data Centers, so there are no overlaps.

3. User Route-Based VPN with Dynamic Routing.

   Available in:

   • R82 and higher

   • R81.20 Jumbo Hotfix Accumulator Take 79 and higher

   • Quantum Spark R81.10.15 and higher

If yes, then:

1. Edit the VPN Community object.

2. In a VPN Community of type Star:

   1. In the left panel, click MEP.

   2. Clear the checkbox Enable center gateways as MEP.

      SD-WAN does not support Explicit MEP (Known Limitation PMTR-104985).

   3. If this VPN Community contains two or more Center Gateways,

      then either all or none of the Center Gateways must have SD-WAN enabled

      if on the VPN Routing page, you selected one of these options:

      • To center and to other satellites through center

      • To center, or through the center to other satellites, to internet and other VPN targets

3. In a VPN Community of type Star or Mesh:

   1. In the left panel, click Tunnel Management.

   2. If you selected Set Permanent Tunnels, and SD-WAN is enabled on the Security Gateways, then clear the checkbox Enable Route Injection Mechanism (RIM).

      SD-WAN does not support RIM (Known Limitation PMTR-104984).

4. Click OK.

5. Install the Access Control policy.

• For each ISP link, configure a default route with the required next hop. These default routes must have different priorities.

• Configure static routes for remote site networks to use the MPLS next hop, if it exists.

To configure each SD-WAN interface, get the required information:

• IP address and subnet mask for the SD-WAN interface.

• IP address of the next hop.

• NAT IP address, if the SD-WAN interface connects to the Internet through a NAT device.

If yes, then:

You can configure SD-WAN only on CloudGuard Network Security Gateways (CGNS) in cloud environments.

If yes, then:

Workaround:

Put a dedicated supported Security Gateway between the Maestro Security Group and VSX Gateway and the Internet and configure SD-WAN on that dedicated Security Gateway.

If yes, then:

• If your Security Gateway runs:

  • R82 and higher

  • R81.20 Jumbo Hotfix Accumulator Take 79 and higher

  • Quantum Spark R81.10.15 and higher

  Then the ARP Next-Hop Prober feature (enabled by default) should resolve this issue. By default, the Security Gateway performs the nexthop probing using the ARP prober. If the ARP prober fails or does not get a response, then the Security Gateway falls back to using the ICMP Probing.

  If the issue continues, then configure the parameter "sdw_nexthop_probe_enabled = 0" as described in SD-WAN Next Hop Probing on CloudGuard Network Security Gateways.

• If your Security Gateway runs:

  • R81.20 Jumbo Hotfix Accumulator Take 76 and lower

  • Quantum Spark Gateway R81.10.10 and lower

  Then configure the parameter "sdw_nexthop_probe_enabled = 0" as described in SD-WAN Next Hop Probing on CloudGuard Network Security Gateways.

For additional information, see sk181147: Quantum SD-WAN - Troubleshooting.

If yes, then:

You must disable ISP Redundancy in the Security Gateway object in SmartConsole (section Other > page ISP Redundancy) and install the Access Control policy.

SD-WAN cannot work with ISP Redundancy enabled.

Migration from ISP Redundancy to SD-WAN:

• Do you use ISP Redundancy for inbound traffic?

  If yes, then:

  • If the connections should be symmetric (request and reply arrive on the same ISP link), then follow Inbound Non-Encrypted Traffic to Internal Servers.

  • If you have Manual Proxy ARP configured on the Security Gateway (sk30197), then before you disable ISP Redundancy:

    1. In SmartConsole, click Menu > Global properties.

    2. In the left panel, click NAT.

    3. Select Merge manual proxy ARP configuration.

    4. Click OK.

  Roadmap - Support for DNS Proxy in SD-WAN is on the roadmap

• Do you use ISP Redundancy for outbound traffic?

  If yes, then:

  • If you use ISP Redundancy in the Primary/Backup mode, then in the applicable SD-WAN Policy rule, you can use the Steering Behavior object that is configured with "Manual order of WAN Links".

  • If you use ISP Redundancy in the Load Sharing mode, then in the applicable SD-WAN Policy rule, you can use the Steering Behavior object that is configured with "Link Aggregation".

  Note - SD-WAN does not support ISP Weight for Load Sharing.

• Do you use ISP Redundancy for VPN traffic?

  If yes, then after you disable ISP Redundancy:

  1. Edit the Security Gateway object.

  2. In the left panel, click IPsec VPN > click Link Selection.

  3. Configure the applicable settings.

     If a peer VPN Gateway does not have SD-WAN enabled, then select Use probing. Link redundancy mode and select the applicable mode.

     If you do not use link redundancy, then configure a single link.

     Refer to the Site to Site VPN Administration Guide for your version.

  4. Click OK.

  5. Install the Access Control policy.

  Note - If all peer VPN Gateways have SD-WAN enabled, then the settings on the Link Selection page do not apply.

If yes, then:

• For PBR rules that match traffic based on the Access Control rules:

  1. Delete these PBR rules on the Security Gateway.

  2. Configure the applicable rules in SD-WAN Policy.

• For PBR rules that match traffic based on the Source IP address, Destination IP address, Port number, and so on:

  • If possible, delete these PBR rules on the Security Gateway and configure the applicable rules in SD-WAN Policy.

  • If it is not possible to delete the PBR rules, then make sure these PBR rules do not conflict with SD-WAN Policy rules.

  Notes: PBR rules with priority lower than 100 take precedence over SD-WAN Policy rules. SD-WAN Policy rules that use the Steering Behavior object of type "Local Breakout" take precedence over PBR rule with priority greater than 100.