由于流量超时导致IPSec业务中断

发布时间:  2014-09-20 浏览次数:  313 下载次数:  0
问题描述
组网结构:
Peer Device(60.247.x.y)-----------(IPSec)---------------防火墙
防火墙与远端peer(60.247.x.y)建立IPsec vpn,有一个业务是远端peer下的某终端(10.217.18.97)每周末向本端下的终端(10.217.1.5)进行大容量数据的备份业务,约20G,在传了一段时间(几个小时左右,但时间不固定)后,会出现中断,过一段时间后能恢复重连。其他业务正常。
处理过程
1. 查看IPsec隧道,协商正常.
HRP_M<USG-1> display ike sa
288342     60.247.x.y              RD            v1:2  public
288339     60.247.x.y              RD            v1:2  public
288338     60.247.x.y              RD            v1:2  public
288337     60.247.x.y              RD            v1:2  public
288336     60.247.x.y              RD            v1:2  public
288335     60.247.x.y              RD            v1:2  public
288334     60.247.x.y              RD            v1:2  public
288332     60.247.x.y              RD            v1:2  public
288331     60.247.x.y              RD            v1:2  public
288288     60.247.x.y              RD|D          v1:1  public

从上面采集的信息来看,现网使用IKEv1进行协商.
2. 如果业务会出现中断,一般情况下可能是由于隧道中断导致.而且业务可以自动恢复重连,说明隧道又可以协商成功。
3. 从上面的推断来看,有两种可能原因导致。
a. 由于网络拥塞,IPSec重协商失败,导致隧道中断,通过ping测试发现网络状况没有问题.排除该原因导致.
b. 每次出现故障的时候,都是在备份业务,即出现大流量的时候.所以应该和流量相关,IPSec隧道的生命周期有两种,一个是时间生命周期,一个是流量生命周期.所以可能是流量导致的IPSec流量超期.
4. 根据上面的可疑点作进一步分析,由于防火墙作为IKEv1的被动方,对端为IKEV1的发起方,由于IKEv1实现机制问题,只有触发端才能发起重协商.另外流量的生命周期都以隧道的入流量进行统计,从上面的信息分析,对端在备份报文的时候,有大量的入报文进入防火墙,流量作为入隧道,会导致防火墙IPSec隧道的生命周期超时,同时防火墙又作为响应端,不会发起重协商,导致隧道和业务出现中断.
根因
防火墙作为ikev1协商的响应端时,隧道不会因为流量超时而发起重协商,导致隧道中断.
解决方案
在IPsec策略试图下关闭流量超时.方法如下:
ipsec policy 1 1 isakmp                                                                                                             
undo sa duration traffic-based enable

END