防火墙ipsec丢包

ipsec统计，只有一个ACL check failure: 3706，这个数据一直变化，是不是和这个acl有关系？

核心故障点分析

1. 1.

   ​​ACL check failure: 3710(最主要原因)​​

   • •

     ​​含义​​：有3710个数据包需要被IPSec加密保护，但是它们​​没有匹配到任何一条有效的IPSec安全策略（或策略中引用的ACL规则）​​，因此被丢弃。

   • •

     ​​通俗解释​​：您告诉防火墙“去北京的包裹要用加密卡车运送（IPSec策略）”，但现在有一个寄往上海的包裹，您既没有说用普通货车送（普通路由），也没说用加密卡车送，仓库管理员（防火墙）不知道如何处理，只好把它扔掉。

2. 2.

   ​​No available SA: 74(次要原因)​​

   • •

     ​​含义​​：有74个数据包匹配了IPSec策略，需要被加密，但此时​​IPSec隧道尚未成功建立​​（没有对应的安全联盟SA），因此无法处理而被丢弃。

   • •

     ​​通俗解释​​：加密卡车已经安排好了（策略配置好了），但卡车还没到仓库（SA没建立），这时来了一个需要加密的包裹，无法处理，只好暂时扔掉。

   • •

     这个错误通常发生在隧道正在建立（如触发首包建立）的瞬间，或者隧道因某种原因中断后重新建立的阶段。如果数量远少于ACL失败，通常可以忽略，或者表明隧道有短暂的不稳定。

为什么访问互联网不丢包？

您观察到“访问互联网不丢包”，这完全符合上述分析。

• •

  ​​互联网流量​​：目的地址是公网IP，​​没有匹配​​到您为IPSec隧道配置的“感兴趣流”（ACL）。这些流量直接匹配了设备的默认路由或普通策略，直接通过NAT转换后发送到互联网，所以不丢包。

• •

  ​​IPSec流量​​：目的地址是您对端私网IP的流量，​​试图匹配​​IPSec的“感兴趣流”。但由于配置问题（详见下文），不是找不到策略（ACL失败）就是策略找到了但隧道没准备好（No SA），导致丢包。

根本原因与解决方案

根本原因是IPSec策略中的​​感兴趣流（ACL）定义​​与实际的业务流量不匹配。

​​请按照以下步骤排查和修复：​​

第1步：检查IPSec策略引用的ACL

1. 1.

   找到您的IPSec策略（通常通过 display ipsec policy查看）。

2. 2.

   查看该策略引用了哪个ACL（例如 acl number 3100）。

3. 3.

   使用 display acl <acl-number>命令查看该ACL的具体规则。

​​常见的配置错误包括：​​

• •

  ​​ACL规则顺序错误​​：ACL规则是从上到下匹配的。如果先有一条 deny规则匹配了您的流量，那么后续的 permit规则就不会生效。

• •

  ​​ACL规则定义错误​​：

  • •

    ​​源/目的网段写反​​：例如，本端网段是 192.168.1.0/24，对端网段是 10.0.0.0/24。那么ACL规则应该是：

    rule permit ip source 192.168.1.0 0.0.0.255 destination 10.0.0.0 0.0.0.255

  • •

    ​​网段掩码错误​​：使用了错误的通配符掩码（wildcard mask，是反掩码）。记住 0表示匹配，255表示忽略。0.0.0.255对应前缀掩码 /24。

  • •

    ​​协议端口错误​​：如果ACL定义了特定协议（如TCP/UDP）和端口，而您的流量不符合，也会导致匹配失败。对于通常的站点间互访，直接使用 ip协议即可。

第2步：检查IPSec策略的应用位置

• •

  使用 display ipsec policy-binding查看IPSec策略被应用在了哪个接口上（通常是连接公网的出口接口）。

• •

  确认您的业务流量​​确实从这个接口流出​​。如果流量路径不正确，IPSec策略也不会被触发。

第3步：确认IPSec隧道状态

• •

  使用 display ipsec sa命令查看安全联盟是否成功建立。

• •

  如果SA不存在，那么所有匹配的流量都会报 No available SA错误。您需要去排查IKE（第一阶段）的配置，包括预共享密钥、对端地址、提议配置等。

总结与操作命令示例

​​您的排查重心应该是：ACL check failure。​​

1. 1.

   ​​找到IPSec策略名​​：

   display ipsec policy
2. 2.

   ​​查看策略细节，确认引用的ACL编号​​：

   display ipsec policy name <policy-name>
3. 3.

   ​​检查ACL规则是否正确​​：

   display acl <acl-number>

   ​​重点核对​​：源地址、目的地址、通配符掩码是否与您想要加密的流量完全一致。

4. 4.

   ​​触发流量并观察​​：在纠正ACL配置后，再次从内网发起访问对端的测试（如ping），然后执行 display ipsec sa查看隧道是否建立，再次执行 display ipsec statistics查看 ACL check failure计数器是否停止增长。

通过以上步骤，您应该能准确定位并解决IPSec丢包的问题。

丢包原因解析：
1. No available SA (无可用安全关联)
- 出现74次，表示设备在转发IPSec报文时未找到对应的SA（如SA尚未建立、已过期或配置不匹配）。
- 排查建议：
- 确认IPSec隧道两端配置一致（加密算法、认证算法、PFS组、生存时间等）。
- 通过 `display ike sa` 和 `display ipsec sa` 检查SA状态是否正常建立，若缺失则需检查IKE协商过程（如预共享密钥、身份信息）。
- 检查ACL定义的感兴趣流是否覆盖业务流量，确保流量能触发SA建立。

2. ACL check failure (ACL检测失败)
- 出现3710次，表示解密后的明文流量未匹配到ACL规则（即IPSec解封装后流量被安全策略丢弃）。
- 排查建议：
- 检查IPSec策略中引用的ACL（感兴趣流）是否与业务流量匹配，确保解密后报文的源/目的IP在ACL允许范围内。
- 通过 `display acl` 确认ACL规则未配置错误（如反向流量未放行）。
- 若涉及NAT，需确认ACL是否排除了IPSec流量（避免NAT转换干扰）。

关键排查步骤：
1. 验证SA状态：

display ike sa 检查IKE SA是否建立（Flag应为"RD"或"RD|ST"）
display ipsec sa 确认IPSec SA存在且无到期告警


2. 检查ACL与业务流量匹配：
- 在两端设备分别执行：

display ipsec policy 查看引用的ACL编号
display acl <编号> 核对ACL规则是否覆盖业务网段

- 示例：若业务流量为192.168.1.0/24 ↔ 10.1.1.0/24，ACL需包含双向规则：

rule permit ip source 192.168.1.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
rule permit ip source 10.1.1.0 0.0.0.255 destination 192.168.1.0 0.0.0.255


3. 捕获调试日志：
- 开启IPSec丢包调试（谨慎操作，仅在测试时使用）：

debugging ipsec error 捕获详细错误信息
terminal monitor 实时查看日志

- 复现问题时观察日志，定位具体丢包原因（如ACL拒绝或SA缺失）。

结论：
当前丢包主要由 SA缺失 和 ACL策略拦截 导致。优先检查IPSec隧道协商状态及ACL配置，确保业务流量能正常触发SA建立且解密后流量被安全策略放行。若问题持续，需结合调试日志进一步分析。