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 IBM Traveler server in this topology.


Reverse Proxy

The second diagram shows the same network topology with a High Availability (HA) pool of IBM 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.


Reverse Proxy HA

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 IBM Traveler servers. IBM® Mobile Connect can provide the authentication proxy and request spraying capability.


Reverse proxy HA sprayer

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 IBM® Domino® server infrastructure to the Internet or DMZ zones.

IBM 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 IBM 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 IBM 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 IBM 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 IBM 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 IBM Traveler. If you are using such a solution, verify with your MDM vendor that it is capable of supporting all IBM Traveler applications on mobile devices or determine if there are known restrictions to what is supported by the MDM vendor. IBM 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. IBM Verse for Android and iOS, IBM 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 IBM Traveler, and do not need to be mapped to anything in particular (Domino HTTP will do the mapping as necessary).
When using a reverse proxy, administrators must make sure to set the external URL in the IBM Traveler server document, as explained in Server document settings.
Note: If you are using MobileIron and setting up IBM Traveler ToDo and IBM Traveler Companion, see this article for considerations on how to set the External URL setting.

Tested environments

  • IBM® Mobile Connect 6.1. provides an HTTP access service that functions as a passthru for mobile devices using HTTP or HTTPS to a dedicated server resource inside the intranet. See the topic HTTP access services in the IBM® Mobile Connect documentation for more information.
  • IBM® Websphere Edge server version 6.1

IBM Traveler custom HTTP headers

The following is a list of the custom HTTP headers that IBM Traveler uses. In general, proxies should not be removing any HTTP response headers, but if you are going to remove some, ensure they are not on the list included below:
  • X-IBM-BusySignal
  • X-IBM-CHANGEDEVICEID
  • X-IBM-ESS-RESPONSETIME
  • X-IBM-GETSTATUS
  • X-IBM-GENERATEDEVICECONFIG
  • X-IBM-PW-EXPIRATION
  • X-IBM-TRAVELER-AFS-CALENDAR
  • X-IBM-TRAVELER-AFS-MAIL
  • X-IBM-TRAVELER-COMMANDS
  • X-IBM-TRAVELER-HOST
  • X-IBM-TRAVELER-HTTP-TIME
  • X-IBM-TRAVELER-ERROR-MESSAGE
  • X-IBM-TRAVELER-MONITOR-LID
  • X-IBM-TRAVELER-PING
  • X-IBM-TRAVELER-PUSH-HTTP

IBM Traveler return codes

The following is a complete list of return codes that are used by the IBM Traveler server. It is required that any network equipment being used not intercept or alter these return codes.
  • 200 OK
  • 401 Authentication required or failed
  • 403 Access forbidden
  • 404 Request not found
  • 408 Sync timeout
  • 409 Sync resume (after timeout)
  • 449 Provision
  • 500 General server error
  • 503 Server Busy