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)
To resolve this issue, you will need to exempt LogMeIn from being SSL-intercepted. Apply the following Content Policy Language (CPL) to disable SSL Interception based on the Server certificate hostnames of