IPSec-NAT穿越原理和配置

前提知识：防火墙的处理流程

防火墙处理流程

---

NAT 与 VPN 冲突的核心原因深度解析

核心结论 ：NAT 与 VPN 的冲突根源在于地址转换破坏了 VPN 隧道建立的基础条件 ，加上处理顺序倒置 和协议不兼容，导致隧道无法协商或数据传输失败。

"VPN 是最后的处理过程，没有触发隧道建立" 只是表象，本质是 NAT 在 VPN 之前修改了关键信息，让 VPN 无法正常工作华为

NAT & VPN 三大通用底层冲突（最初的核心框架）

这是所有矛盾的根源，适用于 GRE、IPSec 等全部 VPN 协议，也是华为防火墙现网最核心的 3 个冲突点：

冲突 1：NAT 篡改 IP 地址 → 破坏 VPN 的「身份 / 端点匹配规则」

VPN 本质是点到点虚拟隧道 ，建立和维持隧道都依赖固定的 IP 标识：

1. IPsec：依赖对端公网 IP + IKE 协商身份；

2. GRE：直接依赖隧道两端外层 IP 作为唯一端点标识（无协商、无额外身份校验）。而动态 NAT/NAPT会修改报文外层源 IP / 端口，直接篡改 VPN 依赖的 "身份标识"。

冲突 2：防火墙转发顺序问题 → NAT 先于 VPN 处理，导致隧道无法触发建立

原始报文 → 安全策略 → SNAT（源NAT） → 连接数限制 → 会话表 → 【VPN封装/隧道触发】

关键规则：

IPsec 靠感兴趣流 ACL 触发隧道，ACL 默认匹配内网原始私网 IP；

GRE 靠路由指向 Tunnel 口触发封装，封装前报文已经过 SNAT 转换。

结果：IP 被 NAT 修改后，流量无法匹配 VPN 触发条件，隧道根本不会建立。

冲突 3：NAT 会话表存在老化机制 → 映射关系会定时失效

动态 NAPT（华为 Easy-IP / 地址池）的转换关系是临时会话表，有老化超时时间（GRE 这类三层协议默认仅 30~60s）。

一旦会话老化删除，NAT 映射消失，报文无法完成地址转换，直接丢包。

以上 3 条，是 NAT 与 VPN 冲突的总纲。下面所有 GRE 的故障，都是这 3 条总纲结合 GRE 协议特性衍生出来的。

---

IPSec 场景：源 NAT 改 IP→匹配不到感兴趣流→IKE 不发起→隧道压根建不出来

故障发生位置：SNAT 在 IPSec 触发校验前面执行

• 内网 PC：192.168.1.10访问192.168.2.10，原始报文源 = 私网 192.168.1.10；
• 安全策略放行后，先走 SNAT ，源 IP 被改成分支公网 IP203.1.1.5；
• 转换后的报文交给 IPSec 模块，IPSec 拿现在已经变成公网的源 IP去匹配 ACL；
• ACL 规则只认私网192.168.1.0，公网源匹配失败→不触发 IKE 协商、不建立 IPSec SA。

直白总结故障点

IPSec 靠【原始私网 IP】触发建隧道，NAT 提前把私网改成公网，破坏触发条件，隧道永远无法建立。

疑问解答：明明只是改源 NAT，为啥影响建隧道？因为建隧道的开关（感兴趣流）识别的是转换之前的原始 IP，NAT 在开关前面篡改了报文 IP，开关打不开。

---

先明确华为防火墙出向处理总流程（铁律，必须记死）

原始私网报文 → 路由查找 → 安全策略放行 → 源SNAT地址转换 → 会话表创建 → 【VPN封装】

关键区别：

• IPSec：封装在【最后一步】，必须等 SNAT 完成后，才会判断是否触发封装
• GRE ：封装在【路由查找之后、SNAT 之前】，因为 GRE 是路由强制触发的，和 IPSec 的 "流量触发" 机制完全不同

