说明：
1、 县局内网全部为143.76.14X..0/24网段，网关全部指向143.76.14X..250（防火墙内网接口地址）；
2、 防火墙工作在混合模式下，县局内网—》INTERNET走NAT的路由模式，县局内网—》税务专网走桥接（交换）模式；
3、 防火墙路由表： 143.0.0.0 255.0.0.0 143.76.14X.254
4、 县局核心交换机只启用了2层交换功能；
二、故障现象：
1、 县局内网用户无法访问市局的服务器（我们测试时用市局某FTP服务器143.76.3X..2/24），但却可以访问省局服务器（我们测试时用省局某WEB服务器143.16.X..1/24）；
2、 县局内网用户把网关改为直接指向专网路由器内部接口地址143.76.14X.254，则市局服务器、省局服务器访问都正常；
三、分析和解决过程：
1、 首先为验证用户所说故障现象，我们针对市局、省局的服务器做了测试，确实存在如上所述故障；
2、 登陆防火墙查看配置，确认防火墙访问控制策略、路由等配置无误；
3、 没有明显的配置问题，那么为什么市局的服务器在县局都无法访问呢？
为确认此问题，当市局FTP服务器访问不了时，我们就telnet到防火墙上抓一下这些数据包，看看这些数据包通过防火墙到底是怎么走的。
（1），在防火墙内网口使用命令：tcpdump –i eth2 host 143.76.3X.2；
（2），在防火墙专网出口使用命令：tcpdump –i eth0 host 143.76.3X.2；
备注：由于是使用用户处的机器抓包的，所以没有留下抓包内容
我们发现，县局内网发往市局FTP服务器的SYN请求包发送到了防火墙内网接口ETH2上，但是在防火墙专网出口ETH0上却没有发现这些SYN请求包，而是由防火墙内网接口地址143.76.14X.250发送的关于143.76.3X.2的ARP请求包；
（3）， 正常情况下，防火墙应该根据自己的路由表将这些SYN请求包转发给专网路由器才对，为什么防火墙没有转发该包，而是自己直接发送143.76.3X.2的ARP请求包呢？难道防火墙认为143.76.3X.2跟自己是在同一网段的？
4、为验证上面的推论，我们登上防火墙查看其内网接口地址，发现内网接口分配的地址为：143.76.14X.250/255.255.0.0，靠！16位的掩码！ 难怪防火墙会认为143.76.3X.2是自己直连的网段；
5、接下来的事情就简单了，修改防火墙内网接口地址的掩码为255.255.255.0，保存，测试，一切正常了！
四、结论：
1、怪异现象的背后总是有原因的，当我们尝试着去分析和解决这类怪异问题时，需要有扎实的理论基础，在该例中，就需要对数据包的转发流程以及各种常用通讯协议（ARP）比较熟悉；
2、掌握几种经典工具的使用方法，对我们解决故障将有莫大的帮助（此例中tcpdump的使用）；
3，此例的怪异程度只是一般，遇到怪异程度高的故障，如果我们解决不了，最好能够取得相关设备的厂家的技术支持，因为：首先，不同的网络设备处理数据包的流程是不一样的，有些厂商的设备在数据包的处理上并不符合我们所熟悉的正常的流程（他们很可能不按照套路出牌，呵呵！），例如天融信防火墙NGFW4000的2.6.40 的版本，当防火墙工作在桥接模式下时，就限制ARP数据包穿透防火墙；其次，任何设备都有存在BUG的可能，以前在用户处就遇到过FORTINET防火墙的BUG问题；
BTW:效率！？
坐车来回需要5小时，等用户花了2小时，解决问题花了5分钟，此次解决问题的效率为：
5/[(5+2)*60+5]＝0.011764705882352941176470588235294
