USG6300双出口IPSec tunnel运行一段时间后中断

发布时间:  2016-08-31 浏览次数:  618 下载次数:  0
问题描述

客户反馈FW_A(USG6300)通过双出口连接两个运营商,通过安全策略模板方式与FW_B建立IPSec隧道。

FW_A关于IPSec的配置如下:

#                              
ike proposal 10                
#  
ike peer b 
pre-shared-key %$%$U\zWG^*_4zY'uAgs\e:j'{r%$%$
ike-proposal 10 
#                              
ipsec proposal tran1           
#                              
ipsec policy-template map_temp 1
security acl 3000             
ike-peer b                    
proposal tran1
#       
ipsec policy map1 10 isakmp template map_temp              
#                  
interface GigabitEthernet0/0/5              
ip address x.x.163.1 255.255.255.0       
ipsec policy map1                 
#      

FW_B关于IPSec的配置如下:


ike proposal 10
#  
ike peer a 
pre-shared-key %$%$U\zWG^*_4zY'uAgs\e:j'{r%$%$
ike-proposal 10 
remote-address x.x.163.1
#
ipsec proposal tran1
#
ipsec policy map1 10 isakmp
security acl 3000
ike-peer a
proposal tran1              
#                  
interface GigabitEthernet0/0/5              
ip address x.x.169.1 255.255.255.0       
ipsec policy map1                 
#          

告警信息

查看FW_A有如下告警:

#IPSEC/4/IPSECTUNNELSTOP:1.3.6.1.4.1.2011.6.122.26.6.2 the IPSec tunnel is deleted.

#IPSEC/4/IPSECNEGOFAIL:1.3.6.1.4.1.2011.6.122.26.6.9 IPSec tunnel negotiation fails.

处理过程

1.从问题描述看,IPSec隧道在运行一段时间后中断,说明FW_A和FW_B可以成功建立IPSec隧道。从第二条告警“IPSec tunnel negotiation fails.”可以看出原因是IPSec重协商失败导致隧道中断。

2.IPSec重协商为什么会失败呢? 当IPSec SA老化后,即使配置为安全模板的一端也会发起重协商。我们在FW_B上debug ike all检查一下协商报文交互的情况。

IKE/4/IKEPEER(l): Phase1: cannot find matched IKE peer configuration for peer [x.x.76.66],please check "remote-address" and "exchange-mode" in IKE peer configuration.

3.Debugging信息中x.x.76.66并不是FW_A绑定IPSec接口GigabitEthernet0/0/5 的IP地址,而是GigabitEthernet0/0/4的接口地址。那么IPSec重协商报文为什么会重没有绑定IPSec policy的端口发送出去呢?

由于USG对报文处理流程是先查路由后进行IPSec封装,在双出口等价路由的网络中,如果协商报文从没有绑定IPSec policy的端口发送到对端,对端会检测到报文的源IP与IKE peer的remote-address不一致而导致协商失败。

检查FW_A的路由配置,证实了上面的推断:

#
ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet0/0/4 x.x.76.65
ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet0/0/5 x.x.163.1
#

4.至此,问题原因已经清楚,但是为什么IPSec最开始可以协商成功呢?  这是由于FW_A是安全模板,初次协商是FW_B发起的,FW_B无论以哪个端口发送协商报文,FW_A都不检查remote-address,所以成功建立IPSec隧道。

根因
IPSec SA老化后,重协商报文从未绑定IPSec policy的端口发送,该接口IP地址与对端设备的remote-address不一致,导致协商失败。
解决方案

1.针对上述分析,最根本的原因是USG没有自动选择从已绑定IPSec policy的端口发送重协商报文,所以可以考虑配置策略路由,重协商报文出接口为绑定IPSec policy的端口。但是当前USG不支持基于local的策略路由,所以该方案暂时行不通,只能通过后续需求解决。

2.现网最终采用次优方案,将出接口为GigabitEthernet0/0/4的默认路由优先级降低,重协商报文优先从绑定IPSec policy的接口GigabitEthernet0/0/5发出。

3.后续优化,建议客户配置IPSec主备链路备份实现高可靠性。配置方法参考产品手册,这里不再赘述。

建议与总结
在多出口网络部署和故障定位中,一定要注意策略的优先级,可以借助session表、debug等信息快速梳理转发流程并找到问题根因。

END