Cloud Native应用交付
  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
☁️We are in new App Mesh era: imesh.club ☁️
  1. 首页
  2. CISCO资源
  3. 正文

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

2007年11月02日 12637点热度 0人点赞 5条评论

最近公司需要和新加坡一家公司互联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方式的。

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

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

本作品采用 知识共享署名 4.0 国际许可协议 进行许可
标签: IPSec NAT-T checkpoint PIX l2l
最后更新:2007年11月02日

纳米

http://linjing.io

打赏 点赞
< 上一篇
下一篇 >

文章评论

  • monoxide

    精华,啥都不说了

    2007年11月02日
    回复
  • wanydoors

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

    2007年11月08日
    回复
  • gg

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

    2008年01月26日
    回复
  • 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地址

    2009年05月22日
    回复
  • melody

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

    2010年09月03日
    回复
  • 取消回复

    纳米

    http://linjing.io

    ☁️迈向Cloud Native ADC ☁️

    认证获得:
    Kubernetes: CKA #664
    Microsoft: MCSE MCDBA
    Cisco: CCNP
    Juniper: JNCIS
    F5:
    F5 Certified Solution Expert, Security
    F5 Certified Technology Specialist, LTM/GTM/APM/ASM
    F5 Certified BIG-IP Administrator
  • 点击查看本博技术要素列表
  • 分类目录
    • Avi Networks (3)
    • Cisco ACI (1)
    • CISCO资源 (21)
    • F5 with ELK (8)
    • F5-Tech tips (38)
    • F5技术 (203)
    • Juniper (4)
    • Linux (7)
    • Nginx (18)
    • SDN (4)
    • ServiceMesh (19)
    • WEB编程 (8)
    • WINDOWS相关 (7)
    • 业界文章 (18)
    • 交换机技术 (20)
    • 化云为雨/Openstack (35)
    • 协议原理 (52)
    • 容器/k8s (64)
    • 我的工作 (19)
    • 我的生活 (70)
    • 网站技术 (19)
    • 路由器技术 (80)
    • 项目案例 (28)
    文章归档
    标签聚合
    F5 k8s openstack nginx istio DNS envoy gtm docker network flannel api irule bigip neutron cc kubernetes ELK vxlan BGP dhcp VPN IPSec lbaas ingress ingress controller nginx plus sidecar IPSec VPN NAT sql
    最新 热点 随机
    最新 热点 随机
    Say hello for 2021 二进制flannel部署,非cni网络模式下与k8s CIS结合方案 又是一年国庆 Service Account Token Volume Projection Istio ingressgateway 静态TLS证书加载与SDS发现方式配置区别 Istio里Gateway的port定义与实际ingressgateway的listener端口关系及规则 Helm 3 部署NGINX Ingress Controller 应用交付老兵眼中的Envoy, 云原生时代下的思考 Istio sidecar iptables以及流量控制分析 Istio 熔断策略及envoy配置
    Say hello for 2021
    WA对request的要求&处理顺序&对response的要求 Easy vpn server introduce and referrence windows 7 软件兼容性实践 F5 Consulting service: ASM workshop Docker学习备忘2 Cisco Certified Network Professional have passed Ubuntu配置作为DNS服务器 BIND从9.4.1-P1开始在递归设置的微妙变化 session详解 heat template guide
    链接表
    • Jimmy Song‘s Blog
    • SDNap
    • SDNlab
    • SDN论坛
    • Service Mesh社区
    • 三斗室
    • 个人profile

    COPYRIGHT © 2020 Cloud Native应用交付. ALL RIGHTS RESERVED.

    THEME KRATOS MADE BY VTROIS

    京ICP备14048088号-1

    京公网安备 11010502041506号

    [ Placeholder content for popup link ] WordPress Download Manager - Best Download Management Plugin