This article applies to all versions of inSync Client.
Overview
In a closed environment, traffic to the public network is mostly routed through a Proxy in order to ensure that a secure communication reaches directly to its destination. In such an environment, you can create a PAC file to define how user agents can automatically choose the appropriate proxy servers to fetch a given URL.
This article talks about the restrictions that you need to follow when you modify the PAC file to ensure inSync Client communicates directly with inSync Cloud.
What happens if inSync fails to match rules mentioned in the PAC file?
In case of incorrect redirection of inSync to proxy server for cloud.druva.com in the PAC file, the clients may encounter the following issues:
inSync Client may not be able to communicate with cloud.druva.com, as it is not redirected to the proxy server.
Client directly tries to connect to the cloud if it fails to find a matching rule in the PAC file. This may lead to failure in authentication and backups.
Snippets similar to the following are saved to inSyncClientGUI.log file.
{snippet}
2018-02-08 16:43:05,309] [ERROR] Failed to connect DIRECTly to cloud.druva.com:80. Error: [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
{snippet}Considerations
Do not create URL rule for inSync in the PAC file to redirect all http, https, and ftp traffic to the proxy. Since inSync server name (cloud.druva.com) does not start with http or https, the above might not match and may re-direct inSync communication to public network directly.
Calls made by inSync are RPC calls and hence a URL rule for http or https in the PAC file may not work.
Define the following function in the PAC file.
if( shExpMatch(url, ".druva.com") {return "PROXY proxy.<FQDN>.com:<PROXYPORT>";} return "DIRECT";