F1000-AK125+三次握手正常，客户端http-get到达防火墙后，防火墙回RST

从你的抓包来看，防火墙在两侧分别向客户端和服务器发送了 RST，但这通常不是防火墙“主动阻断”，而更可能是策略匹配与 TCP MSS 调整共同作用的结果。Telnet（23端口）正常而 HTTP（80端口）不通，说明问题不在安全策略的“允许/拒绝”层面，而是在报文转发细节上。核心原因大概率是安全策略的匹配顺序或 TCP MSS 调整。

 最可能的原因：安全策略匹配顺序

F1000-AK125 的域间策略是顺序匹配，命中即停止。根据 H3C 官方排查指引，策略的匹配顺序至关重要。

你描述中“策略没问题”可能是指策略存在，但没确认顺序。一个非常常见的误配是：存在一条更靠前的 deny 策略，恰好匹配了 HTTP 流量，导致安全策略将其丢弃（Drop），此时防火墙会向客户端回 RST。

排查方法：在防火墙上执行以下命令，查看 Trust 与 Untrust 域之间策略的完整顺序和匹配计数：

重点关注：

• 在允许 HTTP 的策略之前，是否存在 deny 策略？

• HTTP 策略是否被更宽泛的 deny any 策略“覆盖”了？

• 策略的 Hit Count（命中计数）是否有增长？如果 HTTP 被拒绝，拒绝策略的计数会增长。

 关键排查方向：TCP MSS 调整

从抓包看，你提到“1口抓包显示…内部服务器IP直接回包RST”。如果客户端和服务器之间的路径 MTU 不一致，防火墙作为二层设备默认会对 TCP SYN 进行 MSS 调整。如果调整后的 MSS 值不正确，可能导致后续 HTTP GET 报文（通常较大）无法正常分片，从而被中间设备丢弃或触发 RST。

排查方法：

查看是否启用了 MSS 调整及其数值。如果启用了，可以尝试在接口视图下临时关闭：

如果关闭后 HTTP 访问恢复，则说明 MSS 调整值是问题根源。

 补充排查：ASPF 与 会话同步

你提到“未主动配置 ASPF”，但 F1000-AK125 默认可能启用了 HTTP 的 ASPF 检测。如果 ASPF 将 HTTP 流量判定为异常（如 URL 过长、Header 异常），也可能触发 RST。

排查方法：

查看是否有默认 ASPF 策略生效，以及其阻断日志。同时，虽然你描述的是单防火墙场景，但如果设备存在 IRF 堆叠或 HA 配置，跨框流量也可能因会话同步问题导致 HTTP 不通。可执行 display session synchronization 确认会话同步状态。

组网梳理：外部客户端 → 外网出口路由器（NAT 映射 Web 服务器）→F1000‑AK125+【1 口】(二层透明桥)【2 口】→内网 Web 服务器。 现象：telnet 访问 Web 端口正常；HTTP 访问异常；

• 1 口抓包：三次握手完整，收到客户端 HTTP‑GET 报文，之后出现 RST；
• 2 口抓包：三次握手成功，只有客户端方向发出 RST 报文；

现象解读：TCP 三次握手报文完整穿过防火墙，但是 HTTP‑GET 到达防火墙后会话被防火墙拆除，防火墙主动发出 RST 打断连接；telnet 纯 TCP 数据流正常，HTTP 应用报文触发会话异常拆除；用户确认未开启 DPI，未手动配置 ASPF 策略。

⚠️注意：V7 防火墙传输层 TCP 检测是 ASPF 内置默认开启，不受手动 aspf policy 是否应用的控制，即使不手动配置 aspf 策略，TCP 状态检测仍然生效H3C。

一、核心可能根因（按概率排序）

1、来回路径不一致（最高概率，透明桥常见坑）

外网路由器 NAT 映射后的流量：客户端 SYN 走 F1000 的 G1 口进入；但是 Web 服务器的 SYN‑ACK 应答报文，存在其他二层链路绕过 F1000 直接返回出口路由器。

• 结果：防火墙只收到单向 SYN，没有收到服务器侧 SYN‑ACK；防火墙会话表半开。
• 当后续客户端 HTTP‑GET 报文到达防火墙，防火墙会话状态校验失败，主动发送 RST 拆除 TCP 会话。

telnet 为什么正常：telnet 交互报文速率低、时延大，部分半开会话老化前可以短暂通行；HTTP 报文快速发送 GET 直接触发状态检测校验，立刻 RST 断开。

