小锐常常接到客户的反馈是，防火墙部署好了但是业务还是不通，往往束手无策。今天小锐，不藏着掖着了，把收藏多年的佳酿，故障小窍门拿出来让喜欢小锐的大家细品细品。
防火墙的安全检查特性
网络源于生活却又高于生活，作为网络世界大门的鼎鼎大名的“安全检查官“下一代防火墙，有他自己特有的“安全属性”，遵守网络世界的“安全规则”，我们就能更好的在防火墙的故障排查过程中游刃有余。这些“安全属性”倒成了我们在实施防火墙过程中的“绊脚石”，虽然排查故障过程是痛苦的，但解决问题后的快乐是永远铭记值得回味的。
防火墙为了相信数据包是可信的，在收到数据包的时候设置了两个“安全检查点”：
1反向路径检查Reverse Path Forwarding (RPF)
2异步检查（asymroute，也就是大家常说的连接完整性检查）
两项检查只有都符合，才会继续其他模块检查，否则直接丢弃数据包，那针对这两个检查特性我们展开聊聊：
反向路径检查
所谓反向路径检查，简单举例，就是如果从内网口port31收到一个数据包，反向的回包必须从内网口port31回去，也就是要确保源进源出，反之认为此数据包为欺骗包执行丢弃动作。假设，防火墙收到数据包是src_addr_ip->dst_addr_ip为172.16.1.16->219.222.191.72，防火墙不会执行其他模块检查（这些模块会涉及到源目的地址转换、UTM等），而是先执行反向路径检查，根据反向流量219.222.191.72->172.16.1.16，在查找路由表后如果也是从port31出去的，说明流量是正常的，继续处理其他模块检查；如果存在另一个路由通路比如从port32出去或者甚至没有查找到相应路由，这个将导致反向路径检查失败防火墙执行丢弃动作。
使用debug flow抓包命令，会发现有个提示为：reverse path check fail, drop，特别显眼，这个提示就是因反向路径检查失败直接执行了丢弃动作了，这种情况建议是查一下防火墙上的路由配置问题。
异步路由检查
所谓异步路由检查，就是要确保来回路径要一致，保证数据连接的完整性。如：tcp的三次握手的数据包都要过防火墙，正常的tcp三次握手交互过程如下：
如果出现来回路径不一致的情况，防火墙认为报文有问题直接丢弃。
小锐现在就说说这流量转发哪里出现问题了，从流量转发来看PC1访问服务器的流量tcp syn报文转发路径是
PC1->RouterA->NGFW->RouterB->internet->Server，回包syn+ack的转发路径是Internet>RouterB>RouterA->PC1，未经过防火墙，ack报文PC1->RouterA->NGFW(丢弃报文不转发)，防火墙发现会话状态不完整（我没有看到syn+ack,我不信任你），执行丢弃动作。
使用debug flow命令对数据流分析一般会提示为：“org dir, ack in state syn_sent, drop”
当然这里还有更为奇葩的数据转发路径，如果是syn包转发路径不过防火墙，syn+ack的回复报文经过防火墙，这种情况下防火墙是无法找到对应的会话（我没有看到syn，我压根就没有你的会话），直接丢弃，这种也属于异步路由的一种特殊场景。使用debug flow抓包命令，会发现有个提示为：“no session matched”。
还有一种就是来回的二层mac不一致问题也是异步路由检查的一种特例了，一般这种场景常见于防火墙透明模式部署的时候。也就是如果过防火墙的数据包是mac1->mac2[pc1->pc2]，回包的时候是mac3->mac1[pc2->pc1]，这种数据包也是有问题的防火墙不会允许过的。
那可能大家会问小锐，异步路由检查可以关闭吗，实际业务场景不建议关闭的，最好的做法是找到导致来回路径不一致的原因，将异步问题终结掉，因为防火墙关闭异步检查后，多链路出口的场景源进源出功能将不生效，代理防护类utm功能将无法正常工作。
方法是：
set asymroute enable
config system settings
end
此命令是告诉防火墙如果不是syn的报文一样也可以创建会话。
数据包穿越防火墙处理过程详解
正常的数据包穿越防火墙，需要经过哪些过程呢？可以通过debug flow命令查看整个完整过程。
diagnose debug flow show console enable //启用debug flow显示打印，有些版本不需要敲
diagnose debug flow filter addr 192.168.1.110 //过滤条件，避免抓包无用信息过多，这里过滤地址，filter ？可以查看过滤哪些条件
34;vd-root received a packet(proto=6, 192.168.
1.110:51661->119.253.62.131:80) from internal. &34;allocate a new session-00016920&34;find a route: gw-192.168.118.1 via wan1&34;find SNAT: IP-192.168.118.28, port-43333&34;Allowed by Policy-1: SNAT&34;SNAT 192.168.1.110->192.168.118.28:43333&34;vd-root received a packet(proto=6,
119.253.62.131:80->192.168.118.28:43333) from wan1.&34;Find an existing session, id-00016920, reply direction&34;DNAT 192.168.118.28:43333->192.168.1.110:51661&34;find a route: gw-192.168.1.110 via internal&34;vd-root received a
packet(proto=6,192.168.1.110:51661->119.253.62.131:80) frominternal.&34;Find an existing session, id-00016920, original direction&34;enter fast path&34;SNAT 192.168.1.110->192.168.118.28:43333&diagnose debug flow trace stop //停止
diagnose debug reset //重置
34;iprope_in_check() check failed, drop&34;Denied by forward policy check&34;run helper-ftp(dir=original)"
看到这里，小锐相信您也和小锐一样get 了不少防火墙的抓包命令了吧？那么接下来我们继续深入看下进阶版案例分析吧。
进阶案例展示一下命令有多么神奇^-^
现场反馈的拓扑简单描述如下：
全新下一代防火墙做端口映射，部分ISP专网IP访问端口映射的业务不通。基础的配置检查也没有看出问题所在，那接下来使用强大的debug flow对其数据流进行捕获，在信息输出中发现防火墙本地回复了RST报文（也就是图中的...from local. flag [R]），这点甚是可疑，说明问题还是出在防火墙的哪个模块处理环节上。
那我们一起开动脑筋思考一下什么情况下防火墙会主动发送RST包？
从数据包转发上我们注意到tcp syn将通过防火墙，但是当接收到tcp syn / ack时，NGFW会将tcp rst发送回tcp syn / ack的始发者。
即使存在允许流量通过NGFW的策略，配置错误的IPpool或VIP[l7] 也会给TCP连接造成连接问题。（名词解释：这里的ippool一般是用在上网做源地址转换的时候，一个地址不够用，可以把内网的源地址转换成一个地址段范围内的地址，VIP是防火墙的端口映射，也就是大家常说的目的地址转换关系）
一般这种问题的可能性是：本地有相应的IP地址（比如是源地址）了，因为没有对应的服务在监听，会去响应RST报文，按照这种排查思路去检查配置。
那我们把问题点锁定在IPPool或VIP上重点排查，通过配置查看找到了这个始作俑者。将对应错误的策略配置删除问题解决。
经确认现场源地址10.85.40.3也加到了虚拟ip映射里了。对于防火墙配置不太熟悉的往往可能会出现这种奇怪的配置，有时候策略一多真的用肉眼很不好看出问题出在哪儿。
一般出现防火墙回复...from local. flag [R]的情况有如下三种:
1、将服务器地址配置到了IPpool里；
2、将客户端IP地址配置到了IPpool里；
3、将客户端IP地址配置到了VIP里。
总结
Debug flow命令是防火墙实施部署过程中使用频率极高，而且故障诊断问题定位率可达80%左右，真的是算上是爱说大实话的命令了，提示什么原因一般故障就定位出来 了，是小锐力荐需掌握的命令，学会了就是掌握了上乘武功了哦，一起修炼起来吧。
声明：易商讯尊重创作版权。本文信息搜集、整理自互联网，若有来源标记错误或侵犯您的合法权益，请联系我们。我们将及时纠正并删除相关讯息，非常感谢！
