我们有一个访客 wifi 网络，位于防火墙上的类似 DMZ 的区域中。我们的 Exchange 2010 服务器位于防火墙的“内部”区域，对“外部”区域的公共 IP 地址进行 1-1 NAT。
自动发现和 Activesync 在“外部”的所有情况下都能正常工作（请注意，这意味着 Microsoft 远程连接分析器通过了所有测试）。
从访客 wifi 区域到 Exchange 服务器所在的内部区域涉及防火墙外部接口上的“发夹”或“掉头”，因为访客 wifi 客户端使用公共 DNS 进行自动发现和 Activesync（我们不当然，希望客人能够看到我们的内部 DNS）。防火墙制造商 (Palo Alto) 有一个我遵循的 u-turn 配置的配置指南，除了一个怪癖之外，它可以工作：
访客 wifi 上的 iOS 设备可以使用适用于 iOS 的 Microsoft Outlook 应用程序连接到 Exchange 以进行自动发现和 Activesync，但不能使用内置 iOS 邮件应用程序使用自动发现或 Activesync。
我无法弄清楚为什么这两者的行为或工作方式会有所不同。到目前为止，我一直怀疑 Apple 正在尝试使用不同的端口或其他东西进行同步，即使我的期望只是 HTTPS 443 并且（可能）需要 HTTP 80。目前，我从来宾 wifi 区域向 Exchange 服务器开放的端口是 80、443 和 143（对于 IMAP 作为暗中的刺）。
在 Activesync 方面，Outlook for iOS 和 iOS Mail 有什么区别？
编辑 - 更多信息
我已经做了几件事来试图弄清楚这一点。首先，我打开了访客 wifi 区域和 Exchange 服务器之间的所有端口，但没有任何改变。这让我觉得 u-turn 配置可能无法正常工作，但 Outlook for iOS 应用程序正在解决这个问题。
其次，我过滤了从访客 wifi 区域到 Exchange 服务器的连接的防火墙日志，并且没有任何记录，即使 Outlook for iOS 应用程序正在检索邮件。
所以我目前的理论是，微软通过允许它使用一种 Activesync 代理服务来帮助它在所有情况下或类似的情况下到达目标服务器，从而在他们的 Outlook for iOS 应用程序中建立了一些弹性。
Outlook 应用程序不直接连接到 Exchange - 这就是区别。
Outlook 应用程序的所有流量都流向 Microsoft 控制下的服务器（它们在 Amazon AWS 中，我认为它们现在已被带到 Azure）。然后，Microsoft 服务器会连接到您的 Exchange 服务器。
适用于 iOS 和 Android 的 Microsoft Outlook 应用程序基于另一个名为 Accomli 的应用程序，该应用程序是 Microsoft 于 2014 年购买的。这是一篇关于它的担忧的旧博客文章（唯一改变的是使用的数据中心）：
https://blog.winkelmeyer.com/2015/01/warning-microsofts-outlook-app-for-ios-breaks-your-company-security/
您需要再次检查您的防火墙配置 - 以便您的内部服务器的流量以正确的方式流出。