问

防火墙做IPSec建立不了ike sa

2026-04-15提问

0关注
0收藏，183浏览

塵

塵零段

粉丝：0人关注：0人

问题描述：

<bestvike>dis ike sa verbose con 10542408

-----------------------------------------------

Connection ID: 10542408

Outside VPN:

Inside VPN:

Profile: GE1/0/6_IPv4_113

Transmitting entity: Initiator

-----------------------------------------------

Local IP: 60.208.26.242

Local ID type: IPV4_ADDR

Local ID: 60.208.26.242

Remote IP: 121.26.2.250

Remote ID type: Unknown

Remote ID:

Authentication-method:

Authentication-algorithm:

Encryption-algorithm:

Life duration(sec): 0

Remaining key duration(sec): 0

Exchange-mode: Aggressive

Diffie-Hellman group: Group 14

NAT traversal: Not detected

Extend authentication: Disabled

Assigned IP address:

查看ike sa发现主动发起的ike没有携带信息呢，这是什么情况？

5 个回答

按时间按赞数

我是谁呢

我是谁呢四段

粉丝：6人关注：8人

检查下配置

暂无评论

刘浩存

刘浩存八段

粉丝：13人关注：1人

从你的 display ike sa verbose 结果来看，IKE协商的发起方参数大量缺失，这通常是IKE协商根本没有正常启动，或设备在启动阶段就因参数不匹配而中止了。

最可能的原因有两个：一是触发的感兴趣流ACL配置有问题，导致报文没有命中IPsec策略；二是野蛮模式下本端/对端的身份标识（ID）配置不当或缺失。

核心排查步骤

1. 检查感兴趣流ACL与策略引用

IKE协商由“感兴趣流”触发。首先要确认触发IPsec隧道的流量是否正确匹配了IPsec策略中引用的ACL规则。

查看IPsec策略引用的ACL：执行 display ipsec policy 找到该隧道对应的策略，记下引用的ACL编号（如3000）。
检查ACL规则：执行 display acl all，确认规则中源/目的地址与发起端和接收端的实际网段完全匹配，特别注意掩码是否正确。
确认策略应用：确保IPsec策略已正确应用在公网接口（如 GigabitEthernet1/0/6）上，且方向无误。
排除NAT干扰：如果公网接口启用了NAT（Easy IP），需要确保NAT策略排除了IPsec流量。可以在ACL中增加 deny 规则，让IPsec流量不进行NAT转换。

2. 核对IKE Profile和Keychain配置

野蛮模式对身份标识（ID）和匹配规则要求严格。你的日志中 Remote ID type: Unknown，表明对端ID识别失败，通常是 ike profile 或 keychain 配置有误。

确认IKE版本与模式：确保两端IKE版本（如IKEv1）和协商模式（Aggressive/野蛮模式）一致，命令为 exchange-mode aggressive。
检查预共享密钥：确认两端预共享密钥（PSK）完全一致，检查 keychain 配置是否正确引用。
核对身份标识（关键）：野蛮模式常通过ID互相识别，确保本地和对端的ID类型（address 或 fqdn）及值严格匹配。
核对对端地址：若对端地址固定，remote-address 应配置为对端公网IP。若对端地址动态，remote-address 可配置为 0.0.0.0，并依赖ID匹配。

3. 检查IPsec安全提议与策略完整性

确保两端的IPsec安全提议（ipsec transform-set）和策略引用无误。

核对安全提议参数：确认两端的 ipsec transform-set 在封装模式（tunnel/transport）、安全协议（ESP/AH）、加密和认证算法上完全一致。
检查策略完整性：确认IPsec策略已正确绑定ACL、ike-profile、transform-set 和对端地址。

4. 启用调试与抓包分析

如果上述配置检查无误，需要通过实时调试和抓包定位深层原因。

开启Debug调试：在设备上通过 debugging ike all 和 debugging ipsec all 查看详细协商日志，注意NO_PROPOSAL、AUTH_FAIL等错误关键字。
进行报文抓包：在防火墙内联口或出口镜像流量抓包，分析UDP 500/4500端口的ISAKMP报文，检查是否存在报文重传或参数不匹配。

暂无评论

zhiliao_sEUyB

zhiliao_sEUyB 九段

粉丝：98人关注：11人

