我们有一个访客 wifi 网络，它位于防火墙上的类似 DMZ 的区域。我们的 Exchange 2010 服务器位于防火墙的“内部”区域，而“外部”区域中的公共 IP 地址则采用 1-1 NAT。
Autodiscover 和 Activesync 在所有“外部”情况下都能正常工作（请注意，这意味着 Microsoft Remote Connectivity 分析器通过了所有测试）。
从来宾 wifi 区域进入 Exchange 服务器所在的内部区域，需要在防火墙的外部接口上进行“发夹弯”或“掉头”，因为来宾 wifi 客户端使用公共 DNS 进行自动发现和 Activesync（当然，我们不希望来宾能够看到我们的内部 DNS）。防火墙制造商（Palo Alto）有一个掉头配置指南，我已遵循该指南，并且该指南有效，除了有一个怪癖：
访客 Wi-Fi 上的 iOS 设备可以使用 iOS 版 Microsoft Outlook 应用程序连接到 Exchange 进行自动发现和 Activesync，但不能使用内置 iOS 邮件应用程序的 Autodiscover 或 Activesync。
我不明白为什么这两个端口的行为或工作方式会有所不同。到目前为止，我怀疑 Apple 正在尝试使用不同的端口或其他东西来同步，尽管我的预期是只需要 HTTPS 443 和（可能）HTTP 80。目前，我从来宾 wifi 区域向 Exchange 服务器开放的端口是 80、443 和 143（用于 IMAP，作为盲目的尝试）。
就 Activesync 而言，iOS 版 Outlook 和 iOS Mail 有何区别？
编辑-更多信息
我做了几件事来试图弄清这个问题的根源。首先，我打开了来宾 WiFi 区域和 Exchange 服务器之间的所有端口，但什么都没有改变。这让我觉得可能是 U 型转弯配置不起作用，但 iOS 版 Outlook 应用却以某种方式解决了这个问题。
其次，我过滤了从访客 WiFi 区域到 Exchange 服务器的防火墙日志，没有任何记录，即使 Outlook for iOS 应用正在检索邮件。
所以我目前的理论是，微软在其 Outlook for iOS 应用程序中构建了一些弹性，允许它使用一种 Activesync 代理服务来帮助它在任何情况下到达目标服务器，或类似的东西。
答案1
Outlook 应用程序不直接连接到 Exchange - 这就是区别。
Outlook 应用程序的所有流量都流向 Microsoft 控制下的服务器（它们之前位于 Amazon AWS，我认为现在已移至 Azure）。然后，Microsoft 服务器会连接到您的 Exchange 服务器。
iOS 和 Android 版 Microsoft Outlook 应用基于另一款名为 Accomli 的应用，微软于 2014 年收购了该应用。这里有一篇关于该应用的担忧的旧博客文章（唯一改变的是所使用的数据中心）：
您需要再次检查您的防火墙配置 - 以便您的内部服务器的流量以正确的方式流出。