设备H3C SecPath F100-C-A5防火墙NAT ALG SIP 转换问题

您好，这是一个非常典型且深入的SIP ALG应用问题。您遇到的情况很可能是由于​​NAT会话状态与SIP ALG处理流程不匹配​​导致的。

首先，您对问题的描述非常准确，核心在于：为什么REGISTER请求能被正确修改，而后续的NOTIFY却不能？

根本原因分析

SIP ALG的工作原理不仅仅是简单地在“所有”SIP报文经过时都去修改其头部。它的行为是​​状态相关​​的，其处理逻辑与​​NAT会话表项​​和​​SIP对话（Dialog）状态​​紧密绑定。

1. 1.

   ​​REGISTER请求是特殊的​​：

   • •

     这是SUA（SIP User Agent）与服务器建立联系的第一个请求，用于告知服务器“我在这里，我的联系地址是这个”。

   • •

     对于ALG来说，这是一个明确的信号，需要为这个UA创建一个​​控制通道​​或​​绑定关系​​。ALG会修改Contact、Via等头字段，并将其与NAT转换后的公网IP和端口进行映射，同时记录这个映射关系（状态）。

2. 2.

   ​​NOTIFY/ INVITE等请求依赖于现有状态​​：

   • •

     这些后续请求属于一个已建立的SIP对话（Dialog）。

   • •

     SIP ALG在处理这些报文时，会首先检查这个报文是否属于一个​​已经通过REGISTER等请求建立好的NAT会话和ALG状态表项​​。

   • •

     如果ALG认为这个NOTIFY请求不属于一个需要它处理的“合法”会话，或者未能正确关联到之前的SIP对话状态，它就可能会选择​​ bypass ​​（绕过）处理，即不修改报文内容，直接进行普通的IP/端口转换。

排查思路与解决方案

请按照以下步骤进行排查，从最常见的原因开始：

1. 检查NAT会话与ALG状态（最关键）

这是最可能的原因。在防火墙上检查NAT会话和ALG的调试信息。

• •

  ​​查看当前NAT会话​​：

  display nat session verbose
  • •

    在您的内网SIP客户端发起NOTIFY请求时，立即执行此命令。

  • •

    仔细查找源IP是您SIP客户端IP、目的IP是外网SIP服务器的相关会话。

  • •

    ​​重点关注​​：这条会话的协议类型是否显示为 ​​SIP​​？ 如果显示的只是UDP，则说明防火墙没有识别出这是SIP流量，ALG自然就不会工作。

• •

  ​​启用SIP ALG调试功能​​（如果问题可复现，在技术支持指导下进行）：

  terminal monitor terminal debugging debugging nat alg sip

  然后重现问题（让客户端发送NOTIFY），观察调试信息输出。调试信息会明确显示ALG是否处理了该报文以及如何处理。如果没有任何关于NOTIFY报文的调试输出，说明报文没有被ALG引擎识别。

2. 确认流量路径与策略配置

• •

  ​​策略路由与域间策略​​：确保NOTIFY请求和REGISTER请求走的是完全相同的路径，经过相同的防火墙接口和安全策略。如果流量因为某种原因（如路由变更）没有命中您配置了ALG的策略，ALG也不会生效。

• •

  ​​域间策略​​：确认NOTIFY报文所在的安全域之间（如Trust -> Untrust）的策略已经放行，并且调用了正确的NAT策略。

3. 检查SIP ALG的识别能力

• •

  ​​SIP 消息格式​​：某些SIP ALG实现可能对非标准的SIP消息格式（如压缩的头部、非标准的端口、TCP vs UDP）支持不佳。确保您的NOTIFY报文格式是标准的。

• •

  ​​ALG 深度解析能力​​：虽然可能性较低，但不同版本的ALG对SIP协议不同方法的支持深度可能有细微差别。确认您的防火墙软件版本没有已知的与此相关的BUG。

4. 高级配置检查：port-mapping 与 nat server

您提到了nat server和port-mapping。这里需要明确：

• •

  nat server：通常是用于​​外部访问内部​​服务器，是目的NAT。

• •

  port-mapping：用于细化ALG对特定协议端口的处理。

在您描述的场景（内部客户端主动访问外部服务器）中，主要起作用的是​​源NAT（nat outbound）​​ 和 ​​ALG​​。请确认您的配置重心在此。

port-mapping配置需要确保包含了SIP标准端口（5060/5061）以及您的客户端可能使用的任何非标端口。

总结与行动方案

您遇到的问题​​不是SIP ALG规则主动不对NOTIFY进行处理，而更可能是配置或状态匹配问题​​。

​​建议的排查顺序：​​

1. 1.

   ​​核心检查​​：通过 display nat session verbose命令，确认NOTIFY请求产生的会话协议被识别为 ​​SIP​​ 而非 UDP。这是决定性的证据。

2. 2.

   ​​调试信息​​：如果会话显示为UDP，启用 debugging nat alg sip，查看ALG为什么没有识别出NOTIFY报文。

