我们有一个客户wifinetworking，在防火墙的DMZ区域。 我们的Exchange 2010服务器位于防火墙的“内部”区域，在“外部”区域中有1-1个到公用IP地址的NAT。
自动发现和Activesync在“外部”的所有情况下都能正常工作（请注意，这意味着Microsoft远程连接分析仪可以通过所有testing）。
从客户wifi区域到Exchange服务器的内部区域涉及防火墙的外部接口上的“发夹”或“掉头”，因为客户端WiFi客户端使用公共DNS进行自动发现和Activesync（我们不希望客人能够看到我们的内部DNS，当然）。 防火墙制造商（Palo Alto）有一个关于掉头configuration的configuration指南，这个configuration指导是我遵循的， 除了一个怪癖外 ，
来宾WiFi上的iOS设备可以使用适用于iOS的Microsoft Outlook应用程序连接到Exchange以进行自动发现和Activesync，但无法使用内置iOS Mail应用程序使用自动发现或Activesync。
我无法弄清楚为什么这两个行为或工作不同。 到目前为止，我一直怀疑苹果公司试图使用不同的端口或者其他的东西来进行同步，尽pipe我的期望只有HTTPS 443，而且可能还需要HTTP 80。 目前，我已经从客户wifi区域开放到Exchange服务器的端口是80,443和143（IMAP在黑暗中刺戳）。
用iOS和iOS Mailpipe理Activesync有什么区别？
我已经做了一些事情来试图达到这个目的。 首先，我打开了客户wifi区域和Exchange服务器之间的所有端口，没有任何改变。 这让我觉得，掉头的configuration可能不工作，但不知何故，Outlook的iOS应用程序正在解决这个问题。
其次，我过滤了防火墙日志，以便从客户wifi区域连接到Exchange服务器，并且没有任何logging，即使Outlook for iOS应用程序正在检索邮件。
所以我现在的理论是，微软已经build立了一些弹性到他们的Outlook的iOS应用程序允许它使用一种Activesync代理服务，以帮助它到达目标服务器在所有情况下，或类似的东西。
Outlook应用程序不直接连接到Exchange – 这是不同的。
Outlook应用程序的所有stream量都是由微软控制的服务器（他们在亚马逊AWS，我认为他们现在已经被带到Azure）。 Microsoft服务器然后连接到您的Exchange服务器。
用于iOS和Android的Microsoft Outlook应用程序基于另一个名为Accomli的应用程序，Microsoft在2014年购买了这个应用程序。以下是关于它的一个旧博客文章（唯一改变的是使用的数据中心）：
您需要再次查看您的防火墙configuration – 以便您的内部服务器的stream量以正确的方式出去。