Implementing ActiveSync in an Exchange 2003 organization facilitates mobile device synchronization. However, doing so in an environment that has Exchange 2003 servers located behind a network address translation (NAT) firewall causes synchronization failures. There's no single solution for this ActiveSync issue, but understanding why ActiveSync fails with NAT firewalls can help in the troubleshooting process.
The basic idea behind NAT is that there aren't enough IPv4 addresses to go around, so most ISPs give subscribers a single, publicly accessible IP address. This address is assigned to the NAT firewall, and all machines behind the firewall have private IP addresses that are only valid from within the network perimeter.
When a machine needs to communicate externally, it sends the request to the NAT firewall. The NAT firewall then acts as a proxy and makes the request on behalf of the machine. When the response comes back, the NAT firewall forwards the response to the requesting machine.
When servers are made available to the outside world, but those servers are behind a NAT firewall, port forwarding is often used. For example, an organization may have an Exchange server behind a NAT firewall, and that server must be able to receive external SMTP messages.
In such a case, the MX record on the DNS server that is authoritative for the domain would point to the NAT firewall, not to the Exchange server itself since that IP address isn't accessible externally. The NAT firewall is then configured with a port-forwarding rule that forwards any inbound SMTP traffic to the Exchange server's private IP address.
The first problem with u...
To continue reading for free, register below or login
To read more you must become a member of SearchExchange.com
sing Exchange ActiveSync in conjunction with NAT is that many ISPs only lease dynamic IP addresses. For example, the ISP that I use reassigns IP addresses every few hours to prevent subscribers from hosting their own servers.
Frequently changing public IP addresses can cause some problems with trying to host services, because the DNS records for the domain must point to the organization's public IP address. There are technologies for keeping DNS records up-to-date, but some mobile devices cache DNS records. This cache may not be renewed frequently enough to keep pace with IP address changes.
If you have static IP addresses and Exchange ActiveSync isn't working correctly, then the problem most likely is related to your SSL certificates. Typically, when you enable Exchange ActiveSync, wireless clients synchronize using SSL encryption. SSL encryption requires the use of an SSL certificate, which contains the server's fully qualified domain name (FQDN) and IP address. This can be problematic.
When clients attempt to synchronize, they connect to the NAT firewall, not directly to the Exchange Client Access server (CAS). The NAT firewall forwards the request to the server, which responds. The server attempts to establish SSL encryption using its certificate. However, the server's output is proxied back through the NAT firewall, which has a different IP address than the server.
Because the organization has one public IP address, that address is used for all outbound communications. The client thinks that the response is coming from the NAT firewall's IP address, rather than the Exchange server's IP address. The SSL certificate contains the server's IP address; therefore, the client thinks the certificate is invalid.
One solution for this involves creating a host entry on the mobile device that maps to the FQDN to which the SSL certificate is assigned. Windows Mobile devices don't support the use of host files, but you can add the necessary host record to the device's registry. Host information can be entered into the mobile device's registry at: HKEY_LOCAL_MACHINE\comm\tcpip\host.
Another possible solution is to replace your NAT firewall with an ISA Server. This is a viable option because ISA Server can act as a NAT firewall and offers a feature called SSL bridging, which allows the end user to establish an SSL session with the ISA Server. It doesn't have to establish the session with the Exchange server that sits behind it. The ISA Server can establish a separate SSL session with the Exchange server and act as a type of SSL proxy.
Configuring SSL bridging can be tricky because you must export your Client Access server's SSL certificate and add it to the ISA Server's certificate store. Microsoft offers more information on SSL bridging.
MEMBER FEEDBACK TO THIS EXCHANGE MOBILITY TIP
Just a thought... I think this whole problem can be solved with 1) a static IP and 2) an SSL certificate from a recognized authority -- e.g., Thawte, which references the outside public IP. This 'blows up' internal SSL access like OWA, but it can be easily fixed by permanently accepting the certificate.
This method also blows up Exchange public folder access from Exchange System Manager. But this too is easily fixed. It works like a champ for the 40+ sites we have running this configuration.
—Eric H.
About the author: Brien M. Posey, MCSE, is a four-time recipient of Microsoft's Most Valuable Professional Award for his work with Windows Server, Internet Information Server (IIS) and Exchange Server. Brien has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit Brien's personal web site at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