GRE 封装为什么在 SNAT 前？

1. GRE 封装的触发机制（和 IPSec 天差地别）

GRE 是无协商、无触发条件 的隧道：只要配置好 Tunnel 接口，且路由指向 Tunnel 口，流量进入 Tunnel 就立刻封装 GRE 头，不需要等任何匹配规则。

正确配置的 GRE 流程（tunnel source 为公网接口 IP）：

• 内网 PC 192.168.1.10 访问总部 192.168.2.10，路由指向 Tunnel0
• 流量进入 Tunnel0，立即封装 GRE 头 ：
  • 外层 IP：源 = 分支公网 IP 203.1.1.5（tunnel source 配置的公网接口 IP），目的 = 总部公网 IP 202.1.1.1
  • 内层 IP：源 = 192.168.1.10，目的 = 192.168.2.10
• GRE 报文进入 Untrust 域，不触发源 NAT（因为外层源已是公网 IP，匹配 no-nat 策略）
• 总部收到 GRE 报文，外层源 IP 与本地 tunnel-dest 一致，解封装转发，业务正常

---

命中NAT策略之后，会进行NAT转换

转换之后就无法命中ACL，就触发不了产生隧道的建立，就算有隧道也不会走，因为没有命中感兴趣流。

流量都不会进隧道，直接就出来了

---

IPSec NAT 旁路

原先的NAT策略

配置一条不做转换的NAT

注意：no-nat的顺序要在前面，要先匹配到

不进行NAT转换，就可以命中感兴趣流，会触发隧道的建立，并且流量会进入到隧道。

---

NAT 穿越

运营商在中间也有可能为了节约地址，做NAT转换。

192.168.1.1/24 访问 172.16.1.1/24 是不需要做NAT的，

---

内网私网主机经过 NAT 设备上网，外网收到报文后能正常把回复报文原路送回内网原主机 = 成功穿越 NAT；回包被 NAT 丢掉、到不了内网 = 无法穿越 NAT。

NAT（NAPT）核心铁律：多个内网共用 1 个公网 IP，靠四层端口 区分内网不同主机，映射表格式：内网IP+源端口 ↔ 公网IP+新端口回程报文靠【目的公网端口】查表，找到对应的内网 IP。没有端口 → NAT 没法做映射，回程不知道发给谁，直接丢包。

一、能正常穿越 NAT：报文带 TCP/UDP 头部（自带端口）

举例：IKE 协商报文（UDP 500，9 个 ISAKMP 包）

• 内网 PC 发 IKE：UDP 报文，源端口 5000、目的端口 500 源：192.168.1.10:5000，目的：202.1.1.1:500
• 经过 NAT 网关：NAT 改写源 IP，随机分配新公网端口 7000新报文源：203.1.1.5:7000，目的不变同时 NAT 生成映射表：192.168.1.10:5000 ↔ 203.1.1.5:7000
• 总部收到报文，回复 IKE：目的203.1.1.5:7000
• NAT 查表：目的端口 7000 对应内网192.168.1.10:5000，报文转发回 PC

✅ 收发闭环，成功穿越 NAT。

这就是：IKE9 个包全是 UDP500，自带端口，天生能过 NAT。

二、不能穿越 NAT：只有 IP 头、无 TCP/UDP 头（无端口：ESP 协议 50、GRE 协议 47）

举例 1：原生 ESP 报文（IP 协议号 50，没有四层端口）

• 内网发 ESP 加密报文：只有 IP 头部，没有端口 源192.168.1.10，目的202.1.1.1
• NAT 只能把源 IP 改成203.1.1.5，没有端口，无法生成端口映射表，NAT 记不住这个报文来自内网哪个设备
• 总部回 ESP 报文：目的 IP203.1.1.5
• NAT 拿到回包：没有目的端口，查不到对应内网主机，直接丢弃报文

