Adobe Connect 11, Chrome and Smoothwall

[_techie_]

Hi.

 

Trying to resolve an issue with Adobe Connect, STEM Learning, and Hosting a meeting using the Adobe Connect App.

I have basically given everything I can give to the user who needs this (including removing HTTPS Inspection for the user and PC). This is without bypassing Smoothwall itself via 4G - my backup plan.

The issue seems to be when trying to launch a new adobe connect session (using the app) and haults at about 80% at 'preparing room'.

 

Deploying the app worked fine by the admin MSI from Adobe (it seems the version we are on is: 20.10.26).

Running the diagnostic afterwards: Test Meeting Connection passes without issue.

I have added in adobe.com and adobeconnect.com to our Exceptions URL's list on Smoothwall to remove some 407 errors from the PC's IP address, but so far no joy.

 

The only thing I can see from the web-filter logs seems to be a few https://IP Address here entries, which keep changing. I keep adding these into the https transparent incompatible sites category, but no joy so far, as they keep changing.

 

About to try with a laptop, and 4g hotspot, so here goes.

 

Anyone else struggling to get STEM Learning and Adobe Connect to work?

 

Cheers

[ibpalle]

Hi _techie_

 

Is this with using proxy settings on the client or relying on transparent proxy? If transparent, could you edit the transparent proxy policy and tell what the HTTPS method is set to in the drop down list?

[_techie_]

Hi.

 

Yes, this is using proxy settings set in the browser.

However, I have also set an "Ident by location" on the IP range/CIDR that the PC is sitting on (this is mainly to deal with Teamviewer requests) to match the users Group.

The user group is set not to inspect on HTTPS traffic (so this should allow the PC through without inspecting too).

 

The issue seems to stem from a rotating https non compatible site IP that changes each time the adobe connect meeting is launched.

 

I'm baffled on this one to be honest.

[_techie_]

Hi.

 

Just checked the IP against the HTTPS inspection policies. I had forgotten I had recently changed the IP of this PC, so the range wasn't included in the HTTPS inspection policy, to do not inspect.

Just updated this, and will come back to you.

 

Thanks,

[_techie_]

Still the same issue with the room loading and getting stuck, grr how frustrating!

Still same https://IP Address issue when the room is loading!

[ibpalle]

What is the HTTPS method set for the transparent proxy? Edit the auth config for the transparent proxy - it should not be set to 'Block HTTPS traffic with no SNI header'

[_techie_]

Nope, set to allow Transparent HTTPS compatible sites for that location on the transparent.

[ibpalle]

Could you set it to 'allow Transparent HTTPS compatible sites and filter others by certificate' and see if that makes a difference?

[_techie_]

Hi.

 

I'll give that a whirl and see what gives.

 

Cheers

Mark

[_techie_]

GREEAAT, that works perfectly!

What does this behaviour do differently to the normal Allow Transparent HTTPS Compatible sites?

I'm interested in how this works and whether I should be allowing it or not?

 

Thanks,

[ibpalle]

The addition of 'Filter others by certificate' allows HTTPS using a certificate that can be validated to pass into the proxy even though SNI info is not present or ID info is not correct. The option is meant to match any HTTPS traffic which isn't in our transparent compatible sites due to range of IPs being too wide or other reasons, basically relying on the fact that if the certificate used is valid, we will let it use the proxy. This does not allow it through Guardian by default - the Guardian filtering still applies after this check has been done.

 

So yes, you should use this option - it can be the only method as valid HTTPS traffic will use a certificate that can be validated, even for most of the software that use I target IPs that ware in the transparent incompatible sites.