secpath建立ipsec不成功
- 0关注
- 0收藏，71浏览
问题描述：
两台一样secpath的设备，按照官网文档方式建立ipsec不成功，web诊断显示ike协商结果超时。
dis ipsec statistics 显示No available SA: 5604，Decapsulation failure: 434
##
display ike sa
Connection-ID Remote Flag DOI
------------------------------------------------------------------
10203 60.XXXXXXX Unknown IPsec
Flags:
RD--READY RL--REPLACED FD-FADING RK-REKEY
##
display ike sa verbose
-----------------------------------------------
Connection ID: 10203
Outside VPN:
Inside VPN:
Profile:
Transmitting entity: Responder
Initiator COOKIE: 5d7ee4cfddb127f1
Responder COOKIE: 0a2da94d1f2504aa
-----------------------------------------------
Local IP: 222.XXXXXX
Local ID type: Unknown
Local ID:
Remote IP: 60.XXXXXX
Remote ID type: Unknown
Remote ID:
Authentication-method: PRE-SHARED-KEY
Authentication-algorithm: SHA1
Encryption-algorithm: 3DES-CBC
Life duration(sec): 86400
Remaining key duration(sec): 0
Exchange-mode: Main
Diffie-Hellman group: Group 2
NAT traversal: Not detected
Extend authentication: Disabled
Assigned IP address:
Vendor ID index:0xffffffff
Vendor ID sequence number:0x0
##
参考视频案例检查配置。11-IPsec典型配置举例演示视频视频
就是按照这个配置的，还是不成功
解决了，之前配置有问题，没写安全策略啥的，主要是后面修改了一次预共享密钥，但是网页端修改之后默认不重置进程，之前已经建立的SA不会重置，网页端也没有重置选项，需要登录命令行reset ike/ipsec sa一下
排查步骤：
1. 检查连通性：确认两端IP地址能互通，`ping`测试，并检查是否有中间设备（如防火墙）阻断了UDP 500/4500端口。
2. 检查IKE提议：两端执行 `display ike proposal`，确认加密算法、认证算法、DH组、认证方法（`pre-share`）完全一致。
3. 检查IKE对等体：执行 `display ike peer`，确认：
* 对端地址配置正确。
* 预共享密钥一致。
* 引用的IKE提议一致。
* `local-address`（如有配置）与对端`ike peer`中配置的地址匹配。
4. 检查安全策略/策略模板：确认IPsec策略或策略模板正确引用了IKE对等体，并应用到正确的接口。
5. 开启IKE调试（生产环境谨慎）：`debugging ike all`，然后触发协商，观察日志 (`display logbuffer`)。
关键命令检查：
display ike proposal
display ike peer
display ipsec policy
display ipsec statistics
信息补充：请提供两端IKE提议、IKE对等体、IPsec策略的配置片段，以及 `display ike sa verbose` 的完整输出。
从你提供的信息来看，问题的核心在于两台防火墙的IPsec协商参数不一致，导致IKE第一阶段未能成功建立。
display ike sa 显示的状态为 Unknown，说明你的设备在发起协商后，一直没有收到对端的正确响应，一直在重传协商报文。这就像打电话，你的设备一直在拨号，但对方要么占线、要么号码不对，导致通话始终无法接通。
同时，No available SA 和 Decapsulation failure 这两个计数器，是第二阶段协商失败的典型表现。只有IKE第一阶段（ISAKMP SA）成功建立，才会开始第二阶段的IPsec SA协商。因此，根源还是在于第一阶段的参数不匹配。
第一步：核对核心配置参数
请重点检查两端的以下配置，必须确保完全一致：
| 配置项 | 检查方法 | 常见不一致点 |
|---|---|---|
| 预共享密钥 (PSK) | display current-configuration | include pre-shared-key | 大小写错误、特殊字符缺失、复制时带入空格 |
| IKE 版本 | display ike proposal | 一端配置 IKEv1，另一端配置 IKEv2 |
| IKE 协商模式 | display ike profile | 一端配置主模式 (Main)，另一端配置野蛮模式 (Aggressive) |
| IKE 提议 (Proposal) | display ike proposal | 加密/认证算法（如 3DES-CBC 与 AES-128）、DH组（如 Group 2 与 Group 5）不一致 |
| 对端地址 | display ike profile | 一方地址填写错误，或一方有 NAT 而另一方未开启 NAT-T |
第二步：启用 Debugging 进行精确定位
如果手工核对后问题依旧，可以使用 Debugging 功能来捕获详细的协商失败原因。请按以下步骤操作：
开启调试：在两台设备上分别执行以下命令，开启 IKE 的调试信息输出。
<H3C> terminal debugging<H3C> terminal monitor
<H3C> debugging ike all触发协商：从一端的内网向对端内网发起访问（如
ping），以触发 IPsec 协商。分析日志：观察设备输出的调试信息，通常会有明确的错误提示。
NO_PROPOSAL_CHOSEN: 提议不匹配。检查加密、认证算法及 DH 组。
AUTHENTICATION_FAILED: 认证失败。重点检查预共享密钥是否正确。
INVALID_ID_INFORMATION: 身份信息无效。检查两端配置的 ID 类型和内容是否匹配。
TS_UNACCEPTABLE: 感兴趣流不匹配。检查两端的 ACL 是否镜像对称。
我是按照官网文档web页面配置的，两边配置参数一样，但是就是不成功
我是按照官网文档web页面配置的，两边配置参数一样，但是就是不成功
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
解决了，之前配置有问题，没写安全策略啥的，主要是后面修改了一次预共享密钥，但是网页端修改之后默认不重置进程，之前已经建立的SA不会重置，网页端也没有重置选项，需要登录命令行reset ike/ipsec sa一下