Using a reverse proxy, IP sprayer or load balancer

The diagrams in this topic shows a network topology where a reverse proxy resides in your DMZ and provides authentication services for the mobile device clients.

The first diagram represents a stand alone HCL Traveler server in this topology.

The second diagram shows the same network topology with a High Availability (HA) pool of HCL Traveler servers. In this case, the function of spraying or load balancing the device requests is provided by a separate server in the trusted domain.

The third diagram shows the network topology with the authentication proxy also providing the ability to spray the mobile requests to the HA pool of HCL Traveler servers. HCL Safelinx can provide the authentication proxy and request spraying capability.

This network topology does not allow as much flexibility as the VPN topology. However, it still provides a secure network implementation that does not expose any of the HCL Domino® server infrastructure to the Internet or DMZ zones.

HCL Traveler has been tested with several reverse proxy products, but most products providing a standard reverse proxy function should be adequate. These are some items to consider when selecting a reverse proxy:

• Verify that the reverse proxy is able to support a number of long-running HTTP connections equal to the mobile device clients that are in your network. When push is enabled on your mobile devices, they open an HTTP or HTTPS request to the server which remains open until a timeout occurs or new data arrives. This effectively means that the number of HTTP or HTTPS connections is equal to or slightly higher than the number of devices that are online. This model is different from a web browser, which typically opens a connection to retrieve a web page or image and then immediately closes the connection after the request is complete.
• If the reverse proxy is going to authenticate the mobile device credentials, it must be able to return an HTTP 401 response code for a failed authentication of the user credentials. The proxy must not return a user-oriented web page with an HTTP 200 (OK) response to the mobile devices. This is because the sync clients on the mobile devices are not able to interpret a user-oriented web page or form; instead, they rely on the standard Internet response codes that indicate authorization failure.
• Connections from the device to the HCL Traveler server use the HTTP GET, POST, and OPTIONS methods. Verify that all three methods are allowed.
• The web administration client requires HTTP GET, POST, PUT and DELETE methods. Verify that all four methods are allowed if you are using a proxy to also perform web based administration of the HCL Traveler server.
• The HTTP or HTTPS connections from the device may be long running (up to 30 minutes for push connections), so ensure that the proxy will allow the connections to be outstanding for that long and not time them out sooner.
• Ensure the HTTP OPTIONS response is coming from the HCL Traveler server and not the reverse proxy.
• Ensure an HTTP 449 response is not changed into a different HTTP response (for example, 500).
• Avoid HTTP 500 responses, as some devices will resync all of the data after multiple HTTP 500 responses. Usually, HTTP 503 responses can be used instead.
• Avoid HTTP 301 and 302 redirects, as the devices will, in response, often turn POSTs into GETs. By definition, a GET does not contain a body, so the body that was in the POST will be missing.
• The proxy server should not encode or decode URLs. Any URL to or from a HCL Traveler server should already be properly encoded. Encoding a URL twice may corrupt the URL arguments and make it unusable.
• Some Mobile Device Management (MDM) solutions use a proxy to control communications between the mobile device and HCL Traveler. If you are using such a solution, verify with your MDM vendor that it is capable of supporting all HCL Traveler applications on mobile devices or determine if there are known restrictions to what is supported by the MDM vendor. HCL Traveler supported applications use a variety of communications protocols, including Exchange ActiveSync and SyncML. General HTTP proxies do not examine the underlying data flows, but some MDM solutions require a specific underlying protocol for support. HCL Verse for Android and iOS, HCL Traveler To Do for iOS devices and Traveler Companion do not use the Exchange ActiveSync protocol and may not be supported by MDM vendors that only support Exchange ActiveSync capable applications.
• /Microsoft-Server-ActiveSync*, /servlet/traveler*, /traveler* should all be passed to HCL Traveler, and do not need to be mapped to anything in particular (Domino HTTP will do the mapping as necessary).