ipsec sa建立起来了？

暂无评论

沉鱼落雁_解决问题看主页

沉鱼落雁_解决问题看主页九段

粉丝：77人关注：0人

参考案例检查下配置。1.16 IPsec典型配置举例

暂无评论

zhiliao_GeOM0O

zhiliao_GeOM0O 七段

粉丝：10人关注：2人

从你提供的 dis ike sa verbose 信息来看，IKE SA 状态异常、协商完全卡住，核心表现是：

Remote ID type: Unknown（对端 ID 类型未知）
Remote ID: 空
Authentication-method /algorithm/ Encryption-algorithm 全空
Life duration / Remaining key duration 都是 0
Exchange-mode: Aggressive（野蛮模式）

这说明：本端虽然发起了 IKE 协商，但根本没收到对端的有效响应，连最基本的 IKE 提案（加密 / 认证 / DH）都没匹配上，对端 ID 也没解析出来。

一、直接原因（从输出反推）

野蛮模式（Aggressive Mode）下，对端没有正确返回 ID 信息
- 野蛮模式不像主模式先加密再传 ID，而是明文带 ID 发起。
- 你这里：Remote ID type: Unknown + Remote ID: 空 → 对端根本没回 ID 载荷，或回的 ID 格式本端不认。
IKE 安全提议（Proposal）完全不匹配
- 加密 / 认证 / DH 组 / 认证方式（预共享密钥）两端不一致 → 导致协商直接失败，算法字段全空。
对端无响应 / 被中间网络拦截
- UDP 500 / 4500（NAT-T）被防火墙 / 运营商拦截，只有发包、没有收包。

二、分步排障（按优先级）

1. 先确认基础连通性与端口

bash

运行

# 1) ping 对端公网IP
ping -a 60.208.26.242 121.26.2.250

# 2) 确认UDP 500、4500放通（本地+中间+对端）
display firewall statistic | include 500
display firewall statistic | include 4500

# 3) 抓包（重点看是否有出无回）
display ike statistics  # 看IKE报文收发计数

现象：只有 Tx 增长、Rx 为 0 → 中间拦截或对端没启 / 没响应。

2. 检查 IKE Peer 关键配置（必查）

你用的是野蛮模式（Aggressive），ID 配置是致命点：

bash

运行

display ike peer 名称 verbose

必须匹配的 5 项（一端发起、一端响应）：

exchange-mode aggressive → 两端必须一致
id-type（本端 / 对端 ID 类型）
- 野蛮模式下必须显式指定：id-type ip 或 id-type name
- 你这里本端是 IPV4_ADDR，对端必须同类型且 ID 正确
pre-shared-key 完全一致（大小写、特殊字符）
ike proposal 完全一致：
- encryption（AES/DES/3DES）
- authentication（SHA1/SHA2/MD5）
- dh group（Group14=2048bit，两端必须一样）
remote-address 正确（121.26.2.250）

典型错误（你大概率踩坑）：

本端 id-type ip，对端配成 id-type name → ID 类型不匹配 → Remote ID Unknown
野蛮模式下没配 remote-id /remote-name → 对端不知道认哪个 ID
Proposal 一端 AES-256+SHA2-256+Group14，另一端 DES+MD5+Group2 → 完全不匹配

3. 修复配置（野蛮模式标准模板）

bash

运行

# 本端（60.208.26.242）关键配置
ike proposal 10
 encryption-algorithm aes-256  # 与对端一致
 authentication-algorithm sha2-256
 dh group14
 sa duration 86400

ike peer GE1/0/6_IPv4_113
 exchange-mode aggressive       # 野蛮模式
 pre-shared-key simple ******** # 密钥一致
 ike-proposal 10
 remote-address 121.26.2.250
 id-type ip                     # 本端ID类型：IP
 local-id 60.208.26.242         # 本端ID
 remote-id 121.26.2.250         # 对端ID（必须配！野蛮模式必填）
 nat traversal                  # 如中间有NAT需开启

重点：野蛮模式一定要配 remote-id，否则对端 ID 无法识别 → Unknown。

4. 开启 Debug 定位（最准）

bash

运行

terminal monitor
terminal logging
debug ike packet    # 看IKE报文收发
debug ike error    # 看错误信息

