USG2110-F(分支)和USG2120BSR(总部) IPsec VPN建立成功,但是定义的保护数据流无法ping通

发布时间:  2015-04-07 浏览次数:  901 下载次数:  0
问题描述

组网结构:

故障现象及操作记录:

客户的目的是使得10.86.3.111能访问分支10.77.0.8的服务器。查看配置,配置是正确的,从总部USG2120BSR去ping -a 10.86.3.1  10.77.8.1 是不通的,

PC1与server依然也不通。采集两端的ike sa 和 ipsec sa主要信息截取如下:

 总部USG2120BSR:

 <USG_SHA>dis ike sa
 -----------------------------------------------------------------------------
 conn-id    peer                    flag          phase vpn
 -----------------------------------------------------------------------------
 
40065      114.95.232.160          RD            v2:2  public
 40064      114.95.232.160          RD|ST         v2:2  public
 40067      114.95.232.160          RD|ST         v2:2  public
 40066      114.95.232.160          RD|ST         v2:2  public

 31         114.95.232.160          RD|D          v2:1  public
 
 

 

<USG_SHA>Dis IPsec  sa

-----------------------------
   IPsec policy name: "map1"
   sequence number: 10
   mode: template
   vpn: public
   -----------------------------
     connection id: 40299
     rule number: 4294967295
     encapsulation mode: tunnel
     holding time: 0d 12h 44m 47s
     tunnel local : 101.230.16.72  tunnel remote: 114.95.232.106
     
flow      source: 10.86.0.0-10.86.3.255 0-65535 0
     flow destination: 10.77.0.0-10.77.15.255 0-65535 0
  
 

 

分部USG2110F:

 

 [10.86.32.2]dis ike sa
 current ike sa number: 5
 -----------------------------------------------------------------------------
 conn-id    peer                    flag          phase vpn
 -----------------------------------------------------------------------------
 40787      101.230.16.72        RD|ST         v2:2  public
 40786      101.230.16.72        RD            v2:2  public
 40789      101.230.16.72        RD            v2:2  public
 40788      101.230.16.72        RD            v2:2  public
 41         101.230.16.72        RD|ST|D       v2:1  public

 
  

 [10.86.32.2]dis IPsec sa

 

 flag meaning
   RD--READY    ST--STAYALIVE  RL--REPLACED      FD--FADING
   TO--TIMEOUT  TD--DELETING   NEG--NEGOTIATING  D--DPD

 

   -----------------------------
   IPsec policy name: "map1"
   sequence number: 10
   mode: isakmp
   vpn: public
   -----------------------------
     connection id: 40846
     rule number: 15
     encapsulation mode: tunnel
     holding time: 0d 12h 47m 1s
     tunnel local : 114.95.232.106    tunnel remote: 101.230.16.72
 
    flow      source: 10.77.0.0-10.77.15.255 0-65535 0
     flow destination: 10.86.0.0-10.86.3.255 0-65535 0

 

从如上信息可以看出IPsec VPN 隧道是建立成功的,但实际测试PC和server之间是无法互相ping通的!
     

告警信息
处理过程

1.在两端的设备上做会话采集

 分部USG2110F
 [10.86.32.2]display firewall session table verbose source inside 10.77.0.8

   icmp  VPN:public --> public
   Zone: trust--> untrust  TTL: 00:00:20  Left: 00:00:15
   Interface: Dialer0  NextHop: 10.86.3.111  MAC: 00-00-00-00-00-00
   <--packets:0 bytes:0   -->packets:6294 bytes:377640
   10.77.0.8:10-->10.86.3.111:2048
(分部只有出去的ICMP包)

 

 

总部USG2120BSR

 

 <USG_SHA>display firewall session table verbose source global 10.77.0.8
  Current Total Sessions : 2
   icmp  VPN:public --> public
   Zone: untrust--> local  TTL: 00:00:20  Left: 00:00:20
   Interface: InLoopBack0  NextHop: 127.0.0.1  MAC: 00-00-00-00-00-00
   <--packets:6199 bytes:371940   -->packets:6199 bytes:371940
   10.77.0.8:10-->10.86.3.1:2048
(有收到报文和回应报文的会话)

 

从会话信息分析来看,数据包是在回程的过程中丢在了USG2110F的设备上或者运营商

 

 

2.根据如上的会话信息分析,在分部USG2110F做流量统计,确认一下丢包在哪里及原因

备注:做流统时,终端设备都一直开启长ping的。

 