❌ 回包无法抵达内网，不能穿越 NAT。

举例 2：GRE 报文（IP 协议号 47，无端口）

和 ESP 一模一样，没有四层端口，中间运营商 NAPT 无法生成端口映射。运营商 NAT 只能修改 GRE 外层源公网 IP，GRE 对端只认固定源 IP，IP 一变报文丢弃，这就是之前 GRE 跨运营商 NAT 不通的根源。

---

IKE 的第三第四个报文

前置基础

---

关于NAT穿越的文章：

四种 NAT 类型详解｜透彻理解 NAT 穿越原理（全锥 / 受限锥 / 端口受限锥 / 对称 NAT）-CSDN博客

---

---

NAT-T「ESP 塞进 UDP」完整拆解

老师说的交叉值不相同 = IP 头源 IP≠NAT-D 内置原始 IP ，触发 NAT-T，后续业务报文整体封装进 UDP4500，实现 NAT 穿越。

一、实验拓扑与地址规划（明确边界）

分支内网PC(192.168.1.10) ←→ 分支防火墙
       内网口：192.168.1.1（真实IP）
       外网口：G0/0/0=203.1.1.5（NAT转换后公网IP）
                 ↓互联网（运营商NAPT）
总部防火墙 外网口：202.1.1.1（无NAT，原生公网）
           内网：10.1.1.0/24

关键规则 ：分支防火墙对所有外网流量做动态 NAPT ，仅修改外层 IP 头源地址，内层载荷不碰。

---

二、基础约定（先明确核心概念）

1. NAT-D 载荷 ：IKE MM3/MM4 专属载荷，作用是携带发送方原始 IP + 端口，用于 NAT 探测
2. 交叉校验公式 ：接收方计算IP头源IP + UDP端口的 HASH 值，与 NAT-D 载荷内的 HASH 值对比
   • 相等：无 NAT，ESP 裸跑（IP 协议 50）
   • 不等：有 NAT，启用 NAT-T，ESP 封装进 UDP4500
3. 封装边界 ：
   • IKE 协商报文（MM1-MM6）：永远用UDP500，不随 NAT-T 改变
   • 业务 ESP 报文：仅在 NAT-T 启用时封装UDP4500

---

三、场景：分支有 NAT（触发 NAT-T 的完整流程）

阶段 1：MM3 报文（分支→总部）封装 + NAT 转换

步骤 1.1 分支构造原始 MM3 报文（从内到外封装）

层级	封装内容	具体数值
ISAKMP 载荷层	协议类型：ISAKMP载荷：NAT-D (2 个)+KE+ID+SANAT-D 核心内容	第一个 NAT-D：对端 IP (202.1.1.1)+ 端口 (500) 的 HASH第二个 NAT-D：本端原始 IP (192.168.1.1)+ 端口 (500) 的 HASH
UDP 头部	源端口：500目的端口：500	标准 IKE 端口，不变
外层 IP 头部	源 IP：192.168.1.1（分支真实 IP）目的 IP：202.1.1.1（总部公网 IP）协议字段：17 (UDP)	未经过 NAT 的原始 IP 头

原始 MM3 完整结构：

[IP:192.168.1.1→202.1.1.1, 协议=17] + [UDP:500→500] + [ISAKMP{SA,KE,ID,NAT-D1,NAT-D2}]

步骤 1.2 分支防火墙 NAT 转换（仅改外层 IP 头）

NAPT 只修改最外层 IP 源地址 ，内层所有内容（UDP、ISAKMP、NAT-D 载荷）完全不变。

转换后 IP 头：

• 源 IP：203.1.1.5（NAT 分配的公网 IP）
• 目的 IP：202.1.1.1（不变）
• 协议字段：17 (UDP)（不变）

互联网传输的 MM3 最终结构：

