记一次 MikroTik IPSec 隧道丢包问题排查：FastTrack 导致的 IPSec 失效
背景和拓扑
本次问题发生在一条跨公网建立的 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、从本端的虚拟机 A SSH 登录到 对端虚拟机 B 时，连接能够建立，但交互过程持续卡顿。在命令行中表现为输入延迟、屏幕回显缓慢，不到断线程度，但体验极差。
2、尝试虚拟机 AB 之间进行 iperf3 打流，发现很小而且时断时续。双端正常的带宽应该是 50Mbps。
初步排查
ICMP 正常，但是业务流程异常这个现象，可能是 MTU 的问题。但是我们两端都是静态专线，MTU 1500。为了排除 MTU 的可能性，我们配置了 MSS clamp，发现问题现象依旧。
在部分 VPN 场景中，由于 PPP 封装（双端中有 PPPOE 的一端）等因素会改变链路的有效 MTU。此时可能出现 ICMP Ping 正常，但业务流量异常的情况。为确认链路上的真实可用 MTU 值，可以通过发送“不分片(DF 标志位)”的 Ping 包进行测试，从而判断是否存在 MTU 限制或路径 MTU 抖动。
我们在 ROS 和 山石侧抓了包，发现 ROS 一直在丢 TCP 包。
端倪出现
在排查过程中，我们注意到 CCR 2004 上启用了 FastTrack。FastTrack 是 RouterOS 的一项高性能转发机制，用于提升大流量场景下的吞吐能力。FastTrack 位于 forward 表，会识别处于 established 或 related 状态的连接，将其标记为 fasttrack-connection。这些连接会走快速路径。
FastTrack 处理逻辑图：
FastTrack 数据包绕过 firewall, connection tracking, simple queues, queue tree with parent=global, ip traffic-flow, IP accounting, IPSec, hotspot universal client, VRF assignment，因此管理员必须确保 FastTrack 不干扰其他配置！
如何解决
为确保在启用 FastTrack 的情况下 IPSec 流量仍能正常工作，需要在防火墙规则中显式排除所有与 IPSec 相关的流量。具体做法是：在 FastTrack 规则之前添加匹配 IPSec 相关流量的规则，并对这些连接执行 accept，使其不被应用 fasttrack-connection 标记。这样可避免 IPSec 数据包绕过必要的加密、解密和策略处理，从而保持隧道的稳定性与可靠性。
1 | /ip firewall filter |
这样，属于 IPSec policy 的流量都不会进入 FastTrack，从而保证了 IPSec 功能的正常。
结语
本次故障的根因在于 RouterOS FastTrack 与 IPSec 加密流量之间的机制冲突。FastTrack 在提升性能的同时，会绕过 IPSec 所需的部分处理流程，导致加密流量无法被正确封装，从而表现为 ICMP 正常但 TCP 会话极度不稳定。通过在 FastTrack 规则之前明确放行 IPSec policy 流量，可以有效避免该问题，同时保留 FastTrack 带来的高性能优势。
值得注意的是，在 MikroTik 设备上启用 FastTrack 时，应始终确认是否存在 IPSec、QoS、VRF、流量审计等依赖 connection tracking 的场景。提前做好策略分流不仅能提升设备性能，也能避免类似的复杂故障。希望本文的排查思路能为你在排障与配置优化过程中提供参考。
参考文档：
- Mikrotik Docs - PacketFlowinRouterOS-FastTrack
- Mikrotik Docs - Connectiontracking-FastTrack
- Mikrotik Forum - IPSEC Fasttrack
AIGC 声明：本文使用了 LLM 对文章结构和内容进行了优化，题图和文中部分图片使用 Gemini 进行生成。
