背景和拓扑

本次问题发生在一条跨公网建立的 IPSec VPN 隧道中，双方运营商均为相同运营商，设备分别为：

  • 本端：MikroTik CCR 2004（ROS）
  • 对端：山石网科防火墙（Hillstone FW）

双方均为专线，具有公网 IPv4 地址，通过 IKEv1 野蛮模式（Aggressive Mode） 建立 IPSec 隧道。协商参数正常，SA（Phase 1/2）均稳定，无重协商情况，DPD 正常。

拓扑

是一个典型的 Site to Site IPSec 场景，其中两台虚拟机 A、B 均可互相 Ping 通，往返时延较低，ICMP 无丢包。

问题现象

ICMP 正常，但实际业务流量有明显异常。

1、从 ROS LAN 的虚拟机 A SSH 登录 到 远端虚拟机 B 时，连接能够建立，但交互过程持续卡顿。在命令行中表现为输入延迟、屏幕回显缓慢，不到断线程度，但体验极差。
obfuscate_keystroke_timing: starting: interval ~20ms

2、尝试虚拟机 AB 之间进行 iperf3 打流，发现很小而且时断时续。双端正常的带宽应该是 50Mbps。
iperf3 流量异常

初步排查

ICMP 正常，但是业务流程异常这个现象，可能是 MTU 的问题。但是我们两端都是静态专线，MTU 1500。为了排除 MTU 的可能性，我们配置了 MSS clamp，发现问题现象依旧。

我们在 ROS 和 山石侧抓了包，发现 ROS 一直在丢 TCP 包。

端倪出现

在排查过程中，我们注意到 CCR2004 上启用了 FastTrack。FastTrack 是 RouterOS 的一项高性能转发机制，用于提升大流量场景下的吞吐能力。FastTrack 位于 forward 表，会识别处于 established 或 related 状态的连接，将其标记为 fasttrack-connection。这些连接会走快速路径，这些快速路径会绕过（影响）以下功能。

  • firewall,
  • connection tracking,
  • simple queues,
  • queue tree with parent=global,
  • IP accounting,
  • IPSec,
  • hotspot universal client,
  • VRF assignment

综上，IPSec 和 FastTrack 算是一个配置冲突项。

如何解决

我们希望在支持 FastTrack 的情况下，让 IPSec 工作正常。这需要我们配置规则，让 IPSec 的流量不要进入 FastTrack，就不会被打上 fasttrack-connection 的标记。

在 FastTrack 规则前加两条规则：

1
2
3
4
/ip firewall filter
add chain=forward action=accept ipsec-policy=in,ipsec
add chain=forward action=accept ipsec-policy=out,ipsec
add chain=forward action=fasttrack-connection connection-state=established,related

这样，属于 IPSec policy 的流量都不会进入 FastTrack，从而保证了 IPSec 功能的正常。

结语

本次故障的根因在于 RouterOS FastTrack 与 IPSec 加密流量之间的机制冲突。FastTrack 在提升性能的同时，会绕过 IPSec 所需的部分处理流程，导致加密流量无法被正确封装，从而表现为 ICMP 正常但 TCP 会话极度不稳定。通过在 FastTrack 规则之前明确放行 IPSec policy 匹配的流量，可以有效避免该问题，同时保留 FastTrack 带来的高性能优势。

值得注意的是，在 MikroTik 设备上启用 FastTrack 时，应始终确认是否存在 IPSec、QoS、VRF、流量审计等依赖 connection tracking 的场景。提前做好策略分流不仅能提升设备性能，也能避免类似的复杂故障。希望本文的排查思路能为你在排障与配置优化过程中提供参考。

参考文档：

AIGC 声明：本文使用了 LLM 对文章结构和内容进行了优化，题图和文中部分图片使用 Gemini 进行生成。