MikroTik IPsec客户端Fortigate'接收到未知SPI的ESP数据包'。
我们有一个使用IPsec的6个站点的客户端。 现在每隔一次，甚至每周一次，有时一个月一次，数据就会从远程Fortigate VPN服务器stream向本地MikroTik IPsec VPN客户端。
为了certificate问题的症状，我附上了一个图表。 在“已安装的SA”选项卡上，您将注意到xx186.50的源IP地址尝试与xx7.3通信，但是0个当前字节。 xx186.50是客户端的远程Fortigate IPsec服务器，而xx7.73是基于MikroTik的IPsec端点。 从远程来看，我们并不总是在stream动。
阶段1和2始终build立，但交通总是拒绝从远端stream向我们。
我们随着时间的推移尝试了各种各样的东西，比如重新启动，设置时钟，涉及configuration，重新检查和重新检查configuration，但问题完全是随机的。 有时随机的东西修复它。 在一个阶段，我有一个理论，如果隧道是从他们身边发起的，但是“发送初始接触”摆弄没有任何区别。
- L2TP / IPsec通过HTTP端口80
- 我们是否应该满足一个客户要求我们NAT服务器在VPN内新的公共IP？
- 有没有办法使用StrongSwan IPSec来validationXAuth的外部程序？
- 站点到站点IPSEC vpn是否需要一直连接？
- Fortigate IPSEC VPN问题
我们已经和客户聊了很多，但是他们有更多的国际IPsec VPN，只有我们的MikroTikconfiguration失败了。
Fortigate日志：
http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654
看看Fortigate的知识库，看起来SPI不同意，DPD会有所作为。 但是我已经尝试过在这方面DPD的每一个单一的组合，没有用。 我想在另一方面启用DPD，但我不能由于改变控制，也因为客户说它在所有其他网站的configuration完全相同。 编辑DPD已启用
显示没有stream量的本地VPN客户端图表：
我已经包含一个日志文件，显示“收到一个有效的RU-THERE，ACK发送”连续循环MikroTik日志文件：
echo：ipsec，debug，从xx7.183 [500]到xx186.50 [500]
回声：ipsec，debugging，数据包sockname xx7.183 [500]
回声：ipsec，debugging，数据包发送数据包从xx7.183 [500]
回声：ipsec，debugging，数据包发送数据包到xx186.50 [500]
回声：ipsec，debugging，数据包src4 xx7.183 [500]
echo：ipsec，debug，packet dst4 xx186.50 [500]
回声：ipsec，debugging，包1个84字节的消息将被发送到xx186.50 [500]
echo：ipsec，debug，packet 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf
echo：ipsec，debug，packet cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979
echo：ipsec，debug，packet 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8
echo：ipsec，debug，packet sendto信息通知。
回声：ipsec，debugging，数据包收到一个有效的RU-THERE，ACK发送
我收到了来自IPsec专家和MikroTik的各种暗示，暗示这个问题在远端。 然而，其他5个站点正在工作，客户端的防火墙处于变更控制之下，情况非常复杂。 该设置也一直工作多年，所以他们声称它不能在他们这边的configuration错误。 这个build议似乎是有道理的，但是由于改变控制我无法实现。 我只能改变客户端：
确保IPSec响应者同时拥有passive = yes和send-initial-contact = no set。
这没有奏效。
编辑2013年12月9日
我正在使用Fortigateconfiguration粘贴更多的屏幕截图，以及我们认为是Mikrotik端的快速模式select器。
让我重复一下，我不认为这是一个configuration问题。 我推测这是一个计时问题，由于A方或B方试图发送信息过于积极，导致信息协商（例如SPI）不同步。
编辑2013年12月11日
可惜我不得不放弃这个问题。 令人高兴的是一切都在起作用。 为什么它的工作仍然是一个谜，但进一步说明我们做了什么，我张贴另一个图像内联。
我们通
- 在客户端closuresPPPoE。
- 安装全新的路由器（路由器B）并在边界进行testing。 它在边界工作。
- 在边界closures新的路由器B. 然后，在不作单独更改的情况下，客户端的terminal路由器A开始工作。 所以只需在边界处添加一个重复的路由器，并再次使该路由器离线，就可以使原来的路由器工作
因此，将此修复添加到我们所做的事情列表中：
- 重启。 那一次工作。
- 用新的IP创build新的隧道。 那只工作了一次，但只有一次。 改变IP后端客户端端点再次生效。
- 更改时间服务器。
- 摆弄每一个可能的设置。
- 等待。 有一天，过了一天，它才刚刚出现。 这一次，即使在几天之后，没有什么事情是对的。
所以我推测在Fortigate或MikroTik方面有一个不兼容的情况，而这种情况只发生在非常随机的情况下。 我们唯一无法尝试的是Fortigate升级固件。 也许存在隐藏configuration值的隐藏configuration值或时序问题。
我进一步推测这个问题是由时序问题导致SPI不匹配造成的。 而我的猜测是，Fortigate不想“忘记”旧的SPI，就好像DPD不工作。 这只是随机发生的，只有当端点A是Fortigate，端点B是MikroTik时，我才能知道。 尝试重新build立连接的持续攻击尝试“持有”旧的SPI值。
当它再次发生时，我会添加到这个post。
编辑2013年12月12日
如预期的那样，再次发生。 您可能还记得，我们有6台MikroTik客户端IPsec端点路由器configuration完全相同的连接到一台Fortigate服务器。 最近的事件再次发生在一个随机路由器上，而不是我原先在这里发布的那个。 考虑到我们安装这个重复路由器的最后一次修复，我采取了这个捷径：
- 禁用路由器A，不希望从Fortigate接收数据包的路由器。
- 将路由器A的IPsecconfiguration复制到更靠近我们networking边界的临时路由器。
- 立即禁用新创build的configuration。
- 重新启用路由器A.
- 自动地它开始工作。
看看@mbrownnyc评论我相信，即使DPD开启，Fortigate也不会忘记陈旧的SPI。 我将调查我们客户的固件并发布。
这是一个新的图，很像最后一个，但只是显示我的“修复”：
可能不是你的问题的原因，但可能是其他用户的有用信息。 我们在Mikrotik和Sonicwall之间有一个类似的VPN问题。 stream量会随机停止，要求SA被刷新。
最后，我们意识到Sonicwall正在为每个networking策略创build一个单独的SA（从您的屏幕截图看，您似乎有2个策略/子网通过VPN）。 我不知道这个“SA-per-policy”设置是硬编码还是可configuration的，因为我没有访问Sonicwall。
我们的Mikrotik使用“要求”级别的政策（默认，并在您的屏幕截图中看到）。 这会导致路由器与远程对等体创build单个SA。 当为该对等体的任何策略发送stream量时，无论src / dest子网如何，都将使用相同的SA。
这基本上意味着它只要我们只使用一个子网就可以工作。 只要我们的Mikrotik尝试为第二个子网发送stream量，它就会发送现有的SA（就Sonicwall而言，它是针对特定的子网对），Sonicwall会抱怨，SA序列号将会失效整个一切都停了下来。 （在我们的案例中，客户最终得到了“重放”错误）
最后，只需将策略级别更改为“唯一”即可，因此两端都为每个唯一的子网对使用了唯一的SA。 之后隧道完全开心。
我知道你已经检查过了（就像我有一个类似的，但完全不同的间歇性问题），但确保你没有一个路由器A共享的重复的IP地址。 这会给你一个间歇性的问题，当你的高端路由器对路由器A进行ARP查询并且感到困惑时。 你会认为路由器上的dup Ips会给出一个一致的错误，但事实并非如此。