Cisco 有一个不错的 IPSec 开销计算器（不幸的是，需要 CCO 登录）。

https://cway.cisco.com/ipsec-overhead-calculator/

根据您的 IPSec 设置和一些常见的选项，我们可以从中得出结论：

 8  PPPoE (optional, but widespread)
20  outer IP header
 8  NAT-T (optional, widespread, sometimes even default-on)
 8  ESP Header (4 SPI and 4 Sequence)
16  ESP IV
20  GRE IP Header (optional, check if implicitely enabled with your product)
 4  GRE Header (optional, check if implicitely enabled with your product)

... <IP MTU>, 
    incl IP (20), plus payload, being either of 
         TCP (20), plus payload
         UDP (8), plus payload
         ICMP (8), plus payload

 N ESP Padding (0-255, to adjust length from ESP Header to ESP ICV to to 32bit boundaries)
 1 Pad Length 
 1 byte  Next Header
16 bytes ESP ICV

在 MTU 1500 链路上，这些设置仅将您从 1500 降低 102 字节。添加一些 Padding 进行 32bit 对齐，您的 IP MTU 为 1392 甚至更低。考虑到 IP 为 20，TCP 为 20，这将导致最大 TCP 有效负载大小（又名 MSS）为 1352。

举一个不同的例子，下面是 Cisco 计算器的截图，它基于如果 MSS 被限制为 1382（加上 20b TCP 给出 1402 的“原始 IPv4 有效载荷”）并且没有任何“选项”在工作时会发生什么：

所有理智计算的预期 MSS 仍将是标准的 1472

不。在 IP MTU 为 1500 的链路上绝不会出现这种情况。

即使是两个直接连接的主机，具有直接以太网连接（以太网数据包大小为 1514 字节和 IP MTU 为 1500）也永远不会超过 1460 的 MSS。

要实际拥有 1472 的 TCP MSS，您需要 1512 的 IP MTU（如果在以太网上，则需要 1526 的 L2 MTU）。但是，1472 是 IPv4 中 UDP 或 ICMP 有效负载的最大大小，IP-MTU 的限制为 1500 字节。

使用 ping，您无法测量最大 TCP 有效负载大小。使用 ping 进行测试需要...

• 了解“大小”的给定命令行参数（以及测试结果）是否仅为有效载荷，有效载荷包括。ICMP 标头或有效载荷，包括。ICMP 报头和 IP 报头。这可能因 ping 实现而异。
• 了解由此产生的最大“大小”不是TCP MSS。
• 确定 PMTUd 在路径上的路由跳数上起作用。
• 确保 IPSec 隧道端点不会通过分段破坏您的测试结果，尽管 ping 尝试沿路径进行 PMTU-discover。
• 请记住，虽然给定链路/段的 MTU 通常在两个方向上都是对称的，但路径 MTU 是一个单向概念，并且在返回路径上可能不同。

所以我建议你检查/验证这些：

• 一定要知道任一端是否有 PPPoE（-8 字节）
• 检查 NAT-T 是否用于给定隧道（-8 字节）。如果任一隧道端在 NAT 设备后面，就会有 NAT-T）。检查给定的产品是否默认为 NAT-T。
• 检查给定的产品或配置是否添加了 GRE 标头（-24 字节）。
• 请务必了解产品或配置是否“忽略 df-bit”（或者同样，术语因供应商而异）。请务必了解这如何抵消任何“让我们检查该隧道的 MTU”尝试，甚至削弱 PMTUd。
• 使用 IPSec 开销重做一些计算（见上文）并留下一些用于填充，或者使用 cisco 的计算器。

对于申请，请考虑：

• 请务必了解所讨论的应用程序是使用 UDP 还是 TCP 或两者的组合，如果是，则该应用程序使用哪种特性/功能。
• 在 MTU 减少的链路上，MSS 钳位可以帮助 TCP。
• 在 MTU 减少的链路上，UDP（以及 ICMP）必须要么依赖 PMUTd（最多是不完整的）要么依赖于应用程序配置来减少每个数据包的最大负载。
• 仅将“df-bit ignore”用作最后一个非常丑陋的非解决方案，这会破坏 PMTUd。

简而言之：MSS 钳位 1382 并不遥远。有些防火墙供应商默认为 1350。

[评论后添加]

关于 TCP MSS 钳位与 PathMDU-Discovery

是的，TCP MSS 钳位是完全正常的。

有些产品默认执行（Cisco ASA、Fortigates），有些仅在显式配置（基于瞻博网络 ScreenOS 的设备、Cisco IOS 路由器）后执行 - 我无法为其他人说，从我的头顶。

TCP MSS 钳位可能被认为是一种麻烦，但根据我的经验，它比 PMTUd 更可靠、更快地完成工作，因此我认为这是一种祝福。

