组网及说明
组网简化如下:
内网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