In a typical ProxySG or Advanced Secure Gateway transparent proxy deployment with SSL interception, the LogMeIn service fails to connect.

LogMeIn is a live remote-assistance tool used by many companies to provide support. Users download a file,(Support-LogMeInRescue.exe) and they run it to initiate the connection. When the user is behind a transparent proxy, the connection fails. See the example below:

Disconnected
12:30PM Connecting...
12:30PM This session has expired and can no longer be used. To start a new session this applet must be downloaded again.

LogMeIn live remote support requires users to download a Java Applet component, then establish a connection with the remote support agent. This communication fails because it uses a connection TCP port 443 that is not actually using the SSL protocol. When the ProxySG detects this and attempts to decrypt it, the connection is broken. 

For example:
Policy trace show first POST request sent to secure.logmeinrescue.com/Customer/Download.aspx in order to download LogMeIn applet component.

connection: service.name=HTTPS client.address=<client IP> proxy.port=443
time: 2016-08-08 06:28:53 UTC
POST https://secure.logmeinrescue.com/Customer/Download.aspx
Referer: https://<Vendor Support site>/ServicePortal/...
User-Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko
url.category: Remote Access Tools@Blue Coat
server.response.code: 200
client.response.code: 200

Then in subsequent web requests, the LogMeIn application sends a GET request to secure.logmeinrescue.com (Notice that the user-agent string is Product=LogMeIn Rescue;Component=Applet)

connection: service.name=HTTPS client.address=<client IP> proxy.port=443
time: 2016-08-08 06:29:28 UTC
GET https://secure.logmeinrescue.com/myrahost/list.aspx?weighed=1
User-Agent: Product=LogMeIn Rescue;Component=Applet;Version=7.8.408.1842;LMIOS=854784;
url.category: Remote Access Tools@Blue Coat
server.response.code: 200
client.response.code: 200