[IP:203.1.1.5→202.1.1.1, 协议=17] + [UDP:500→500] + [ISAKMP{SA,KE,ID,NAT-D1,NAT-D2}]

步骤 1.3 总部接收 MM3，执行交叉校验

1. 总部从IP 头提取源 IP：203.1.1.5，端口：500
2. 总部计算这组值的 HASH：HASH(203.1.1.5:500)
3. 总部从 MM3 的NAT-D2 载荷 提取分支原始 HASH：HASH(192.168.1.1:500)
4. 关键对比 ：HASH(203.1.1.5:500) ≠ HASH(192.168.1.1:500)✅ 结论：分支侧存在 NAT 设备

---

阶段 2：MM4 报文（总部→分支）封装 + 校验

步骤 2.1 总部构造 MM4 报文（无 NAT，全程不变）

层级	封装内容	具体数值
ISAKMP 载荷层	协议类型：ISAKMP载荷：NAT-D (2 个)+KE+ID+SANAT-D 核心内容	第一个 NAT-D：对端 IP (203.1.1.5)+ 端口 (500) 的 HASH第二个 NAT-D：本端原始 IP (202.1.1.1)+ 端口 (500) 的 HASH
UDP 头部	源端口：500目的端口：500	标准 IKE 端口
外层 IP 头部	源 IP：202.1.1.1（总部真实 IP）目的 IP：203.1.1.5（分支公网 IP）协议字段：17 (UDP)	无 NAT，原始 IP 头

MM4 完整结构：

[IP:202.1.1.1→203.1.1.5, 协议=17] + [UDP:500→500] + [ISAKMP{SA,KE,ID,NAT-D1,NAT-D2}]

步骤 2.2 分支接收 MM4，执行交叉校验

1. 分支从IP 头提取源 IP：202.1.1.1，端口：500
2. 分支计算这组值的 HASH：HASH(202.1.1.1:500)
3. 分支从 MM4 的NAT-D2 载荷 提取总部原始 HASH：HASH(202.1.1.1:500)
4. 对比 ：HASH(202.1.1.1:500) = HASH(202.1.1.1:500)✅ 结论：总部侧无 NAT 设备

---

阶段 3：IKE 协商结果→启用 NAT-T

MM3/MM4 校验完成后，双方明确：分支侧有 NAT，总部侧无 NAT，协商开启 NAT-T 模式。

注意：

MM1~MM6 全是这套结构：

IP + UDP500 + ISAKMP

所以你看到 MM3 报文自带 UDP，是 IKE 本来就有，不是提前开了 NAT-T。

---

四、"塞 UDP" 的具体过程（NAT-T 封装细节）

NAT-T 真正「塞 UDP」：只在协商结束后、ESP 数据报文生效

NAT-T 的 UDP4500 是协商成功后，后面传业务流量（ESP）才额外新增的头部。

核心改变：仅对外层封装新增 UDP 头，内层 ESP 完全不变

封装前（原生 ESP，无 NAT-T）

[外层IP头:203.1.1.5→202.1.1.1, 协议=50(ESP)] + [ESP头] + [加密业务数据]

封装后（NAT-T 模式，塞 UDP）

[外层IP头:203.1.1.5→202.1.1.1, 协议=17(UDP)] + [UDP头:源随机端口→4500] + [完整原生ESP报文]

具体改动清单（仅 2 处）

• 新增 UDP 头部 ：
  • 目的端口：固定4500（NAT-T 标准端口）
  • 源端口：随机生成（用于 NAT 映射）
• 修改外层 IP 协议字段 ：由50(ESP)改为17(UDP)

关键：内层 ESP 报文（包括内层 IP 头、ESP 头、加密数据）一字不动，完整作为 UDP 的数据载荷。

---

五、为什么 "塞 UDP" 就能穿越 NAT？（NAT 映射核心逻辑）

步骤 1：分支出站→NAT 生成端口映射

