ZIA Connectwise Control SSL Inspection bypass

,

Hi All,

We use Connectwise Control cloud to access many of our unattended devices. The connectwise agents appear to use SSL Pinning so we need to bypass SSL inspection.

Here’s where we have an issue. Our connectwise instance has one static FQDN - instance-nXXXXX-relay.screenconnect.com

This is a CNAME record which points to an AWS FQDN that changes at least once a week.

Although we’ve bypassed instance-nXXXXX-relay.screenconnect.com from SSL inspection, we cannot use Screenconnect without finding out the underlying IP address or AWS instance FQDN which changes all the time.

These are my working theories so far but I was hoping that someone who has encountered a similar scenario could help out:

  • ZIA does not resolve CNAME records
  • ZIA doesn’t update CNAME records after they change or doesn’t update them fast enough
  • It has something to do with how the ZCC intercepts and rewrites DNS requests.

Resolved our issue. It wasn’t due to the load balancing or use of a CNAME record, but a misconfiguration on our end.

What was the misconfiguration? We also use ConnectWise. I attempted to bypass ssl inspection at first but no luck. Just started looking into it today.

@ChristianAnderson We used *.screenconnect.com but should have used .screenconnect.com

URL Format Guidelines | Zscaler

@jduan Thanks for getting back, ok I did see that also the formatting guidelines, so I created a user defined url category put .screenconnect.com in there then added a new ssl inspection policy for that url category to do not inspect and bypass other policies, it is last but the other policies before it don’t apply. I am still not getting successful connections on ZIA back to digging.

@ChristianAnderson Is your tenant upgraded to the granular SSL Inspection policies?

If so, the second last auto-generated rule should be “Inspect Remote Users”. The connectwise rule needs to be above that one.

Other than that:

  • Does the SSL bypass apply to all users/groups/locations or just specific ones?
  • Screenconnect agents take up to 30 mins to re-establish a connection.
  • Does adding the IP address of your screenconnect tenant work?

Sorry for the delay. Yep it was the IP it was looking for and it keeps changing. I have 4 so far and connectwise cannot guarantee a static IP.

Yeah, it happened to me again. I think part of the problem is that Zscaler must cache DNS responses. So, for the first 10-24 hours you need to use the actual IP.

I’ll figure it out when I have some time to dig further.

I reckon the only way to fix this is to use a PAC file to send Connectwise traffic direct. I’ve rolled this out to a test subset of our sites and will test the next time our tenant IP changes.

I confirmed traffic was not being blocked due SSL Inspection. The specific error in the logs was “Bad SSL record”. Our local DNS using Cloudflare upstrema was properly resolving the new Connectwise tenant URL.

However, bypassing the IP directly from SSL Inspection directly fixed the issue…

Connect Wise Screenconnect has a main URL Like below:
https://somecompanyname.screenconnect.com

which resolves to (Notice -web in the URL):
server-awsxxxxxxxx-web.screenconnect.com

When the App Launches, it shows another URL similar to:
instance-xxxxxx-relay.screenconnect.com
which resolves to:
server-awsxxxxxxxx-relay.screenconnect.com

I Created a FQDN group and included above 4. Also created a Wild Card Group with below:
.screenconnect.com

Then created an SSL Inspection Policy to do a Bypass (Including Bypassing all other inspection). And this seems to do the trick and we have no issues.

@bobby.jafari
I have the same bypass, except I haven’t included the server-awsxxxx… one. Will try this one and see if we have the same issue next time.

It works fine normally but ~8 hours after a Connectwise server upgrade ZIA appears to block CW. Only way to fix during these 8 hours is to add the IP address. Does yours work hours after a Connectwise server upgrade?

Update to this - bypasses didn’t work.

Connectwise updated again resulting in no access to most computers.

However, I noticed something interesting:

  • Computers with Z-Tunnel 2.0 did not lose connection.
  • Computers with Z-Tunnel 1.0 and an app forwarding PAC file bypassing .screenconnect.com lost connection.