You can install the Secure Email Gateway (SEG) in a Demilitarized Zone (DMZ) or behind a reverse proxy server. The reverse proxy configuration is preferred when the DMZ configuration is not feasible.

If SEG is installed in the DMZ, you can use an optional setting detailed in the installation wizard to proxy webmail traffic. In a reverse proxy server configuration, the reverse proxy handles webmail traffic.

SEG is an on-premises component that you install as part of your own organization's network. The SEG Proxy model requires Exchange ActiveSync infrastructure. For example, Microsoft Exchange 2010/2013/2016, Lotus Traveler, and Novell GroupWise Data Synchronizer. Please consult your AirWatch representative for more information.

Note:

AirWatch only supports the versions of third-party email servers currently supported by the email server provider. When the provider deprecates a server version, AirWatch no longer supports integration with that version.

Recommended Setup: Exchange ActiveSync SEG Configuration

AirWatch best practices support this configuration. The SEG is placed in the DMZ for routing mobile email traffic.

Recommended EAS SEG Setup

 

Alternative Supported Setup: Exchange ActiveSync SEG Using Optional Reverse Proxy Configuration

The reverse proxy configuration uses an optional reverse proxy to direct mobile device users to the SEG Proxy while routing browser users directly to their webmail endpoints. Use the following network configuration to set up the reverse proxy to communicate between devices and the SEG using the Exchange ActiveSync (EAS) protocol. This configuration should be used in cases where the recommended setup is not feasible.

EAS SEG Setup using Reverse Proxy

Recommendations for Reverse Proxy Configuration

You can configure SEG to work with reverse proxy server in a normal fashion. You can set up load balancing between the SEGs and reverse proxy, but take care to configure the load balancers in front of the Central Authentication Service (CAS).

  • IP based affinity: Configure IP based affinity if you are using Certificate authentication and there is no proxy or other component in front of the load balancer that changes the source IP from the original device.
  • Authentication Header Cookie based Affinity: If you are using Basic authentication, especially if there is a proxy or other network component that changes the source IP from the original device.

For more information, please see:

Exchange ActiveSync is a stateless protocol, and persistence is not explicitly required by MSFT. The best method of load balancing may vary from implementation to implementation.

Configuration

  • Generally, they may be set to do a round-robin on the CAS with a persistence based on the source IP address. This works well when devices connect directly to the reverse proxy but causes issues when you place a SEG in front of it. Suppose you have one or two SEGs and the source IP as far as the load balancer in front of the CAS that is concerned will also be one or two. Hence, this can damage the load balancing and all the traffic can end up going to one or two CAS.
  • Another issue that can arise is if there are some kind of limits set up on the reverse proxy server. For example, on an Internet Security and Acceleration (ISA) server, the default number of concurrent connections accepted from a single IP address is about 150. You need to set this to at least 5000 connections. On an ISA server, this can be set up under the Flood Mitigation settings.