分部USG2110F:

 

 [10.86.32.2]ACL 3333
 [10.86.32.2-acl-adv-3333]rule  permit ip source 10.86.3.111 0 destination 10.77. 0.8  0
 [10.86.32.2-acl-adv-3333]q

 [10.86.32.2]diagn

 [10.86.32.2-diagnose]display firewall statistic acl
 09:48:56  2015/01/14
 
  Current Show sessions count: 0
 
 [10.86.32.2-diagnose]display firewall statistic acl
 09:49:03  2015/01/14
 
  Current Show sessions count: 0
 


 [10.86.32.2]acl 3333
 [10.86.32.2-acl-adv-3333]rule permit ip source 10.77.0.8 0 destinatoin 10.86.3.1 11  0

 [10.86.32.2-acl-adv-3333]q

 [10.86.32.2]diagn


 
 
 [10.86.32.2-diagnose]display firewall statistic acl
 09:49:57  2015/01/14
 
  Current Show sessions count: 1
    
  Protocol(ICMP) SourceIp(10.77.0.8) DestinationIp(10.86.3.111)   
  SourcePort(10) DestinationPort(2048) VpnIndex(public)   
            Receive           Forward           Discard   
  Obverse : 4          pkt(s) 0          pkt(s) 0          pkt(s)   
  Reverse : 0          pkt(s) 0          pkt(s) 0          pkt(s)

    
  Discard detail information:

 

 根据流统的结果看,分部USG2110F只有接收了4个源地址10.77.0.8的ICMP报文,但是不转发。说明丢包是发生在USG2110F的设备上。

 

3.采集设备上的debug IPsec error的信息

 

debugging  ipsec error

 

 

0.92981110 10.86.32.2 DEBUG/7/PktInfo:

 IPSEC_CheckAclByGroup: failed hash:1609  data:

 725ff2c5 36c02f0d e5750050 0000ff06 00000000

*0.92981110 10.86.32.2 DEBUG/7/PktInfo:

 IPSEC_CheckAclByGroup: failed hash:595  data:

 725ff2c5 0a560805 e57901bd 0000ff06 00000000

*0.92981530 10.86.32.2 DEBUG/7/PktInfo:

 IPSEC_CheckAclByGroup: failed hash:752  data:

 725ff2c5 b4613fed e57c0050 0000ff06 00000000

*0.92981630 10.86.32.2 DEBUG/7/PktInfo:

 IPSEC_CheckAclByGroup: failed hash:2295  data:

 725ff2c5 65e60f6d 00000000 0000ff01 00000000

*0.92981630 10.86.32.2 DEBUG/7/PktInfo:

 IPSEC_CheckAclByGroup: failed hash:752  data:

 725ff2c5 b4613fed e5terminal debugging

*0.92982100 10.86.32.2 DEBUG/7/PktInfo:

 IPSEC_CheckAclByGroup: failed hash:595  data:

0.93128890 10.86.32.2 PPP/7/debug2:

 

显示的是加密报文hash失败

 

 

4.再重新查分部USG2110F看设备上的会话信息

<10.86.32.2>display firewall session table verbose source global 101.230.16.72

Current Total Sessions : 1

  esp  VPN:public --> public

  Zone: untrust--> trust  TTL: 00:10:00  Left: 00:09:59

  Interface: Vlanif1  NextHop: 10.86.32.39  MAC: 00-40-48-aa-78-e0

  <--packets:0 bytes:0   -->packets:152270 bytes:17468472

  101.230.15.109:0-->114.95.232.160:0[10.86.32.39:0] -------显示的是ESP的报文命中了NAT server

 

删除此会话后问题解决

<USG_SHA>ping -a 10.86.3.1 -s 8000 10.77.8.1

  PING 10.77.8.1: 8000  data bytes, press CTRL_C to break

    Reply from 10.77.8.1: bytes=8000 Sequence=1 ttl=255 time=20 ms

    Reply from 10.77.8.1: bytes=8000 Sequence=2 ttl=255 time=20 ms

根因

问题的根因是ESP报文命中了USG2110F的NAT server,但是查看分部USG2110F的设备是只有一条NAT server,理论上是不会产生ESP报文被转换的。

nat server 0 global interface Dialer0 inside 10.86.32.39 no-reverse

怀疑可能是客户当前的NAT server修改过,经向客户求证,客户之前做的是NAT server的全映射

nat server global interface Dialer0 inside 10.86.32.39

所以问题的根因就在这里,分部做全映射,所有到分部的设备的报文都会被NAT server转换掉,虽然后来有修改NAT server的配置,但是会话没有老化,一直有命中ESP这条会话,导致终端无法ping通。

解决方案
清除设备上异常的会话信息,问题解决。
建议与总结

在IPsec VPN 的故障排查过程中,需要注意一些常规的思路以及对原理熟练的掌握:

1.首先就是确定组网信息和IPsec VPN配置,通过查看dis ike sa 和dis ipsec sa来分析,第一阶段建立不成功,需要排查第一阶段的ike提议和ike peer参数的配置;第二阶段建立不起来,需要排查IPsec提议,以及IPsec协商的参数配置。

2.在防火墙上借助会话信息来排查故障,有助于分析问题的原因出现在哪里,缩小问题定位的范围。

3.掌握IPsec协商时的关键的信息和原理,例如:

IPSec协商时的端口:
IKE: 500,4500
IPSEC: AH,ESP

报文的封装与解封装的过程以及与NAT转换的关系。

END