PMTUd 取决于中间跳所生成的ICMP 分段所需的数据包，并将其成功传送回数据包源，以及在源主机上正确解释错误消息。

所需要的只是一个顽固的安全管理员（“ICMP 无法访问总是很糟糕，我好吗？”）或损坏的 NAT 实现（“哎呀，传入的 ICMP 无法访问？我不知道如何将其与任何会话匹配，让我们放弃它！ " ) ，甚至一个简单的 TCP/IP 堆栈（打印机，有人吗？）无法解析 ICMP 碎片所需的消息。沿路径或末端系统中的任何一个，PMTUd 都会死得很惨。

然而，TCP MSS 钳位是即时的：MSS 仅在初始握手期间交换，并且钳位器操作 TCP 中的 MSS 字段时如此轻微的延迟将不再被注意到，之后。事情只会随着有效负载和数据包大小的减少而嗡嗡作响...... [2]

另一方面，PMTUd 可能会有一些延迟。SYN、SYN-ACK 和客户端的请求 [3] 数据包可能仍远低于 PathMTU。即使是服务器响应的前几个数据包也可能小到可以偷偷通过而不会出现碎片。当大量数据传输即将开始时，这会变得缓慢。

另外：请记住，“接收需要的 ICMP 碎片”数据包和供应商执行“df-bit ignore”的方式可能是独立的。

一个实现可能仍然选择实现“无论如何让我们把那个东西分片，但也发送一个‘需要分片’并希望他们对它做出反应并在下次发送更小的块”的策略。

要发现此类行为，您可能必须在目的地提取数据包转储，并查看接近/位于/超过 PathMTU 大小的数据包是否到达以及有多少碎片到达。[4]

关于应用程序行为

是的，无论如何，请调查在该 MTU 缩减路径上存在问题的应用程序。

如果TCP在使用时，一定要检查两个SYN和SYN-ACK的MSS值两个TCP会话的结束。如果任何一方看到传入的MSS 值大于减少的 MTU 路径上的值，事情就会变得很糟糕。

另外：仔细检查 PathMTU 发现是否在两个方向都有效：分支站点的防火墙告诉客户端发送较小的数据包很好。在总部/数据中心的一端，也应该有人告诉服务器。同样，PathMTU 是一个单向概念。

另外：验证路径上是否有负载平衡器或“WAN 加速器”（或任何其他充当意外“中间 TCP 端点”的东西。我已经看到其中一些对 TCP 做了可怕的事情，使应用程序瘫痪学位让我想为开发人员和运行它们的无能操作员做一些难以形容的事情。

简而言之：在两个端点上的 TCP 扬声器上捕获几秒钟的流量，然后看看一旦出现问题会发生什么。比较它们离开时的数据包以及（如果和）它们如何到达各自的另一端。查找片段、更改的 IP 和 TCP 标头字段、丢失的数据包、重新传输。

[2] ...如果路径的 MTU 发生变化，就会陷入混乱，因为重新路由刚刚发生在 WAN 中的某个地方，并且正在使用具有更低 MTU 的链路。不能拥有一切，是吗？

[3] 请注意：TCP 本身没有“客户端”或“服务器”的概念。对于TCP，只有一个“发起者”和一个“响应者”。然而，通常应用程序客户端充当发起者，而服务器通常是响应者。

[4] 如果你真的需要深入研究：在实验室环境中复制设置，并使用“ESP-NULL”而不是 AES-256。给予或接受一些改变的字段长度和可能稍微少一点的开销，隧道端点将完成整个 IKEv2 和 IPSec 的事情（好吧，没有一些“Sec”部分），然后你可以数据包捕获（不完全）加密的流量和查看防火墙的 WAN/Internet 端实际发生的情况。

[评论后添加]

真的真的很晚更新，但我忙于其他任务（MS365 迁移、最近的软件漏洞等），所以哎呀我没有解决这个问题。

MTU 信息帮助我们走上了狩猎之路，但随后又转向了“这到底是怎么回事？” 当我们与 Sophos 讨论这个问题时登陆 - 我们实际上有一名工程师在线。事实证明，当您在 XG 上启用多个 IPSec 隧道时，所有 VPN 隧道共享一部分带宽和 MTU 以及传输速率。这不是记录在案的行为。

通过防火墙规则清理和迁移到 XG 防火墙内置的 XG RED 隧道软件的计划，这将解决速度问题。

不过，MTU 问题确实似乎是一个红鲱鱼，因为它让我们找到了其他信息。但这表明 XG 造成的其他混乱以及为什么他们更喜欢您使用他们专有的 RED 机制……我猜 Sophos 做事很奇怪。