USG5120与友商fortigate对接IPsec隧道建立失败

发布时间:  2013-11-04 浏览次数:  933 下载次数:  0
问题描述
用户更换USG5100 IPsec隧道出接口的IP地址后IPsec对接不成功,ike sa建立不起来,打开debug也没有任何调试信息输出。

业务组网图:

告警信息
处理过程
(1)首先检查防火墙的配置,确认防火墙的域间策略是否阻断掉了IPsec协商报文。检查配置发现,由于修改了设备的公网地址,但是在域间并没有放开local域该接口修改后IP地址的安全策略,如下:
policy interzone local untrust inbound
policy 0
  action permit
  policy destination x.x.x.194 0
  policy destination x.x.x.195 0
  policy destination x.x.x.205 0
  policy destination x.x.x.206 0
  policy destination x.x.x.70 0                   //目前设备接口地址是y.y.y.70
(2)修改上述的安全策略的配置错误后,在开启debug的情况下,防火墙能够输出debug信息。但是IPsec隧道仍然无法协商成功,IPsec第一阶段已经协商成功了,但是第二阶段没有协商起来。ike sa的信息如下:
<USG5100>display ike sa
13:51:10  2013/10/18
current ike sa number: 2
--------------------------------------------------------------------------------------
conn-id    peer                    flag          phase vpn
--------------------------------------------------------------------------------------
40224      <unnamed>             NONE         v1:2  public
40223      121.15.84.73            RD|D          v1:1  public
(3)开启debug开关,分析协商上输出的debug信息发现如下内容:
*0.1361275530 USG5100 IKE/7/DEBUG:Add message: type 24
*0.1361275540 USG5100 IKE/7/DEBUG:Get IPsec policy: get IPsec policy failed
*0.1361275540 USG5100 IKE/7/DEBUG:validate_prop: no IPsec policy found
*0.1361275540 USG5100 IKE/7/DEBUG:dropped message from 121.15.84.73 due to notification type INVALID_ID_INFORMATION

防火墙收到INVALID_ID_INFORMATION类型的消息,表示隧道两端的协商的保护数据流不一致,导致隧道协商不成功。但是反复确认两端设备保护数据流的配置都是一致的。相应的配置信息如下:
USG防火墙的相关配置:
acl number 3000
rule 5 permit ip source 192.168.9.0 0.0.0.255 destination 192.168.20.0 0.0.0.255
#                                        
ipsec policy-template map 1              
security acl 3000
ike-peer vpn
proposal vpn2
sa duration time-based 1800
对端fortigate防火墙的相关配置:
 
经过上述分析和确认,怀疑是协商的保护数据流不对。于是经客户同意,尝试放大USG防火墙侧的保护数据流的范围进行测试(USG防火墙侧配置模板方式,可以修改acl进行测试)。修改acl 3000为如下内容:
acl number 3000
rule 5 permit ip source 192.168.9.0 0.0.0.255
#                                        
ipsec policy-template map 1
security acl 3000
ike-peer vpn
proposal vpn2
sa duration time-based 1800
使用上述配置进行IPsec隧道协商测试,发现隧道能够协商成功,并且发现协商出来的隧道的保护数据流是:192.168.9.0/24~121.15.58.213/32,IPsec隧道详细信息如下:
<USG5100>dis ike sa     //ike sa 两个阶段都协商成功了
15:42:14  2013/10/21
current ike sa number: 3
----------------------------------------------------------------------------------------
conn-id    peer                    flag          phase vpn
----------------------------------------------------------------------------------------
40081      x.15.58.213           RD|D         v1:2  public
40079      x.15.58.213           RD|D         v1:1  public

  flag meaning
  RD--READY    ST--STAYALIVE  RL--REPLACED      FD--FADING
  TO--TIMEOUT  TD--DELETING   NEG--NEGOTIATING  D--DPD
<USG5100>
<USG5100>dis ipsec sa     //IPsec隧道也协商成功了
15:42:18  2013/10/21
===============================
Interface: GigabitEthernet0/0/0
    path MTU: 1500
===============================

  -----------------------------
  IPsec policy name: "2"
  sequence number: 1
  mode: template
  vpn: public
  -----------------------------
    connection id: 40082
    rule number: 4294967295
    encapsulation mode: tunnel
    holding time: 0d 0h 29m 18s
    tunnel local : x.113.66.162    tunnel remote: y.15.58.213
    flow      source: 192.168.9.0/255.255.255.0 0/0
    flow destination: x.15.58.213/255.255.255.255 0/0
     //协商出来的保护数据流

    [inbound ESP SAs]
      spi: 2444424488 (0x91b2f528)

  经过以上分析发现,由于对端设备发起的协商数据流错误,不是其配置的保护数据流,导致隧道协商不成功。
根因
由于问题现象看,在防火墙上开启debug开关后,没有任何debug信息输出。同时公网链路能正常ping通,由此,问题原因有如下怀疑点:
(1) 对端没有发起协商;
(2) 对端发起协商,但是中间网络设备阻断了协商报文;
(3) 报文到防火墙了,但是没有被争取处理;
建议与总结
由于对端设备发起协商的数据流不是其设备配置的保护数据流导致IPsec隧道协商失败。需要对端设备解决该问题。
建议:在定位此类与友商设备对接的问题时,要做充分的验证和分析。不能假设友商设备完全没有问题。在确认是保护数据流不一致的情况下,可以采用放大配置模板方式一侧的保护数据流的范围进行测试。

END