天融信防火墙ping功能如何打开

来源：蜘蛛抓取(WebSpider) 时间：2022-10-07 05:29 标签： 防火墙设置允许ping

关于天融信G420A防火墙双向地址转换一个设置细节

但是在server1上不能通过113.105.88.8访问自己提供的服务，（可能有人认为这是多此一举，其实不然，像有的邮件软件就必须通过互联网地址访问自己）；

之后找了天融信的工程师，告知：若要服务器自己通过映射后的地址访问自己，那么需要做一条双向地址映射。遂将双向映射做上去，加上前面加的源和目的映射这个时候共有三条地址映射。但是问题依旧，找了好久原因，无意间我将目的映射移动到双向映射后面，问题就解决了。

反复试验得出结论：若要服务器自己通过映射后的地址访问自己，需要做一条双向地址映射，同时双向映射策略要在目的映射策略前面.

（如下图：8328必须在8034前面）

某局点使用MSR3660路由器和天融信防火墙建立GRE over IPSec VPN不通，现场反馈IPSec VPN和GRE隧道都是建立起来的，但是数据不通。接下来针对这个问题进行分析。

现场反馈建立IPSec VPN和GRE隧道都是使用的公网地址进行配置的，IPSec VPN保护的感兴趣流也是源目公网地址。具体配置如下（公网地址不是客户真实地址）：

最后需要将IPSec policy策略调用在外网接口。

#创建tunnel接口，并且协议为GRE：

通过上面的配置并没有看出问题，GRE建立和IPSec VPN建立都使用公网地址也是按理来说是可行的。现场也搜集display ike sa以及display ipsec sa信息发现IPSec VPN都是建立成功的。

（1）当我们设备终端主动往对方发包时，执行display ipsec statistics看到我们设备有发送的报文，但是没有收到对方的回复报文：

现场和天融信工程师确认之后，天融信并没有收到我们发过去的报文。于是我们设备开启debugging ip packet acl观察报文的处理过程，发现我们的报文已经发出，并且是发出去的接口是tunnel 7的GRE隧道接口，说明我们设备处理没有问题。

（2）天融信设备往我们路由器发包，执行display ipsec statistics看到我们设备有接收到报文，并且也有回复报文：

但是对方设备抓包还是没有看到我们设备的回包。同样在我们设备debugging ip packet acl进行分析也没有发现问题，我们设备从tunnel 7接口收到报文处理之后也将报文发往tunnel隧道。

通过测试发现我们设备发往天融信的方向出现了问题，怀疑是外网原因导致的。外网原因一般就是网络质量不好或者外网运营商设备不能通过比较大的报文。因此尝试在外网接口修改mtu也没有解决问题。

但是从上面的配置我们可进一步分析，发现终端的报文进入GRE隧道之后今天公网地址封装，然后再次进行IPSec封装。这样的话对于一个建立隧道使用的公网地址进行了两次封装，怀疑是公网地址封装报文层数导致的，因此建议两边的设备配置GRE隧道协商的地址改为私网地址进行协商，然后IPSec再保护这个建立GRE隧道的私网地址。

于是，我们设备的配置修改了以下几点地方进行测试：

a、创建loopback接口，配置为私网地址，用来协商GRE使用的。

#配置感兴趣流为loopback接口地址

最后需要将IPSec policy策略调用在外网接口。

#创建tunnel接口，并且协议为GRE：

通过上面配置之后，现场IPSec VPN和GRE隧道正常协商，通过ping测试之后业务正常。说明一点，在复杂的公网环境中，建议协商GRE隧道的地址使用内网地址协商，IPSec VPN封装保护GRE隧道协商地址即可。避免了复杂的公网环境导致的异常情况。

1、建loopback接口，配置为私网地址，用来协商GRE使用的。

通过上面的配置可以避免复杂的公网环境对报文封装的影响。

我要回帖

更多关于 防火墙设置允许ping 的文章

 

随机推荐