This article discusses how to configure a site to bypass the Cato Cloud and egress traffic directly to the Internet.
The Bypass page lets you define bypass rules for Internet traffic that will directly egress to the Internet instead of being routed to the Cato Cloud. Bypassed Internet traffic is not inspected by the PoP security stack in the Cato Cloud security stack. The Socket continues to apply Bandwidth Profiles and QoS to bypassed traffic in the upstream direction. QoS is not applied in the downstream direction because the PoPs are bypassed.
Bypassed Internet traffic is sent over a Socket WAN interface. An internal Socket mechanism generates a score for each WAN interface which is calculated each second based on a set of parameters, such as packet loss, jitter, latency, and congestion.
The default behavior is for the Socket to automatically choose the WAN port for the bypass traffic based on the best score. The Socket can select different WAN ports for different flows.
Preferred Socket Port
When Preferred Socket Port is enabled for a site, you can choose to assign a preferred Socket WAN port for a bypass rule that is used to egress the traffic. With this option, if the WAN interfaces have a similar score, the Socket will use the preferred WAN port for the bypass traffic, as long as the port has Internet connectivity. If the preferred WAN port loses connectivity, the Socket selects a different WAN port for the traffic.
Note
Note: Bypassing Internet traffic is only supported for Socket and vSocket sites.
To define a bypass rule for Internet traffic:
-
From the navigation menu, select Network > Sites, and select the site.
-
From the navigation menu, click Site Configuration > Bypass.
-
For the Destination or Source rule, click New. The New Interface panel opens.
-
Configure the settings for the bypass rule:
-
The Name of the new bypass rule
-
The IP range or IP addresses for the rules
-
(Optional) The traffic protocols that are bypassed: TCP, UDP, ICMP or None (all protocols are allowed)
-
-
(Optional) In Preferred Socket Port, select the WAN port that egresses traffic directly to the Internet.
-
Click Save.
For Socket and vSocket sites, the default flow timeout is 60 seconds. After this time, there is an idle timeout for the traffic flow and the Socket closes the bypassed flow.
You can use the Socket WebUI to customize the flow timeout. However this custom setting is not persistent and if the Socket reboots, including upgrading to a new version, then it reverts to the default flow timeout of 60 seconds. To permanently configure a custom flow timeout, please contact Support.
To customize the bypass flow timeout:
-
Log in to the Socket WebUI:
-
From the navigation menu, select Network > Sites, and select the site.
-
From the navigation menu, select Site Configuration > Socket.
-
From the Actions menu of the socket, select Socket WebUI.
-
-
From the Cloud Connection Settings tab, in the Flow timeout (for bypass flows only) section, enter the new timeout value.
-
Click Update.
10 comments
No mention of what impact bypassed traffic may have on overall bandwidth / QoS
I need a feature to make a certain subnet in local site locally breakout to internet without advertise the subnet into the SDWAN. Any advice?
JM Excellent point - yes the Socket applies QoS to bypassed traffic. I updated the article accordingly.
Thanks!
Thanks Yaakov,
Would it be possible to expand on exactly how QoS is then applied, and how to monitor this?Assumption is nothing will be recorded and shown in CMA as it all happens on the socket - is there any way to see what's going on using the Socket UI?
We have exactly the same requirement as Nicky Tham.
RFE being sent.
Is there a maximum limit on the number of sessions for bypassed traffic on a single interface? If a socket is directly collecting data from the Internet, I believe clients cannot communicate without Network Address Translation (NAT). In such a case, would the socket allocate assignments similar to traditional NAT (PAT) devices, using the port number range of 1024 to 65535?
Any Roadmap plans to allow more specific source/destination combination bypass rules to allow more granular PBR? Like if i wanted to send just icmp type traffic to a certain IP for lets say circuit monitorig or something like that. Currently its an all or nothing based on the source or destinations configured in the rulesets.
Does bypassing the Cato Cloud mean that if I have a 500mbps WAN Link and the site is licensed for 100mbps I can bypass the Cloud for some traffic and that traffic will use the remaining 400mbps not allocated to the Site's POP Connection? OR is the total bandwidth of Cloud traffic + Bypassed traffic subject to the site's 100mbps limit?
Hi Andrew, for licensing questions, please contact your sales representative.
Thank you - Yaron
I echo Adam's comment above: this feature needs far more granularity and additional options in order to be useful, otherwise this is a very blunt knife.
In my use case, I would ideally like to be able to specify both source AND destination and to be able to use an FQDN for the destination, or to at least have the option to select an application, or even just a protocol / destination port.
Could this not be wrapped up in the global network rules section to allow the selection criteria there (which more than meet my needs) to apply to an Internet rule which bypasses the Cato cloud, similar to the ‘off-cloud’ functionality for socket-to-socket traffic?
Anything planned in this area?
Please sign in to leave a comment.