• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

ipsec 流量异常

1天前提问
  • 0关注
  • 0收藏,63浏览

问题描述:

防火墙上面IPSec sa和ike sa都存在,但是还是存在流量时通时不通

数据不通的时候重置ipsec sa和ike sa之后,通信回复

麻烦大佬们帮忙分析一下

4 个回答

隧道存在数据不通

暂无评论

粉丝:132人 关注:11人

配置下DPD吧 

暂无评论

粉丝:11人 关注:9人

排查步骤及命令:
1. 查看IPSec SA状态:display ipsec sa,确认SA是否有异常状态(如超时、错误)。
2. 检查IKE SA状态:display ike sa,确认IKE SA是否存在老化或协商失败。
3. 查看SA生命周期:display ipsec profile,确认SA的Lifetime配置是否过短(如3600秒)。
4. 检查ACL规则:display firewall session table,确认流量是否命中IPSec加密策略。
5. 查看系统日志:display logbuffer,检查是否有IPSec相关错误(如SA建立失败、加密算法不匹配)。
6. 检查NAT穿透配置:若两端有NAT,确认nat-traversal参数是否一致,无NAT则排除。
7. 测试丢包:tracert或ping -M do -s 1472(MTU测试),确认中间链路是否丢包。
关键命令:
reset ipsec sa:重置IPSec SA
reset ike sa:重置IKE SA
display crypto ipsec sa detail:详细查看SA状态
display crypto ike sa detail:详细查看IKE SA状态
可能原因:
1. SA生命周期过短导致自动失效,需延长Lifetime。
2. 两端MTU不匹配,需配置DF位或调整MTU。
3. 中间设备(如路由器)对IPSec流量有会话超时限制。
4. 加密算法或认证算法不匹配(如一方使用SHA1,另一方使用MD5)。
5. 防火墙会话表溢出,需增大会话表容量。
建议优先检查SA生命周期和加密参数一致性,其次排查链路MTU和中间设备配置。

暂无评论

粉丝:17人 关注:2人

IPSec SA/IKE SA 存在但流量时通时断,重置 SA 恢复完整排查(H3C SecPath 防火墙)
一、先解读你截图关键信息
Tunnel 状态 Active,ESP 双向 SA 完整存在,IKE 协商正常;
保护流:源 192.168.2.0/24 → 目的 172.16.0.0/12;
现象:隧道在线,但流量随机断流,手动删除 SA 重建立刻恢复,典型SA 老化 / 报文丢包 / 分段 / 路由 / 安全策略类问题。
二、根因分类(按出现概率从高到低)
1. IKE/IPSec SA 生存时间不匹配,旧 SA 未及时删除(最高发)
故障逻辑
IKE SA 默认 86400s,IPSec ESP SA 默认 3600s;
到达 IPSec SA 生命周期时,设备会发起重协商;
若协商报文被防火墙 / 运营商拦截,新 SA 建立失败、旧 SA 老化删除,流量中断;
手动删除 SA = 强制重新协商,临时恢复。
验证 & 修复
查看生命周期
plaintext
display ike sa verbose
display ipsec sa verbose
对比 IKE、IPSec 老化时间,建议缩短 IPSec SA(3600→1800),减少长时间断协商窗口:
plaintext
ike proposal 10
sa-duration 3600
ipsec proposal 10
ipsec policy map 10 isakmp
sa-duration 1800
放行两端公网 UDP 500/4500、ESP 协议 50,运营商 / 对端防火墙不能拦截。
2. 公网 UDP 500/4500、ESP 报文被运营商 QoS / 防火墙丢弃
IPSec 协商、保活报文小包,运营商流量整形、防攻击策略容易丢小包:
抓包看断流时段:公网口收不到对端 IKE 协商报文;
解决:
两端防火墙放行 ESP、UDP500/4500;
运营商侧取消对 ESP/500 端口限流;
开启 IKE 保活心跳:
plaintext
ike keepalive interval 10 retry 3
定时发送探测报文,防止运营商静默断流。
3. 报文 MTU 分段异常,大包丢、小包能通(表现时通时断)
内网大包(文件、视频)超过隧道 MTU,不分片直接丢弃,小包正常:
IPSec 隧道默认 MTU 1400,内网 PC MTU 1500 产生 1460 大包;
修复方案二选一:
plaintext
# 方案1 隧道全局MTU
ipsec tunnel mtu 1400
# 方案2 内网PC/交换机下发TCP MSS
tcp mss 1360
4. 回程路由浮动 / 等价路由 ECMP 导致流量往返不对称
内网访问对端 172.16.0.0 回程存在多条路由,来回路径不一致;
IPSec 要求加密前明文流量进出同一接口,来回接口不同会解密失败、流量中断;
排查:
plaintext
display ip routing-table 172.16.0.0
确保去往对端业务网段只有唯一静态路由,无浮动路由、策略路由干扰。
5. 安全策略 / 域间策略老化、会话表满
外网 untrust→内网 trust 会话表打满,新建流量被丢弃;
IPSec 解密后内网访问策略临时失效;
plaintext
display session table statistics
会话占比 90% 以上则调大会话表容量,缩短老化时间。
6. NAT 干扰(内网源 NAT 与 IPSec 保护流冲突)
内网 192.168.2.0 访问 172.16.0.0,若匹配内网出外网源 NAT,源地址被转换,流量不匹配 IPSec 保护流,直接不通;
必须配置IPSec 豁免 NAT:
plaintext
acl number 3000
rule permit source 192.168.2.0 0.0.0.255 destination 172.16.0.0 0.0.15.255
nat address-group 0
nat policy no-nat
rule permit acl 3000
nat none
没有豁免 NAT,流量随机匹配 NAT 就会时断时续。
7. 两端加密算法 / 校验算法不一致,重协商失败
一端 AES-256+SHA2-256,另一端 AES-256+SHA1,初始协商成功,但 SA 老化重协商失败,流量中断;
核对两端 ike proposal、ipsec proposal 加密、认证算法完全一致。
8. 设备 CPU / 内存高,协商报文处理延迟
plaintext
display cpu-usage
display memory
CPU 长期 80% 以上,IKE 协商线程处理不过来,重协商超时断流。
三、快速定位排查步骤
开启 IKE 保活,观察断流是否减少;
配置 NAT 豁免,排除内网源地址转换干扰;
调整 TCP MSS 1360,解决大包丢包;
核对两端 IKE/IPSec SA 生命周期、加密算法完全统一;
检查去往对端业务网段唯一回程路由,无 ECMP 浮动;
公网口抓包,确认 UDP500/4500、ESP 无丢包;
监控会话表、CPU 资源占用。
极简总结
最常见 3 个诱因:
缺少 IPSec 免 NAT 策略,内网流量随机被 NAT 转换,不匹配保护流;
SA 老化重协商时 UDP500/ESP 小包被运营商拦截,新 SA 建不起来;
MTU 不匹配,大包分段丢弃,表现时通时断。
删除 SA 重建只是临时恢复,必须解决上面底层问题才能根治。

暂无评论

编辑答案

你正在编辑答案

如果你要对问题或其他回答进行点评或询问,请使用评论功能。

分享扩散:

提出建议

    +

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

确定

亲~检测到您登陆的账号未在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. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明