建立IPSEC隧道后不稳定时断时续

发布时间:  2012-07-17 浏览次数:  303 下载次数:  0
问题描述
两台USG设备建立ipsec vpn,但是出现一段时间能够建立隧道,一段时间不能够建立隧道的现象。
组网如图:

A地点USG2160(211.161.103.10 )------internet-------(58.210.140.210 )B地点USG2130
告警信息
处理过程
1、不能建立隧道时,分别在两端抓包,发现两端ipsec协商报文发出,但是都收不到来自对端协商报文:
A地点端抓包:
B地点端抓包:
因此初步判断可能两端间链路存在问题。
2、建立不成功时:
偶尔在B地点端发现有如下隧道:
dis ike sa
08:57:00 2012/05/24
current ike sa number: 1
---------------------------------------------------------------------
connection-id peer vpn flag phase doi
--------------------------------------------------------------------
0xdda 222.73.189.2 0 RD|ST v2:1 IPSEC
在B地点端发现始终存在有如下会话:
display firewall session table v source inside 222.73.189.2
10:35:31 2012/05/25
Current Total Sessions : 1
udp VPN:public --> public
Zone: untrust--> local TTL: 00:02:00 Left: 00:01:25
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:0 bytes:0 -->packets:196 bytes:58016
222.73.189.2:65181-->58.210.140.210:500
222.73.189.2:65181-->58.210.140.210:500表明222.73.189.2往58.210.140.210发起端口为500的访问,即是ipsec使用的端口,但是B地点端只与A地点建立ipsec,并无何该地址有任何联系。
3、调整配置,让两端无数据流触发,保证会话老化,如果是B地点端先发起访问,可建立隧道,如果是A地点端先主动发起,则可能建立,也可能不能建立。建立隧道成功后信息:
dis ike sa
10:46:06 2012/05/25
current ike sa number: 2
---------------------------------------------------------------------
connection-id peer vpn flag phase doi
--------------------------------------------------------------------
0x15c9 211.161.103.10 0 RD v2:2 IPSEC
0x15c8 211.161.103.10 0 RD v2:1 IPSEC
display firewall session table v source inside 222.73.189.2
10:50:46 2012/05/25
Current Total Sessions : 2
esp VPN:public --> public
Zone: untrust--> local TTL: 00:10:00 Left: 00:10:00
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:0 bytes:0 -->packets:8470 bytes:9864064
222.73.189.2:0-->58.210.140.210:0
udp VPN:public --> public
Zone: untrust--> local TTL: 00:02:00 Left: 00:00:44
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:14 bytes:1232 -->packets:14 bytes:1232
222.73.189.2:48534-->58.210.140.210:500

ipsec建立对端地址是A地点的211.161.103.10,但是会话里面有地址222.73.189.2,表明可能A地点过来的报文地址被修改为222.73.189.2
4、验证前面的分析推断:
B地点pingA地点,在A地点端看会话,正常:
dis firewall session table source global 58.210.140.210
03:17:44 2012/05/25
Current Total Sessions : 1
icmp VPN:public --> public 58.210.140.210:44072-->211.161.103.10:2048
A地点pingB地点,在B地点上看会话,没有来自A地点的icmp会话:
display firewall session table v source global 211.161.103.10
11:00:15 2012/05/25
Current Total Sessions : 1
esp VPN:public --> public
Zone: untrust--> local TTL: 00:10:00 Left: 00:09:59
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:0 bytes:0 -->packets:3269 bytes:934928
211.161.103.10:0-->58.210.140.210:0
display firewall session table v source global 211.161.103.10

但是却在B地点端发现多了来自222.73.189.2icmp报文信息,说明在A地点端和B地点端之间访问地址被替换:
display firewall session table v source inside 222.73.189.2
11:01:35 2012/05/25
Current Total Sessions : 8
esp VPN:public --> public
Zone: untrust--> local TTL: 00:10:00 Left: 00:01:07
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:0 bytes:0 -->packets:32559 bytes:40045352
222.73.189.2:0-->58.210.140.210:0
icmp VPN:public --> public
Zone: untrust--> local TTL: 00:00:20 Left: 00:00:00
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:1 bytes:84 -->packets:1 bytes:84
222.73.189.2:35917-->58.210.140.210:2048
根因

1、设备配置不一致。

2、两端为配置dpd。

3、中间链路问题。

建议与总结
由于A地点端和B地点端的报文访问时,中间链路运营商存在地址被替换的现象,影响到IPSEC协商和建立,中间链路导致不稳定,导致建立时断时续。

END