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 traffic that will directly egress to the Internet instead of being routed to the Cato Cloud. Bypassed 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 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.
The Preferred Socket Port feature is supported from Socket v15.0 and higher.
Note
Note: Bypassing Internet traffic is only supported for Socket and vSocket sites.
To define a bypass rule:
-
From the navigation menu, click Network > Sites and select the site.
-
From the navigation menu, click Site Settings > 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 Settings > 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.
7 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.
Please sign in to leave a comment.