当 NAT 设备收到UDP4500 报文时，自动创建映射表：

内网地址:端口 → 公网地址:端口
192.168.1.1:随机源端口 ↔ 203.1.1.5:NAT分配的公网端口

✅ 有了 UDP 端口，NAT 能记录这条流的 "内外对应关系"。

步骤 2：总部回程→NAT 查表转发

总部回复报文：

[IP:202.1.1.1→203.1.1.5] + [UDP:4500→NAT分配的公网端口] + [完整ESP报文]

NAT 设备根据目的 IP (203.1.1.5)+ 目的 UDP 端口 查询映射表，找到内网 192.168.1.1，剥离外层 IP+UDP 头，将内层 ESP 交给分支防火墙解密。

IKE MM3/MM4 的 NAT-D 载荷里存了双方原始 IP + 端口的 HASH 值 ，接收方把 IP 头里的 "路上改后的 IP + 端口" 算 HASH，和 NAT-D 里的原始 HASH 对比；两个 HASH 不一样 = 中间有 NAT ，于是约定把后续 ESP 业务报文整个塞进 UDP4500，靠 UDP 端口让 NAT 能生成映射表，实现回程寻址，完成 NAT 穿越。

---

整体理一遍流程

一、先理清：IKE 主模式 6 个包的完整时序（带端口变化）

用经典拓扑：分支 (192.168.1.1)→NAT (203.1.1.5)→总部 (202.1.1.1)，NAT 在分支侧。

包序号	阶段	端口	核心内容	关键动作
1	MM1	500→500	ISAKMP SA 提议（加密 / 认证算法）	发起方用 UDP500 发起协商
2	MM2	500→500	同意 SA 提议 + Cookie	响应方回复，仍用 UDP500
3	MM3	500→500	KE+Nonce+NAT-D1+NAT-D2	发起方发送密钥交换 + NAT 探测载荷
4	MM4	500→500	KE+Nonce+NAT-D1+NAT-D2+HASH	响应方回复，HASH 值显示 NAT 存在
5	MM5	4500→4500	ID + 认证数据	发起方端口浮动，源目全为 4500
6	MM6	4500→4500	ID + 认证确认	响应方跟随，端口一致

二、为什么第五个包必须改端口？（3 个底层原因）

2.1 根本触发：NAT-D 探测结果为 "存在 NAT"

MM3/MM4 的 NAT-D 载荷是关键：

• 双方计算HASH(原始IP:端口)和HASH(收到的IP:端口)
• 分支计算：HASH(192.168.1.1:500)≠HASH(203.1.1.5:500)→发现 NAT 在自己侧
• 总部计算：HASH(202.1.1.1:500)=HASH(202.1.1.1:500)→确认自己在公网侧
• 结论：必须启用 NAT-T，端口从 500 切换到 4500

2.2 技术必要性：避免 NAT 设备对 500 端口的 "特殊处理"

• 部分 NAT 设备对 UDP500（IKE 默认端口）做严格限制，不做 PAT 或直接阻断
• 切换到 4500（NAT-T 标准端口），NAT 会把它当普通 UDP 流处理，正常做端口映射

2.3 标准要求：RFC3947 强制规定

发起方发现 NAT 后，发送 ID 载荷（MM5）时必须切换到 4500 端口，响应方后续所有报文都必须用 4500 回复IETF Datatracker

三、完整封装过程：从 MM1 到 ESP（每个包的具体字节变化）

3.1 前 4 个包（MM1~MM4）：UDP500 封装（未浮动）

MM3 封装示例（分支→NAT→总部）：

[外层IP头]
  源IP: 192.168.1.1 → 203.1.1.5（NAT修改）
  目的IP: 202.1.1.1
  协议: 17 (UDP)
  总长度: 1200
+ [UDP500头]  ← 固定500<->500
  源端口: 500
  目的端口: 500
  长度: 1180
  校验和: 0x1234
