组网及说明

组网简化如下：

内网a---FWA ------------公网------------FWB---内网b

告警信息

不涉及

问题描述

FWA和FWB之间建立IPsec隧道，使用过程中经常出现内网a网段无法通过IPsec隧道正常访问内网b网段情况。

此时通过重置隧道可以暂时解决问题。

过程分析

写在前面：对于此类不定时通过IPsec隧道访问不通的情况，首先需要明确的就是故障时IPsec隧道是否存在。

如果隧道不存在的话，则需要通过debug ike等信息去定位隧道异常中断的问题；

如果隧道存在（disp ipsec sa显示感兴趣流有对应的隧道存在），但是访问不通。这类问题思路要相对简单，只需要判断设备封装是否正常。

现场的情况属于第二种，因此我们要做的就是在故障时候在隧道两端（FWA和FWB）抓取IPsec封装前后的流量，来判断设备封装收发报文是否正常。

在抓包之前可以先简单看下内层会话报文的情况（开启会话统计功能:session statistics enable）,看下隧道两端的收发情况。

抓包的目的是为了判断防火墙收发报文是否正常，作为定性的手段。如果确实是防火墙问题，那么此时通过debug的手段可以判断问题原因。

抓包和debug针对的acl略有区别，抓包需要把封装前后的地址都囊括，debug的acl只需要包括感兴趣流地址即可。详细介绍可以参考链接：https://zhiliao.h3c.com/theme/details/215520

基于以上的操作指导，访问由内网a向内网b发起的情况下，通过查看会话发现FWA侧内层感兴趣流会话有发无收，FWB侧收发正常。

那么问题的关键点就是判断FWB（IP地址27.X.X.X）有没有将IPsec封装后的报文发送出来，此时查看抓包如下：

Ping测试的时候ping固定500字节大小的报文以此方便定位定位ICMP报文封装后的ESP报文，标红处可以看到IPsec封装正常（No.1946报文）。

该情况也和FWB查看内层会话收发正常的情况比较相符，问题似乎可能是FWA没有收到ESP报文，或者是收到了ESP报文但是没有正常走IPsec流程解封装处理。

按照前面的操作步骤，在FWA上抓包，没有抓到对应字节的ESP报文。判断问题可能不是出在墙上，但是根据现场的反馈每次出问题重置隧道可以解决问题，那么根源可能还是在IPsec的配置上，和网络的连通性问题不大。

那么为什么FWB发出的ESP报文，FWA没有收到呢？根据常规的思路可能就是流统确定丢包位置，但是两台FW处于网关位置，流统不是很现实。

根据经验查看FWB上抓取的报文，关注No.1943报文，根据源mac判断是从下发IPsec策略的接口收到的。

关注No.1946报文,根据目的mac是设备的其他接口发出去的。

那么分析到这里问题基本已经可以定位了，FWB发送ESP报文的时候走错了出接口导致FWA侧没有收到。

解决方法

后续经过分析，发现FWB下发IPsec的接口下配置了保持上一跳，协商如果是对端发起，那么会话表项存在的情况下FWB可以找到正确的出接口，但是当会话老化之后，FWB侧IPsec封装后会走默认路由的出口出去，导致FWA收不到esp报文。隧道重置后，协商的会话又存在了，业务就恢复正常了。解决方案就是在FWB侧配置本地策略路由。

因此，针对存在多出口的情况下，需要在设备上配置本地策略路由规避问题。

示例：

（1）配置需要走策略路由的流量

[FW]acladvanced3400
[FW-acl-ipv4-adv-3400]rule0permitudpsource27X.X.X 0destination-porteq500 ---该rule对应IKE协商，如果涉及NAT穿越需要加上udp 4500端口
[FW-acl-ipv4-adv-3400]rule5permit50source 27X.X.X0 ---ESP报文协议号50，如果AH则对应51
（2）配置本地策略路由
[FW]policy-based-routetestpermitnode1
[FW-pbr-test-1]if-matchacl3400
[FW-pbr-test-1]applynext-hop Y.Y.Y.Y
[FW-pbr-test-1]quit
（3）全局下引用本地策略路由
[FW-pbr-test-1]iplocalpolicy-based-routetest