行至水穷处 坐看“云”起时

☁️时代应用交付

终于解决PIX与checkpoint互联VPN的怪问题

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

checkpoint——————-isp—————————F5–PIX

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

FIREWALL PARAMETERS

 

新加坡 Information

 

Firewall Type:

Checkpoint Firewall-1 NG

 Outside IP Address of Fiserv Firewall:

220.42.17.2

Protocols passed thru VPN tunnel (i.e. ftp):

telnet, ftp

Internal IP Addresses of Machines that need access thru VPN tunnel (i.e. orlcbs01)

 

NAT IP Address of Internal Machines

Network ID: 192.168.223.0/255.255.255.224

 

 

中国 Information

 

Customer Firewall Type:

CISCO PIX

Outside IP Address of Customer Firewall:

202.100.14.6

IP/Network Address of Destination(s) (Customer Server):

 

Protocols passed thru VPN tunnel (i.e. ftp):

telnet

IP address of Internal Machines

192.168.100.90/24

 

 

IPSec TRANSFORM PARAMETERS

 

ESP encryption:

3DES

ESP authentication:

SHA-1

IPSec SA lifetime:

1 hr or 60 mins or 3600 secs

 

 

IKE POLICY PARAMETERS

 

IKE encryption:

3DES

IKE hash:

SHA-1

 

 

IKE authentication:

Preshared Key: 2w4rvbr

IKE SA lifetime:

24 hrs or 1440 mins or 86400 secs

Diffe Helman Group:

2

 

 

ADDT’L PARAMETERS

 

Perfect Forward Secrecy?

Yes

Aggressive Mode?

No

Key Exchange for Subnets?

Yes

从上面可以很简单的看出,其实就是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方式的。

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

《终于解决PIX与checkpoint互联VPN的怪问题》

原来,他这个型号的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!!!!!!!!!!!!!!!

点赞
  1. monoxide说道:

    精华,啥都不说了

  2. wanydoors说道:

    绝对经典,
    谢谢分享
    继续关注中。。。

  3. gg说道:

    经典东西,继续关注!!!!

  4. cyberbird说道:

    老大,我正有这样一个疑惑,我们要给用户做个测试方案,客户只有2个公网地址,一个是ISP,一个是防火墙。现在要用F5 LC做链路的LB,F5就站了防火墙原来的公网地址,客户还有VPN如何处理?在F5上作PAT,把UDP500和UDP4500映射到F5的外网口,客户的防火墙是checkpoint,估计也不行吧?

    你这个案例,也使把PIX的UDP500和UDP4500映射到F5的外网口吗?

    纳米 于 2009-5-23 2:01:46 回复

    可以利用F5的接口地址做VS地址

  5. melody说道:

    VPN在在协商过程中就已经有NAT-t封装了...我认为你的问题应该是在F5上,F5没有类似的conn的表项对端cp主动发起的流量就进不来。你的链路有keeplive啊。F5怎么会清空连接呢?