Having turned on Symantec Cloud Sandboxing. there has been no information on whether it works or not.
How do we make sure that the Cloud Sandboxing works, and where can we check for the outward requests on CAS.
We tried Packet Capture for Cloud Sandbox URLs/IPs, but there isn't any traffic.
CAS 3.2.x.x
With a Proxy integration:
SSL interception should be bypassed for all cloud-related Symantec Malware Analysis (sandboxing) traffic, especially for Symantec Content Analysis System (CAS) communicating with Symantec Cloud Sandboxing.
Analyzing the log with that in mind:
Curl failure 35 – SSL connect errorUsually indicates TLS handshake failure due to:
Curl failure 3 – URL malformationCan be a secondary error caused when initial HTTPS connection setup (like hash query) fails.
Without a Proxy integration
If there is no proxy in the deployment, then SSL interception is not occurring, and the recommendation to bypass SSL interception becomes irrelevant in this context.
That said, the core issue still remains:
So let's reevaluate what could cause this in a no-proxy environment.
Updated Root Cause Analysis (No Proxy in Path)
Curl failure 35 - SSL Connect Error:
This still indicates that CAS is unable to establish a valid SSL/TLS session with the Symantec Cloud Sandboxing endpoint.
With no proxy in place, the most likely causes are:
Potential Causes & Checks:
1. Firewall Blocking or Interference
2. Invalid or Missing CA Certificates on CAS
3. DNS Issues
<you_custom_domain_1> or *.<you_custom_domain_2> to a wrong IP or fails to resolve it at all, the HTTPS request can fail./var/log/messages or equivalent DNS logs.4. Incorrect System Time on CAS
5. MTU/MSS/Path MTU Discovery Issues
With a Proxy integration:
Why Bypassing SSL Interception is Crucial
When CAS connects to Symantec Cloud Sandboxing (e.g., https://<you_custom_domain_1>, *.<), it performs strict certificate validation. If a proxy like the Edge SWG (ProxySG) is intercepting and re-signing this traffic:you_custom_domain_2>
Recommended Action (Resolution):
On your ProxySG (or any upstream SSL intercepting device):
==> Create an SSL Bypass rule for the following domains/IPs used by CAS for Cloud Sandboxing:
https://<you_URL_1>https://<you_URL_2>https://<you_URL_3>See sample SSL Bypass CLP script below. Replace x.x.x.x/y with the actual IP/mask, and add more lines, if there are more.
;===========For Explicit Deployments ===========================================
<proxy>
condition=cloud_sandbox_Allow detect_protocol(no) authenticate(no) ALLOW
define condition cloud_sandbox_Allow
url.domain=<domain_1>
url.domain=<domain_2>
url.domain=<domain_3>
url.domain=<domain_4>
url.domain=<domain_5>
url.domain=<domain_6>
url.domain=<domain_7>
url.address=x.x.x.x/y
end
;===============================================================================
After Bypassing:
Curl failure 35 should disappear if interception is bypassed properly.
Verification Test:
If you're unsure whether SSL interception is causing this:
Without a Proxy integration:
Recommended Actions (Summarized)
| Action | Command / Interface | Notes |
|---|---|---|
| Test connectivity to cloud sandbox endpoint | From CAS CLI: curl -Iv https://< or equivalent tool |
See if TLS handshake succeeds |
| Verify DNS resolution on CAS | nslookup < or check DNS logs |
Must resolve correctly |
| Verify time sync (NTP) | Admin Console → System → Time Settings | Time skew breaks SSL |
| Check firewall or perimeter filtering | Firewall config | Make sure nothing inspects or blocks outbound TLS |
To double check the integration on CAS side, please refer to the Tech. Docs with the URLs below, as reference.
Integrate Content Analysis with Symantec Messaging Gateway