3. 3.

   ​​策略路由​​：复核流量路径，确保NOTIFY流量与REGISTER流量经过了完全相同的防火墙策略和NAT规则。

4. 4.

   ​​版本与已知问题​​：查询H3C的版本发布说明或知识库，查看您使用的​​F100-C-A5的软件版本​​是否存在SIP ALG相关的已知问题或缺陷。考虑升级到推荐版本。

如果以上自查无法解决，在联系H3C技术支持时，提供以下信息将极大加快处理速度：

• •

  display nat session verbose的输出结果（在问题发生时捕获）。

• •

  display current-configuration中关于NAT、ALG、安全策略的配置片段。

• •

  debugging nat alg sip的调试输出（如果已获取）。

• •

  防火墙的详细型号和软件版本号。

结论先说：主流防火墙的 SIP ALG 并不会“特意跳过 NOTIFY”的 Via 处理。只要报文被 ALG 识别为 SIP、且可见（未加密）、走受管控的会话，REGISTER/INVITE/NOTIFY 等方法的 Via 都会按需改写。
你现在 REGISTER 的 Via 能改、但 NOTIFY 的 Via 没改，通常是下面这些原因之一——更像“识别/场景不满足”或“配置未覆盖”，而不是规则故意不处理 NOTIFY。

常见原因与定位要点

1. NOTIFY 未被 ALG 识别为 SIP 流量

• 走了 非标准端口（不是 5060/UDP 或 5060/TCP），ALG 可能默认不检查。

• 应用识别未绑定到这条安全策略/区域对。

• 长连接复用导致 ALG 没抓到该消息的开始（某些设备对中途入流量识别不佳）。

2. NOTIFY 使用了 TLS（SIPS/5061）或被上层封装

• 加密后 ALG 看不到应用层，自然不会改 Via。

• 解决：用明文 5060 先验证，或在两端改用 STUN/ICE/Outbound，避免依赖 ALG 改头字段。

3. NOTIFY 与 REGISTER 不是同一“方向/会话/策略”

• 例如 REGISTER 用 UDP/5060，NOTIFY 切到 TCP 或 不同出口策略；或命中另一条不启用 ALG 的策略。

• 解决：确保同一条策略启用 SIP ALG；或在所有可能匹配的策略上都打开 ALG。

4. 设备只在特定阶段改 Via（实现差异）

• 有的实现只在 首次对外事务/注册阶段主动改 Via；对 中间请求（in-dialog） 更依赖 rport/received 回送，不强改 Via。

• 如果 NOTIFY 属于对话内请求（带有 Route/To/From/Call-ID 等已建立对话参数），有些 ALG 只做会话打洞，不必改 Via。

5. 客户端 Via 含 rport，服务端按源地址回响应

• 按 RFC 3581，服务端若看见 Via: ...;rport，就会用 报文源地址/端口 回响应，Via 的 sent-by 值反而不关键；一些 ALG 就不再改写 Via。

• 这在 REGISTER 与 NOTIFY 不一致时（比如 REGISTER 有 rport，NOTIFY 没带或格式异常）会表现不同。

6. NOTIFY 的角色异常（客户端充当 Notifier）

• 典型流程通常是 服务器向客户端发 NOTIFY（订阅-通知机制）。你这边是“客户端主动向外发 NOTIFY”，若是 跨端口/跨代理路径 的特殊场景，ALG 的状态机可能不匹配，从而不触发改写。

快速排查清单（按优先级）

• 抓包对比 同一出口 上 REGISTER 与 NOTIFY：

  • 端口（UDP/TCP、5060/5061）、五元组、是否同一安全策略命中。

  • 确认 NOTIFY 是否 明文，报文起始可被解析（起始行应为 NOTIFY sip:... SIP/2.0）。

• 查看防火墙 会话/日志：该 NOTIFY 是否被识别为 SIP 应用、是否触发 ALG。

• 确认策略或全局处已 开启 SIP ALG + Via 修正/SDP 修正（不同厂商名称略有差异，如 “fix-via/ change-via/ sip helper/ sip inspection” 等）。

• 检查 NOTIFY 的 Via 是否带 rport；如果没有，尝试在客户端开启 rport/对称响应，减少对 Via 改写的依赖。

• 若为 TLS（SIPS/5061），ALG 无法改：

  • 短期验证：切回明文 5060 看是否生效；

  • 长期方案：启用 STUN/ICE/Outbound（RFC 5626） 或设 Outbound Proxy，避免改包依赖。

• 确认 NOTIFY 是否 对话内 请求：带 Route 且复用现有对话时，一些 ALG 只做 NAT 绑定/回包引导，不改 Via 是“正常现象”。

可用替代/增强方案（不靠 ALG 改 Via）

• 在客户端配置 Outbound Proxy 指向外网 SIP 代理/边界 SBC，由代理统一改写头字段。

• 开启 rport、对称 UDP（symmetric RTP/SIP）、或 SIP Outbound（保持流）。

• 使用 SBC（会话边界控制器）在边界做可靠的 SIP 规范化与 NAT 穿越。