+ [ISAKMP载荷]
  类型: SA+KE+Nonce+NAT-D1+NAT-D2
  NAT-D1: HASH(192.168.1.1:500)
  NAT-D2: HASH(202.1.1.1:500)

✅ 关键：NAT 只改外层 IP，UDP500 头和 ISAKMP 载荷完全不变

3.2 第 5/6 个包（MM5~MM6）：端口浮动到 4500（源目全 4500）

MM5 封装示例（分支→NAT→总部）：

[外层IP头]
  源IP: 192.168.1.1 → 203.1.1.5（NAT修改）
  目的IP: 202.1.1.1
  协议: 17 (UDP)
  总长度: 1200
+ [UDP4500头]  ← 核心变化：源目全4500
  源端口: 4500  ← 不再是500
  目的端口: 4500  ← 不再是500
  长度: 1180
  校验和: 0x5678
+ [ISAKMP载荷]
  类型: ID+认证数据（如预共享密钥HASH）

✅ 关键：发起方主动改端口，NAT 对 4500 做正常 PAT 映射

3.3 业务流量（ESP）：NAT-T 封装（UDP4500+ESP）

协商成功后，ESP 报文的封装（这才是 NAT-T 真正的 "塞 UDP"）：

[外层IP头]
  源IP: 203.1.1.5（NAT转换后）
  目的IP: 202.1.1.1
  协议: 17 (UDP)
  总长度: 1508
+ [UDP4500头]  ← 塞在IP与ESP之间
  源端口: 4500（或随机，取决于设备）
  目的端口: 4500  ← 固定
  长度: 1488
  校验和: 0x0000（可选）
+ [完整原生ESP包]  ← 内层完全不变
  [ESP头]
    SPI: 0x12345678
    序列号: 0x00000001
  + [加密载荷]
    内层IP头: 192.168.1.10 → 10.1.1.10
    TCP头: 源端口12345 → 目的端口80
    HTTP数据: "GET /index.html HTTP/1.1..."
  + [ESP尾部]
    填充字段
    下一个头: 6 (TCP)
  + [ESP认证ICV]
    哈希值: 0xabcdef1234567890

✅ 解决：NAT 基于 UDP4500 端口做映射，回程流量能正确转发

---

总结

本节 2 大核心重难点

1. IPSec 场景的「NAT 穿越≠外网主机主动向内网发起连接」 ：这是 90% 学习者误区。IPSec 的 NAT 穿越，仅指IPSec 隧道保护的两端内网互访流量可以双向通行；NAT-T 做不到让互联网陌生 IP 主动穿透 NAT 访问内网，主动入站是端口映射 / 全锥 NAT 打洞的范畴，二者完全无关。

2. IKE 协商报文（UDP500）天生带四层端口，无论开不开 NAT-T，IKE SA 都能协商建立；原生故障仅出在 ESP 业务报文 ：也就是IPSec 隧道能协商起来，但是两端内网传数据不通，这才是需要 NAT-T 封装 UDP4500 的根本原因。

沿用固定拓扑：
分支防火墙：内网口192.168.1.1，外网口经过 NAPT 转换成公网203.1.1.5；
总部防火墙：公网地址202.1.1.1，无任何 NAT 转换。

一、精准定义：IPSec 里「NAT 穿越（NAT-T）」到底是什么？

1. 正确释义

分支内网网段 ↔ 总部内网网段，被 IPSec 加密后的 ESP 流量，经过中间 NAPT 网关时，出站能正常出去、回程不会被 NAT 丢弃，业务数据正常互通，就叫实现了 IPSec 的 NAT 穿越。

2. 明确排除两件事

① 不是公网随便一台设备主动发起连接访问分支内网（NAT-T 没有这个能力，需要 NAT Server / 端口映射实现）；