典型报错：

ID payload not found → 对端没回 ID
No proposal chosen → 安全提议不匹配
Pre-shared key authentication failed → 密钥错
No response from peer → 对端无响应

5. 对端侧检查（必须同步）

对端必须：
- 同模式：aggressive
- 同 Proposal：加密 / 认证 / DH
- 同 ID 类型：ip
- 同密钥
- 正确配置 local-id / remote-id
若对端是友商（华为 / 深信服 / 思科）：野蛮模式 ID/Proposal 兼容性极差，优先改用 主模式（Main Mode）。

三、你现场 90% 可能性

野蛮模式下没配 remote-id → 对端 ID Unknown
IKE 安全提议（加密 / 认证 / DH）两端不一致 → 算法全空
中间防火墙 / 运营商拦截 UDP 500/4500 → 只有发没有收

四、快速修复方案

补配 remote-id（野蛮模式必须）
两端 Proposal 严格对齐（AES-256/SHA2-256/Group14）
确认 UDP 500/4500 全路径放通
仍不行：换成主模式（Main Mode）（兼容性更好）

五、验证命令

bash

运行

# 清理旧会话
reset ike sa con 10542408
reset ike statistics

# 重新触发流量（ping 对端内网）
# 再查
display ike sa verbose
display ike proposal
display ike peer

正常状态：

Remote ID type: IPV4_ADDR
Remote ID: 121.26.2.250
加密 / 认证 / DH 全部显示
State: Up

暂无评论

编辑答案

分享扩散:

➤

网站相关: 关于我们; 服务条款; 隐私政策; 帮助中心; 经验与权限; 积分规则

联系我们: 联系我们; 建议反馈

常用链接: 标杆的神器下载

关注我们: H3C官网; 新华三服务公众号; 安仔远程运维服务; 新华三商城

内容许可: 除特别说明外，用户内容均可采用知识共享署名-相同方式共享3.0中国大陆许可协议进行许可

本图标版权归新华三集团所有，仅限本社区使用，切勿用做商业目的，违者必究

浙ICP备09064986号-1 浙公网安备 33010802004416号

✖

亲~登录后才可以操作哦!

确定

✖

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

✖

你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作

✖

侵犯我的权益 >

对根叔社区有害的内容 >

辱骂、歧视、挑衅等（不友善）

侵犯我的权益

泄露了我的隐私 >

侵犯了我企业的权益 >

抄袭了我的内容 >

诽谤我 >

辱骂、歧视、挑衅等（不友善）

骚扰我

泄露了我的隐私

您好，当您发现根叔知了上有泄漏您隐私的内容时，您可以向根叔知了进行举报。请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱，我们会尽快处理。

1. 您认为哪些内容泄露了您的隐私？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
2. 您是谁？（身份证明材料，可以是身份证或护照等证件）

侵犯了我企业的权益

您好，当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时，您可以向根叔知了进行举报。请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱，我们会在审核后尽快给您答复。

1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
3. 是哪家企业？（营业执照，单位登记证明等证件）
4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）

我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

原文链接或出处

诽谤我

您好，当您发现根叔知了上有诽谤您的内容时，您可以向根叔知了进行举报。请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱，我们会尽快处理。

1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
2. 您是谁？（身份证明材料，可以是身份证或护照等证件）

我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔社区有害的内容

垃圾广告信息

色情、暴力、血腥等违反法律法规的内容

政治敏感

不规范转载 >

辱骂、歧视、挑衅等（不友善）

骚扰我

诱导投票

不规范转载

举报说明

产品线		搜索取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式	默认策略匹配全词匹配整句

防火墙做IPSec建立不了ike sa

问题描述：

核心排查步骤

1. 检查感兴趣流ACL与策略引用

2. 核对IKE Profile和Keychain配置

3. 检查IPsec安全提议与策略完整性

4. 启用调试与抓包分析

一、直接原因（从输出反推）

二、分步排障（按优先级）

1. 先确认基础连通性与端口

2. 检查 IKE Peer 关键配置（必查）

3. 修复配置（野蛮模式标准模板）

4. 开启 Debug 定位（最准）

5. 对端侧检查（必须同步）

三、你现场 90% 可能性

四、快速修复方案

五、验证命令

编辑答案

提出建议