Adobe Creative Cloud application installs fail when going through our Ironport web content filters

[Stafford Rau]

As the title says, when our users try to install Adobe applications via the new (and execrable) Creative Cloud software subscription service, those installs and updates fail when going through our Ironports with a lovely "download appears corrupted" message.

We're using WCCP on our core routers to redirect web traffic through the S370 proxies. When I exempt those users from web redirection (via the access list that controls wccp on those routers), the installs work correctly.

One of the frustrating parts of this problem is that none of the requests appear to be blocked. If I can trust the Creative Cloud app's progress bar, the application is completely downloaded and just starts to be extracted when the error occurs.

I did a packet capture on a client when the installation failed, but I didn't find anything particularly enlightening there.

Any suggestions would be most welcome.

[Luis Silva Benavides]

Hi,

Could you please share the access logs:

1. Grep
2. Enter the number of the log you wish to grep: 1 (for accesslogs)
3. Enter the regular expression to grep: <client IP>
4. Do you want this search to be case insensitive?: Y
5. Do you want to search for non-matching lines? N
6. Do you want to tail this log?: Y
7. Do you want to paginate the output?: N

Regards,

Luis Silva

[Dominick Converse]

The access logs show all communication as being open, no blocks or failures. The Creative Cloud manager connects and starts the updates but fails in the middle of a file download. Adobe states it is a proxy issue but there is nothing in the logs to reflect that assumption. The Creative Cloud logs state a communication failure has occurred. A network trace does not show any failures, the issue is within the manager software from what we have been able to figure out. The software updates work when they are completed manually without the Creative Cloud Manager using the same proxy appliances. 

Dominick Converse

[Matt Bowman]

We had the same issue. This is what I did as a work around for the Identities that needed Adobe Creative Cloud:

Create a Custom URL Category
Add .adobe.com to it Sites section
Submit

Assign the Custom URL Category to your Access Policy and Decryption Policy
(we have it set to monitor)
Submit, Commit, Commit

Test

I hope this helps,
-MB 

[Dominick Converse]

I have multiple users with the same issue, we are not decrypting the traffic and do not require user based authentication for any of the domains that are required. This has been confirmed by Adobe. Their tech support is totally clueless as to what the issue is and has been unable to assist. Has anyone found a workaround for the updates/ downloads?

Thanks

Dominick

[Handy Putra]

Adobe download is using range request download method that by default is disabled in WSA globally due to security reason.

If you need to enable this (CLI -> rangerequestdownload) however when you enable this there could be security disadvantage since the scanning engine might not be able to scan correctly due to small sizes per chunks that been downloaded (this will apply globally).

The other workaround is to create custom url category for adobe (.adobe.com) and set it to "Allow"

By setting to "Allow" this will bypass the scanning all together and simply allowing the traffics, therefore WSA will not inspect the range request download protocol/method that adobe is using (this will only apply to adobe not globally).

[Dominick Converse]

what scanning are we bypassing? The only scanning that I do on the WSA is WBRS, there is no malware or AV scanning on the WSA.

What security concerns would enabling rangerequestdownload expose?

[Ken Stieers]

With range requests enabled the WSA never has the whole file all at once so AV/malware scanning may miss things.   If you're not using that you don't lose anything.

[Dominick Converse]

Thanks Ken and Handy, let me give this a try and I will let you know.

[Dominick Converse]

I still have the same failures, updates get to 30-34% and then fail. Back to the drawing board.

[Ken Stieers]

At this point I'd open a TAC case.  They will want a packet capture so they can see what's really happening...

[Dominick Converse]

Ken, I may have found the answer to this issue I am waiting for Adobe to verify. It seems that the software attempts to make an inbound connection(s) to validate downloads and licensing. Adobe expects you to have a rule that allows inbound TCP port 80 & 443 from the internet for this to work be completed. We I requested a list of their ip's or subnets that may do this I was given a listing of 38 domestic subnets including full class 'B' networks. This would explain why the updates work when not behind the WSA and firewall on a home network.

Dominick

[Ken Stieers]

I'm sure there's some confusion there, because no one in their right mind would open that up like that...

[Dominick Converse]

I totally agree, 2 different support personnel at Adobe have given me a similar response. So I requested my ticket be escalated for the issue. That was 2 days ago. We took a sniffer trace between the workstation and the WSA and the WSA and the internet and find nothing wrong. We may need to do another trace at the firewall to see if we find an inbound attempt being dropped.

[Dominick Converse]

Ken,

Adobe confirmed that they require inbound access over port 80/443 for validation and verification during upgrades as stated in the below in the response:

"Our Applications require inbound connection if your Proxy network allows it without any issues and blockage for ports 80&443"

The only suggestion they made it to create an update server and let your user connect to the update server, but this server would also require the same connectivity.

Just wanted to let you know.

Thanks

Dominick