IPsec 隧道UP了，但是业务异常。
1.ESP报文不可达 （202.106.2.1是对方公网IP地址）
如果双方是直接的公网IP，没有NAT的场景下，抓包ESP，看ESP的通信情况：
# diagnose sniffer packet any “proto 50 and host 202.106.2.1” 4
如果双方中间存在NAT的情况下，则数据转发不是用的ESP，而是用的UDP 4500转发的业务数据，但是如果NAT-T的场景下的IPsec VPN可以协商成功，UDP 4500的数据传输就不会有问题，否则IKE协商都是失败的。UDP 4500的抓包命令：
# diagnose sniffer packet any “port 4500 and host 202.106.2.1” 4
2.策略配置错误
3.路由配置错误
4.流量会话已经错误的走向了Internet出口，产生了错误的会话，比如持续的ping，将导致这条会话一直不老化，ping也将持续的不通。特别是无状态的UDP业务持续的发包（比如跨VPN的SIP电话），一旦产生了错误的会话，UDP的老化时间是180S，将会很容易导致即便VPN隧道起来了，UDP的业务也无法恢复。
diagnose sniffer packet any “host 192.168.111.100 and icmp” 4 //查看报文IN和OUT情况
diagnose sys session filter dst 192.168.111.100 // 数据上了NP，抓不到包的时候，清除一下session
diagnose sys session clear
如果数据有IN，没有OUT，可以通过debug flow去确定报文是因为什么被丢弃了：
diagnose debug flow filter addr 192.168.111.100
diagnose debug flow filter proto 1
diagnose debug flow show console enable
diagnose debug flow show function-name enable
diagnose debug flow trace start 10
diagnose debug enable
隧道UP了，但是VPN业务不通？
分析：这种情形，90%以上的原因都是因为路由和策略配置不正确导致，其中路由不正确占据最主要的原因。
1.Center设备策略没有双向放通VPN业务（或者源IP/目的IP/目的接口 与VPN业务流量不匹配）
2.Side设备策略没有双向放通VPN业务（或者源IP/目的IP/目的接口 与VPN业务流量不匹配）
排查思路：Center和Side 双向都应该有匹配业务流量的策略
3.Side设备没有配置去往总部网段的路由指向side-tunnel接口 （sniffer有请求报文的IN，但无OUT）
4.Center设备没有配置回程去往分部网段的路由指向center-tunnel接口 （sniffer有请求报文的IN，无OUT）
5.Center内网核心交换机没有配置去往分部网段的回程路由 （sniffer有请求的IN和OUT，但没有回复的IN）
6.Center内网服务器没有配置去往分部网段的回程路由 （sniffer有请求的IN和OUT，但没有回复的IN）
排查思路：Center和Side 整网都应该有去往对方的路由，包括内网核心交换机和内网服务器
7.通过VPN的SIP电话，时不时中断，无法向服务器成功注册，或者Raidus认证、AP向AC发起的注册请求中断等等。
VPN有时候会因为各种原因重新连接，VPN tunnel此时会出现短暂的DOWN，而去往总部网段的路由也会短暂消失，此时SIP注册请求会因为查询到默认路由而走向了WAN1（internet），从而产生了错误的UDP-NAT-Seesion，此时即便VPN tunnel再次UP，路由再次恢复，SIP流量依旧会走到错误的Session上去，从而引起该业务异常。
排查思路：通过diagnose sniffer pa 以及查看session（diagnose sys session list）去判断问题
解决办法1：配置源接口：LAN，目的接口：WAN1，源IP：内网网段，目的IP：对端内网网段，动作：丢包的策略
将此去往Internet的私网（无用的）流量丢弃掉，避免FGT产生这种错误的session，从而避免了UDP业务时不时中断的问题。
解决办法2：配置对端VPN业务网段的管理距离为254的黑洞路由，一旦VPN隧道DOWN，则将流量转发进黑洞路由，这样就不会产生错误的session，从而避免了UDP业务时不时中断的问题。