抓包佐证现象：在 F1000 的 G2（服务器侧）抓包，看不到服务器回给客户端的 SYN‑ACK 报文，应答报文走别的链路绕开防火墙。

2、ASPF 内置 TCP 传输层状态检测（默认开启，不受手动 aspf 配置开关控制）

重点：V7 的 ASPF 分为两部分： 1）传输层 TCP/UDP 检测：默认全局生效，不需要手工应用 aspf‑policy，做 TCP 三次握手完整性校验H3C。 2）应用层检测（HTTP/FTP/SIP 等）：需要手工配置 detect 才开启；用户没开 DPI，应用层检测没有启用。

场景：透明桥环境，报文非完整三次握手经过防火墙；当 HTTP‑GET 报文到达，ASPF‑TCP 校验会话状态非法，防火墙回复 RST。

telnet 可以通，HTTP GET 报文触发校验。

3、安全策略、黑名单、入侵防御 / DDOS 防护隐性拦截

虽然 telnet 通，但是 HTTP 报文特征命中：

• DDOS 防护：HTTP 报文触发 TCP‑Flood 防护阈值；
• 全局黑名单会话快速丢弃； 可通过display session fast‑drop statistics查看会话快速丢弃计数H3C。

4、Bridge 桥接口成员 VLAN / 成员端口配置错误

G1、G2 没有加入同一个 bridge‑instance；或者接口 PVID、trunk 允许 VLAN 不一致，部分报文二层转发异常，会话状态错乱。

二、现场排查操作步骤

步骤 1：验证来回路径是否一致（重中之重）

在防火墙两个业务口同时镜像抓包： 1）G1（外网侧）：看 SYN、SYN‑ACK、GET； 2）G2（服务器侧）：重点看能不能抓到服务器回复的 SYN‑ACK 报文。

• 如果 G2 抓不到服务器 SYN‑ACK 应答报文：应答流量绕过防火墙，属于来回路径不一致，就是故障根因。

透明桥模式必须保证业务双向流量全部穿过 F1000 的两个桥接口，不能存在旁路二层链路。

步骤 2：查看会话表，访问发生时立刻查看 5 元组会话

观察会话状态：

• 会话是否为SYN‑RCVD半开状态（只收到客户端 SYN，没有收到服务器 SYN‑ACK），这就是来回路径不一致特征。

半开会话收到后续 GET 报文，防火墙 ASPF‑TCP 检测发现状态非法，主动发送 RST。

步骤 3：查看会话快速丢弃统计

计数上涨，说明防火墙内部模块主动拆除会话。

步骤 4：核查 bridge 透明桥配置

确认 G1、G2 属于同一个 bridge‑instance；接口 untag VLAN 一致。

步骤 5：临时规避验证（定位是否 ASPF 传输层检测导致）

仅用于故障定位，不建议生产长期使用。

配置完成，重新测试 HTTP 访问；如果 HTTP 访问恢复，说明是 ASPF 的 TCP 传输层状态检测触发 RST。

⚠️该操作关闭 TCP 传输层状态校验，降低安全防护能力，定位问题完成后需要恢复。

步骤 6：检查 DDOS / 黑名单防护

确认没有针对该五元组动态黑名单。

三、对应解决方案

1. 来回路径不一致（最常见）：修改二层网络，保证 Web 服务器回包必须经过 F1000 防火墙 G2→G1 转发出去，不能存在旁路二层转发路径。透明桥模式双向流量都必须过防火墙。
2. 如果业务无法改变组网，必须存在旁路回包路径：在 zone‑pair 下关闭 aspf transport‑protocol tcp 检测；或者改用路由模式部署。
3. 检查 bridge‑instance，确认两个业务接口属于同一个桥实例，VLAN 配置正确。
4. 检查 DDOS 防护阈值，避免误杀正常 HTTP 报文。

简短总结

现象：telnet 正常、HTTP‑GET 到达防火墙后防火墙主动 RST 断开，大概率是透明桥模式下流量来回路径不一致，服务器 SYN‑ACK 应答报文绕过防火墙返回；防火墙会话处于半开状态，收到 HTTP‑GET 报文触发 ASPF 内置 TCP 传输层状态校验，主动发送 RST 拆除会话。优先双口同时抓包，确认服务器的 SYN‑ACK 是否经过防火墙；访问瞬间查看 session table 会话状态看是否半开。透明桥必须保证双向业务流量全部穿过防火墙；如果组网无法修改，可临时关闭 zone‑pair 下 ASPF 的 TCP 传输检测用于验证定位。