Has anyone had success implementing Traveler (primarily for iPhones and iPads) using the following approach:
DMZ separates the internal network from the Internet
External side of the DMZ is protected by a web application firewall (WAF) that also acts as a reverse proxy
Traveler sits inside the network (not in the DMZ)
Mail servers are all inside the network (not in the DMZ)
All communication between mobile device and Traveler server(s) use SSL
Our issue is sporadic connectivity problems. These problems happen more frequently if the 3G network is used, but they also happen sometimes when the device is connected via WiFi. We suspect latency is causing the issues, but we’re not sure what is causing the extra latency. IBM is not much help. they claim that everyone deploys Traveler easily with no issues like ours. They also claim that our setup is unique. Regardless, I’m fishing for some help here.
Subject: RE: Anyone with Traveler using DMZ and WAF/Reverse Proxy?
I’m on the IBM side, but let me add a few things…
Many customers are deployed with a proxy in the DMZ and Traveler/Mail servers internally. Given that, something is unique about your specific setup that is probably causing the problem - not having a proxy in general.
The range of proxies being used it pretty broad.
The most common problem is having the URL that the client is using to point to the Proxy instead of the Traveler server itself, but that completely breaks things - nothing sporadic about that. Thus, you must have that part working properly.
The most common problem with “sporadic” is normally HTTP threads (not enough of them). You might want to check the tuning and performance section of the doc for that.
Another frequent problem is the HTTP OPTIONS request which ActiveSync uses. Often it is blocked completely, but that appears to not be the case for you. The other problem with proxies is if they respond to the OPTIONS request instead of passing it on to the Traveler server. But again, it is sporadic and you had to do OPTIONS once to set it up in the first place, so OPTIONS is probably not the issue here.
If you use HTTP 302 redirects, the device will retry the POST as a GET and you will get WARNINGs in the Traveler console about the body of the message being missing. The server will return an error, the Apple will retry, and everything will work going forward (at least until the next 302).
When the connections don’t work, can you see them in the Traveler HTTP logs or Traveler servlet logs (you might want to change the servlet logging level to FINE to see the flows)?