② 不是 IKE 协商隧道建立：IKE 基于 UDP500（自带端口），原生就能过 NAPT，不用 NAT-T 也能把 IKE SA 协商成功、隧道建立起来。

举例：不开 NAT-T：IKE 协商 6 个包全部通，IPSec 隧道状态显示 UP，但是分支 PC ping 总部 PC 不通；开启 NAT-T 封装 UDP4500 后，ping 正常通 → 这就是 NAT-T 的作用。

二、NAPT 底层运行规则（能不能穿越的根源）

NAPT（运营商 / 家用路由主流 NAT）核心工作依赖四层端口：

• 内网主机向外发包（TCP/UDP 带端口），NAT 出站生成映射表：【内网IP+内网源端口+协议】 ↔ 【NAT公网IP+NAT分配的公网端口】
• 外网回程报文到达 NAT，依靠目的公网 IP + 目的 UDP/TCP 端口作为唯一索引查表，匹配成功就转发对应内网 IP；无匹配条目直接丢弃数据包。

关键：只有 TCP/UDP 才有四层端口字段，纯三层协议（ESP 协议号 50、GRE47）没有端口，NAPT 无法生成映射条目

三、分两种报文拆解：不加 UDP4500 不行，加上就可以的完整逻辑

场景 1：无 NAT-T、ESP 裸跑（IP 协议号 = 50，IP+ESP 结构，无 UDP 头部）

报文封装：外层IP头(协议=50) + ESP头 + 加密内网原始数据

① 分支出站过程

分支源192.168.1.1→目的202.1.1.1原生 ESP 报文：

NAT 仅能把源 IP 从 192.168.1.1 改成 203.1.1.5；

ESP 没有四层端口→NAPT 缺少生成映射表的关键字段，无法写入 NAT 映射条目。

② 总部回程过程

总部收到 ESP，回复回程 ESP：源202.1.1.1、目的203.1.1.5；

报文送到分支侧 NAT 网关，NAT 查表：没有任何对应此流的映射记录，无法确定要转发给内网哪个设备，直接丢弃 ESP 报文。

最终结果

IPSec 隧道 UP（IKE 协商成功），但两端内网无法互访，ESP 回程丢包→没有实现 NAT 穿越。

修改 IP 头部源 IP ≠ 生成 NAPT 映射表条目

NAT 设备可以随手把报文源 IP 192.168.1.1 改成 203.1.1.5（只是改写数据包三层字段），但NAPT（端口复用 NAT）不会往映射表里写入这条记录；没有表项，回程报文到达后查无记录直接丢弃。

---

场景 2：开启 NAT-T，IP 与 ESP 中间插入 UDP4500 头部（封装：外层 IP+UDP4500 + 完整原生 ESP）

内层 ESP 报文内容一字不动，只在 ESP 整体外面套一层 UDP + 外层 IP。

① 分支出站

整体报文变成 UDP 报文，外层 IP 协议字段从 50 (ESP) 改为 17 (UDP)：

UDP 字段：源端口随机、目的端口固定 4500 ；

NAT 识别为标准 UDP 流量，自动生成端口映射：

192.168.1.1:随机源端口 ↔ 203.1.1.5:NAT分配公网端口，映射存入 NAT 表。

② 总部回程

总部回复报文：外层目的 IP=203.1.1.5，外层 UDP 目的端口 = NAT 分配的公网端口；

NAT 拿着目的IP+目的UDP端口查表，精准匹配内网 192.168.1.1，剥离外层 IP+UDP 头部，把里面原生 ESP 报文交给分支防火墙解密。

最终结果

ESP 来回双向畅通，两端内网可以正常互访→完成 IPSec NAT 穿越。

---

关于端口号4500的补充知识点

一、先拆分两种 4500 端口

我们把流量分成两类，端口规则完全不同：

二、核心原理：NAPT 如何区分多台主机？

三、多主机实战演示（3 台 PC 同时走 IPSec，端口 + 映射表全清晰）

---