最近公司需要和新加坡一家公司互联VPN ，双方协商使用site-site的方式。但对方是checkpoint防火墙，我方是CISCO的防火墙。拓扑结构如下

checkpoint-------------------isp---------------------------F5--PIX

双方约定按以下参数进行：

从上面可以很简单的看出，其实就是192.168.223.0/27与192.168.100.90/24的VPN通信。

于是，我在我的防火墙上设置ACL  permit ip host 192.168.100.90 192.168.223.0 255.255.255.224.我没有设置到端口，是为了以后方便，因为可能增加其他端口通信，更细致的端口限制我在后面的其他设备上作了。

其他参数则按照双方约定的配置。

当天下午配好之后，我PING新加坡 ，一切OK，没有问题，于是发了封邮件告诉新加坡管理员我OK了。

第2天上午，到公司一开邮箱，一封告知我无法PING通的邮件赫然的显示在电脑上。晕～～没道理啊，通信从来都是双方的，我昨天都能PING通他们的呀～。赶紧检查，查ACL，查防火墙上VPN状态，靠 VPN 并没有建立。仔细检查了配置，没有错误啊，于是debug ike，HO，这个debug结果要是能自动保存到一个文件里就好了，这一点CISCO就不如Juniper了，仔细看了输出的消息，发现CISCO并没有认可静态加密映射中设置的ACL，并有这样一个细节：

转载请注明来自http://www.mycisco.cn

I received “Nov 01 09:50:08 [IKEv1 DECODE]: Group = 210.×××.2, IP = 210.×××.2, ID_IPV4_ADDR_SUBNET ID received--192.168.100.0--255.255.255.0”  on cisco firewall

原来对方设置的ACL（checkpoint叫rules）是:192.168.223.0/27到192.168.10024的，而我的ACL是设置到主机的，这个时候CISCO认为对方提议的与自己设定的ACL不匹配，所以无法建立VPN。后经过测试，只要对方提议的范围比CISCO上设置的小，就可以通过。这也恰恰证明了CISCO曾一再强调的，site-to-siteVPN的ACL要互为镜像。

由于对方的checkpoint防火墙无法设置到主机级别，所以只能我这边将ACL范围改大，修改后，VPN终于建立起来了。

如果说最近点背，我真的是背到家了，。。。。。。。。。尽管VPN可以建立，但却根本无法PING通。查看PIX上IPSEC SA，发现加密、解密计数都为0.靠！！！怎么回事呢？ 翻来覆去查ACL ，PIX状态，没有特殊的啊，查CISCO网站，看官方的pix--checkpoint互联配置，没有不一样的地方啊。查F5，有了一些发现，我发现双方的VPN并没有跑在UDP 4500端口上，但由于当时怪事多多，他那边有时甚至PING 我这边 internet口 我都无法在F5上看到，我并没有很在意这个问题，快到下班时间了，新加坡的人也要下班，于是决定先搁置。

 回家，背，所以就会背到家，平常等107路，40多分钟都等不到一辆，这次和同事步行，准备到北边坐40路回家。路上2辆107从身边走过。。。。。。到了地点，平常间隔不大的40今天却奇慢，又是两辆107过去，40还没来。靠！！！！！！！！

到家了，媳妇在包饺子，终于让不爽的心稍稍平静了下。

上网、查资料、群里问，都没结果。头晕，不想了。看juniper吧，学习去。。

早上，又到公司，上防护墙，呵呵 ，新加坡的太阳比中国早？对方已经在测试了，因为我看了IPSEC SA，这次有意外发现，我注意到IPSEC SA中的的一个地方：

inbound esp sas:
      spi: 0x7E5D6098 (2120048792)
         transform: esp-3des esp-sha-hmac none
         in use settings ={L2L, Tunnel, PFS Group 2, }

奇怪，我的TOP中间有一个F5，这个F5是执行了NAT的，而且我的PIX是全局开启了NAT-T的，怎么会没有NAT-T在这个括弧里呢，于是我立即查看到上海的那条VPN：

    inbound esp sas:
      spi: 0xC2D6CB32 (3268856626)
         transform: esp-3des esp-sha-hmac none
         in use settings ={L2L, Tunnel,  NAT-T-Encaps, }

我又联想起昨天在F5上没有看到到新加坡的UDP 4500通信，而正常情况下，NAT-T是跑在UDP 4500上。于是我推断是双方在NAT-T上的协商有了问题。于是debug,发现：

Nov 02 11:55:19 [IKEv1]: IP = 210×××.2, Keep-alive type for this connection: None
Nov 02 11:55:19 [IKEv1]: IP = 210.×××.2, Keep-alives configured on but peer does not support keep-alives (type = None)

显然，设备没有就这个参数达成一致，对方并没有告知PIX它的keep-alive类型。

于是赶紧给新加坡发去邮件，说明我的推测，对方回复邮件说他知道nat-t是工作在client到VPN gateway上的，或许他的认识没有错误，因为他用的是checkpoint 设备，但是在CISCO的设备上这种说法显然不对，因为NAT-T是支持L2L方式的。

这时，对方正好打来了电话，于是在电话中和他进行了沟通，对方表示去查下资料。最后果然有所发现：

原来，他这个型号的checkpoint设备不支持主动发起NAT-T协商，但可以接受带NAT-T的协商。到此，终于明白为什么我可以在任何时候PING通他们，而他们却不能在任何时候PING通我这

边（但如果我这边主动PING过去后，他们就可以PING过来了）。原来是这个原因导致的单向！

怎么解决这个问题呢！

由于只能我这边主动发起协商，通信才能正常，而此时建立的VPN是没有NAT-T的，即是一个普通的IPSEC通信，在这种情况下，PIX是不会发送keepalives消息来保持链路中的NAT的，如果是这样，F5上默认5分钟将断开这个连接，到时将会不通，事实证明确实是这样。要想不断刷新以保证F5上连接的存在，则必须让我这边某台电脑不停的PING新加坡那边，实际测试不停的PING可以保证双方的通信。至此这个VPN只能采用这种不算完美的办法了（期间我问对方的设备是否可以发送keepalive，对方说好似没有。。。）。

后记：要想保持这个通信畅通，我这边的PING是不能停的，万一停了，双方再没有数据交换，那么5分钟后，连接就被F5断开，此时如果新加坡主动发起了新一轮的VPN协商，则完蛋了，双方都将不通。所以针对此问题，我注意到PIX上有一个参数，就是可以让PIX只发起协商而不接受协商，但遗憾的时候没有效果，查CISCO文档发现该参数只适合CISCO设备之间。checkpoint上更没有类似这种功能设置，所以只能保持我这边的长PING，万一出现上面的情况，则只能上去清SA了。

O MY GOD!!!!!!!!!!!!!!!