Why Exchange ActiveSync fails with NAT firewalls
Brien Posey, Microsoft Exchange MVP
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
When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by Exchange professionals today working with Exchange, Outlook and other related technologies.
Margie Semilof, Editorial Director
Premium Access
Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy
Dig Deeper
-
People who read this also read...
-
This was first published in May 2008
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 using 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.
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.
| 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.
|
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.
Disclaimer:
Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
