我们有一个客户，其 6 个站点均使用 IPsec。有时，可能每周一次，有时每月一次，数据会突然停止从远程 Fortigate VPN 服务器流向本地 MikroTik IPsec VPN 客户端。
为了演示问题的症状，我附上了一张图表。在图表的“已安装 SA”选项卡上，您将注意到源 IP 地址 xx186.50 正在尝试与 xx7.3 通信，但当前字节为 0。xx186.50 是客户端的远程 Fortigate IPsec 服务器，而 xx7.73 是基于 MikroTik 的 IPsec 端点。看来从远程端到我们的数据并不总是流动的。
第 1 阶段和第 2 阶段始终能够建立，但是流量始终拒绝从远端流向我们。
我们尝试了各种方法，比如重启、设置时钟、修改配置、反复检查配置，但问题似乎完全是随机的。有时随机方法可以解决问题。我曾一度认为，如果隧道是从他们那边发起的，那么隧道就可以正常工作，但摆弄“发送初始联系”并没有任何效果。
我们已经与客户就此问题进行过多次交流，但他们有更多的国际 IPsec VPN，只有我们的 MikroTik 配置失败了。
Fortigate 日志：
http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654
查看 Fortigate 的知识库，似乎 SPI 不一致，DPD 会产生影响。但我尝试了这边的每种 DPD 组合，但都无济于事。我想在另一边启用 DPD，但由于更改控制，以及客户端说它在所有其他站点上都以完全相同的配置工作，所以我无法启用。EDIT DPD 已启用
本地 VPN 客户端图表显示没有流量：
我已包含一个日志文件，其中显示了“收到有效的 RU-THERE，已发送 ACK”的连续循环 MikroTik 日志文件：
echo：ipsec，debug，数据包 84 字节从 xx7.183[500] 到 xx186.50[500]
echo：ipsec，debug，数据包套接字名称 xx7.183[500]
echo：ipsec，debug，packet 从 xx7.183[500] 发送数据包
echo：ipsec，debug，packet 将数据包发送到 xx186.50[500]
回显：ipsec，debug，数据包 src4 xx7.183[500]
回显：ipsec，调试，数据包 dst4 xx186.50[500]
echo: ipsec,debug,packet 1 次 84 字节消息将被发送到 xx186.50[500]
回显：ipsec，调试，数据包 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf
回显：ipsec，调试，数据包 cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979
回显：ipsec，调试，数据包 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8
echo：ipsec，debug，packet sendto 信息通知。
echo：ipsec，debug，packet 收到有效 RU-THERE，ACK 已发送
我收到了来自 IPsec 专家和 MikroTik 本身的各种建议，暗示问题出在远程端。然而，情况变得更加复杂，因为其他 5 个站点正在运行，并且客户端的防火墙处于变更控制之下。该设置多年来一直有效，因此他们声称这不可能是他们那边的配置错误。这个建议似乎很有道理，但由于变更控制，我无法实施。我可能只会更改客户端：
确保 IPSec 响应者已设置 Passive=yes 和 Send-initial-contact=no。
这不起作用。
编辑于 2013 年 12 月 9 日
我粘贴了包含 Fortigate 配置以及我们认为的 Mikrotik 端快速模式选择器的附加屏幕截图。
让我重申一下，我不认为这是一个配置问题。我推测这是一个时间问题，即 A 方或 B 方过于积极地尝试发送信息，导致信息协商（例如 SPI）不同步。
编辑于 2013 年 12 月 11 日
遗憾的是，我不得不放弃解决这个问题。幸好一切都正常。为什么它能正常工作仍然是个谜，但为了进一步说明我们做了什么，我发布了另一张内联图片。
我们通过以下方式修复了它：
- 关闭客户端的 PPPoE。
- 安装全新路由器（路由器 B）并在 Border 进行测试。它在 Border 运行正常。
- 关闭边界的新路由器 B。然后，无需进行任何更改，客户端的端点路由器 A 就开始工作了。因此，只需在边界添加一个重复的路由器并再次使该路由器脱机，就可以使原始路由器正常工作。
因此，请将此修复程序添加到我们已经完成的事情列表中：
- 重启。这个方法曾经奏效。
- 使用新 IP 创建新隧道。此方法有效一次，但仅一次。更改 IP 后，客户端端点再次生效。
- 更改时间服务器。
- 摆弄所有可能的设置。
- 等待。有一次，过了一天，一切都好了。这一次，过了好几天，什么事也没有发生。
因此我推测 Fortigate 或 MikroTik 一方存在不兼容问题，这种情况只会在非常随机的情况下发生。我们唯一无法尝试的是升级 Fortigate 上的固件。也许存在隐藏的损坏配置值或配置器看不到的计时问题。
我进一步推测，该问题是由时序问题导致 SPI 不匹配引起的。我猜 Fortigate 不想“忘记”旧的 SPI，就好像 DPD 不起作用一样。它只是随机发生的，据我所知，只有当端点 A 是 Fortigate 而端点 B 是 MikroTik 时才会发生。不断尝试重新建立连接的积极尝试“保留”旧的 SPI 值。
当它再次发生时，我会添加到此帖子中。
编辑于 2013 年 12 月 12 日
正如预期的那样，它再次发生了。你可能还记得，我们配置了 6 个 MikroTik 客户端 IPsec 端点路由器一模一样连接到一台 Fortigate 服务器。最新事件再次发生在一台随机路由器上，而不是我最初在此处发布的那台路由器。考虑到我们上次安装此重复路由器的修复，我采取了以下捷径：
- 禁用路由器 A，即不再接收来自 Fortigate 的数据包的路由器。
- 将路由器 A 的 IPsec 配置复制到更靠近我们网络边界的临时路由器。
- 立即禁用新创建的配置。
- 重新启用路由器 A。
- 它会自动开始工作。
查看 @mbrownnyc 的评论，我认为我们遇到了一个问题，即即使 DPD 已启用，Fortigate 也不会忘记过时的 SPI。我将调查我们客户的固件并发布它。
这是一个新图表，与上一个非常相似，但仅显示我的“修复”：
答案1
这可能不是导致您出现问题的原因，但可能对其他用户有用。我们在 Mikrotik 和 Sonicwall 之间的 VPN 上遇到了类似的问题。流量会随机停止，需要刷新 SA。
最后，我们意识到 Sonicwall 正在为每个网络策略创建单独的 SA（从您的屏幕截图来看，似乎有 2 个策略/子网通过 VPN）。我不知道这个“每个策略的 SA”设置是硬编码的还是可配置的，因为我无权访问 Sonicwall。
我们的 Mikrotik 正在使用“require”级别的策略（默认，如您的屏幕截图所示）。这会导致路由器与远程对等端创建单个 SA。当为该对等端的任何策略发送流量时，它将使用相同的 SA，无论源/目标子网如何。
这基本上意味着只要我们只使用一个子网，它就可以工作。一旦我们的 Mikrotik 尝试为第二个子网发送流量，它就会通过现有的 SA 发送（就 Sonicwall 而言，这是针对特定子网对的），Sonicwall 会抱怨，SA 序列号会失控，整个过程都会停止。（在我们的案例中，客户在他们的终端上收到了“重放”错误）
最后，只需将策略级别更改为“唯一”，这样两端就对每个唯一子网对使用唯一的 SA。此后，隧道就完美了。
答案2
我知道您已经检查过这一点（就像我遇到类似但完全不同的间歇性问题时所做的那样），但请确保您没有路由器 A 共享的重复 IP 地址。当您的高端路由器对路由器 A 进行 arp 查找并感到困惑时，这会给您带来间歇性问题。您可能会认为路由器上的 dup Ips 会产生一致的错误，但事实并非如此。