Routing Traffic to an Off-Cloud Link

Traffic that is sent over the Cato Cloud benefits from the Cato network and security enhancements. However, there are specific scenarios where companies may need to use Socket to Socket direct VPN connectivity over the Internet. The off-cloud transport feature lets you configure Sockets to send off-cloud traffic over the Internet instead of the Cato Cloud. For example, when there are regular backups between different sites in the same region, you can designate these backups as off-cloud transport.

The Sockets create a full mesh topology with each other for the off-cloud traffic. The traffic is encrypted and sent over the Internet using DTLS tunnels.

For Sockets with multiple links, you can enable or disable each link for sending off-cloud traffic. Off-Cloud can be configured in these deployments:

This section explains how to configure sites and network rules for off-cloud transport.

Enabling the Sites for Off-Cloud Transport

Enable off-cloud transport on each site that is sending and receiving off-cloud traffic. For Socket deployments with multiple links, configure the links to support off-cloud traffic.

By default, off-cloud transport is enabled for the WAN links on Socket sites. However, when you define the WAN Precedence for a link as 3 (Last-Resort), then off-cloud transport is automatically disabled for that link.

The example above, shows a site with the WAN1 and WAN2 links are configured to send off-cloud traffic. You can also choose to configure a site where one of the WAN links only sends traffic over the Cato Cloud.

For more about sites with multiple links, see below Configuring a Site for Off-Cloud with Multiple Links.

Configuring the Public IP and Static Port

In general, the Public IP and Static Port settings for links that send off-cloud traffic are automatically configured by the Socket, and aren't configured in the Cato Management Application. The Socket chooses a random source port and uses the public IP address of the Internet router to initiate the connection.

You can also use the Cato Management Application to manually configure a static public IP address and port number for each link that sends off-cloud traffic. When doing this, make sure that the site's Internet router is assigned a fixed public IP address and configured with a matching Port Forwarding Rule. Otherwise, don't manually configure the Public IP and Static Port settings.

However, in some situations you need to configure these settings. For example, when you are using port-forwarding rules as a solution to NAT related issues with the local router.

To enable off-cloud transport for a site:

1. From the navigation menu, select Network > Sites, and select the site.

2. From the navigation menu, select Site Configuration > Socket.

3. Configure the active link that will be enabled for off-cloud traffic:

   1. Click the link.

      The Edit Socket Interface pane opens.

   2. Expand the Off-Cloud section.

   3. In the Traffic Status drop-down menu, select Enabled.

   4. (Optional) Enter the Public IP and Static Port number for the off-cloud link.

4. Click Apply, and then click Save.

5. Repeat the previous steps for each site that sends and receives off-cloud traffic.

Create a network rule that defines the type of WAN traffic that is sent using the off-cloud transport. Then configure this rule to route the traffic over the off-cloud transport.

You can't configure the Interface Role options for off-cloud transport. Also, disable TCP acceleration for network rules that use off-cloud as the primary transport.

For more about network rules, see Configuring Network Rules.

For Sockets with multiple links, you can configure active/active and active/passive deployments for off-cloud traffic. If you choose to only enable one link for off-cloud traffic, if that link can't send traffic, then the off-cloud connections follow the Routing > Transport settings for the network rule.

For in-depth technical background about Sockets with multiple links, see Part 1: The Socket Interfaces and Precedence.

In active/passive deployments, the Socket links are set to different precedences and provide high availability for the site. Every few seconds, the Socket evaluates the link quality of the active link - if the health of the active link degrades, then the Socket gradually moves the traffic to the passive link. When the link quality is restored, the Socket resumes sending traffic over the active link. Similarly, if the active link goes down, then the traffic flows are transferred to the passive link until the active link is restored. These are the minimal link quality metrics:

If a link can't meet one of the above metrics, then the traffic is gradually moved to the other link. Every 10 seconds the Socket evaluates the links and chooses the best link for the traffic. So, if the Socket fails over to the passive link, then it waits at least 10 seconds before it can fall back to the active link.

In some situations, failover to the passive link can create asymmetric traffic between two sites. For example, site1 and site2 are both configured for active/passive deployments. If site1 fails over to the passive link, site1 sends traffic over WAN2 and site2 sends traffic over WAN1. Another situation is when one site is configured in an active/active deployment and the other side is active/passive. The single active link on one site sends traffic to both active links on the other site.

You can show analytics and status for the off-cloud traffic and tunnels, in the Off-Cloud screen.