USG系列防火墙故障案例集讲解.docx

上传人:b****6 文档编号:5383475 上传时间:2022-12-15 格式:DOCX 页数:14 大小:71.89KB
下载 相关 举报
USG系列防火墙故障案例集讲解.docx_第1页
第1页 / 共14页
USG系列防火墙故障案例集讲解.docx_第2页
第2页 / 共14页
USG系列防火墙故障案例集讲解.docx_第3页
第3页 / 共14页
USG系列防火墙故障案例集讲解.docx_第4页
第4页 / 共14页
USG系列防火墙故障案例集讲解.docx_第5页
第5页 / 共14页
点击查看更多>>
下载资源
资源描述

USG系列防火墙故障案例集讲解.docx

《USG系列防火墙故障案例集讲解.docx》由会员分享,可在线阅读,更多相关《USG系列防火墙故障案例集讲解.docx(14页珍藏版)》请在冰豆网上搜索。

USG系列防火墙故障案例集讲解.docx

USG系列防火墙故障案例集讲解

USG系列防火墙故障案例集

USG2100攻击防范导致地址映射不成功

接口MTU不匹配导致OSPF邻居卡在ExStart状态

MTU参数问题导致无法访问外网网站

解决ADSL拨号上网NATSERVER外网IP不固定问题

解决L2TP连接后总部主动和分支通信的问题

ADSL接口不能配置PVC命令问题

V.35SA卡双串口绑定与LOOPCONVERTER无法连通

UTM模式下,更换部署网络,签名库/病毒库无法更新

采用QoS限制其中一个子网访问外网的速率

USG2100攻击防范导致地址映射不成功

现象描述:

用户需要将内部地址8000端口和8999等端口通过地址映射发布到外网,然而在外网访问发布的端口却发现,只有8000端口能够访问进来,其他做了映射的端口均不能访问成功

原因分析:

1:

运营商阻止映射端口的通信

2:

防火墙包过滤未打开。

3:

其它原因。

处理过程:

1、将不能访问的端口修改成防火墙web登录的端口,可以访问。

说明运营商未封闭该端口。

2、查看防火墙上的包过滤策略,没有做端口过滤限制。

3、查看会话,发现除了8000端口外,访问任何映射的端口均无任何会话信息。

4、打开抓包功能,检查访问时数据包是否到了防火墙,当外网发起访问时能看到有数据包到达防火墙:

[shanxi09]dispfirewallpacket-capturestatistic

QueueIDCapturedNumberSentStateTCPUDPICMPOther

-----------------------------------------------------------------------------

04(0%)Unsent100.00%0.00%0.00%0.00%

10(0%)Unused0.00%0.00%0.00%0.00%

20(0%)Unused0.00%0.00%0.00%0.00%

30(0%)Unused0.00%0.00%0.00%0.00%

40(0%)Unused0.00%0.00%0.00%0.00%

证明访问的报文已经到了防火墙,说明是防火墙将报文丢弃。

5、检查用户攻击防范,除了开启默认攻击防范外,还开启了tcp代理攻击。

firewalldefendsyn-floodzonetrusttcp-proxyon

firewalldefendsyn-floodzoneuntrusttcp-proxyon

firewalldefendsyn-floodinterfaceEthernet1/0/0tcp-proxyon

firewalldefendsyn-floodinterfaceVlanif1tcp-proxyon

将该攻击防范关闭,外网访问映射端口正常

建议/总结:

如果默认开启了firewalldefendsyn-floodenable功能,不能再开启tcp代理攻击,否则可能导致访问映射端口失败

接口MTU不匹配导致OSPF邻居卡在ExStart状态

现象描述:

组网拓扑如下

一台USG2205BSR(在上图中Router-ID为20.1.1.2)与另一厂商防火墙之间建立GRE隧道,并运行OSPF,两设备的Tunnel0口参与OSPF进程。

现在的问题是,两台设备的OSPF邻居状态不正常,卡在ExStart状态。

[USG2205BSR]disospfpeerbrief

08:

59:

322011/11/03

OSPFProcess1withRouterID20.1.1.2

NeighborStatistics

AreaIDDownAttemptInit2-WayExStartExchangeLoadingFullTotal

0.0.0.14000010001

Total000010

00

原因分析:

OSPF总共有8种可能的启动过程,但并不是一定会经历这8个过程,具体过程如下:

Down→Attempt→Init→Two-way→Exstart→Exchange→Loading→Full

除了Two-way和Full这两个状态,邻居停留在任何状态,都是不正常。

处理过程:

1、检查两台安全网关的OSPF配置,物理接口和Tunnel接口配置,没有问题,测试物理口联通性和Tunnel的连通性,都正常。

2、使用命令检查两端设备的Tunnel口参数

[USG2205BSR]disinterfaceTunnel0

09:

00:

022011/11/03

Tunnel0currentstate:

UP

Lineprotocolcurrentstate:

UP

Tunnel0currentfirewallzone:

untrust

Description:

Huawei,USG2200BSRSeries,Tunnel0Interface

TheMaximumTransmitUnitis1500bytes

而另一端Tunnel口的MTU值为6400,修改另一端Tunnel口的MTU值为1500。

再看邻居状态正常:

[USG2205BSR]disospeerbrief

09:

01:

322011/11/03

OSPFProcess1withRouterID20.1.1.2

NeighborStatistics

AreaIDDownAttemptInit2-WayExStartExchangeLoadingFullTotal

0.0.0.14000000011

Total0000000

建议/总结:

实验验证,当MTU不匹配导致OSPF邻居卡在ExStart/ExChange状态时,Router-ID大的一端为ExStart状态,Router-ID小的一端为ExChange状态。

OSPF邻居正常状态只有Two-way和full,否则不正常,邻居不正常的可能原因如下:

1、接口未参与OSPF进程;

2、AreaID不一致;

3、Stub-bit或NSSA-bit不一致;

4、OSPF验证类型不一致或者密码不一致;

6、RrouterID是否冲突;

7、OSPF链路两端的MTU相差比较大,通常停留在ExStart状态(需要在其接口下配置OSPF忽略MTU检查或修改MTU);

8、是否在同一网段(PPP链路除外);

9、是否有策略过滤掉OSPF报文

MTU参数问题导致无法访问外网网站

现象描述:

客户使用我司产品USG2120,通过ADSL接口与BSNL(印度宽带运营商)的10MBPS网络相连,在配置Dialer、NAT、VLANIF、DNS等信息后,在内网PC机可以ping通,却无法打开网站页面。

原因分析:

通过分析客户的提供的配置脚本文件,配置基本都正确,Dialer、NAT、VLANIF、DNS及路由信息都没问题,且通过验证,内网PC机可以ping通外网,却无法打开网页。

将我司设备换成友商WirelessN-Router,ModelNoWRX150的路由器后,客户内网PC机可以访问外部网站。

遇到这种情况,一般情况下需要check两端link的参数配置。

故让客户提供WRX150相关配置信息,如下:

PPPOEadvancesettingofMTUSettingas1400andDNS

218.248.255.212

218.248.255.139

于是,我们怀疑MTU参数有问题,因为我司设备的每个接口的MTU默认参数时1500字节。

由于两端(USG212O与BSNL设备)的MTU参数不一致,导致双方link协商不能完成正常连接。

再者,ADSL使用的PPPoE略小于这个数值,一般为1492。

而此客户需要使用的MTU很可能是1400字节。

处理过程:

建议客户更改每一个VLANIF接口的MTU为1400,如下:

#

interfaceVlanif1

mtu1400

ipaddress192.168.120.1255.255.255.0

#

interfaceVlanif2

mtu1400

ipaddress192.168.121.1255.255.255.0

#

interfaceVlanif3

mtu1400

ipaddress192.168.122.1255.255.255.0

#

interfaceVlanif4

mtu1400

ipaddress192.168.123.1255.255.255.0

#

interfaceVlanif5

mtu1400

ipaddress192.168.124.1255.255.255.0

#

interfaceVlanif6

mtu1400

ipaddress192.168.125.1255.255.255.0

#

interfaceVlanif7

mtu1400

ipaddress192.168.126.1255.255.255.0

#

interfaceVlanif8

mtu1400

ipaddress192.168.127.1255.255.255.0

#

通过更改配置,内网PC机可以正常访问外网网站。

建议/总结:

涉及到此类问题,优先check设备是否配置DNS等信息,然后check链路对接等配置信息;此外,用其它设备替换进行验证测试,也是个很好的选择,有利于问题的快速甄别。

解决ADSL拨号上网NATSERVER外网IP不固定问题

现象描述:

客户ADSL拨号后,由于获取IP地址不断变动,NATSERVER失效

原因分析:

V100R003C01SPC700以前的版本不支持接口映射

处理过程:

一、需求:

V100R003其他版本无法实现使用接口作NATSERVER的功能,升级到V100R003C01SPC700即可解决问题

二、升级后的版本为V100R003C01SPC700

三、升级过程

为了客户操作方便这里我们使用WEB界面升级

操作步骤

通过Web方式,从V100R003C01版本升级V100R003C01SPC700版本的具体步骤如下。

步骤1在作为Browser的PC2上使用IE浏览器登录到USG2100BSR/HSR,用户名为admin,密码为Admin@123。

步骤2选择“系统管理>启动信息”,在“上传系统软件”中选择“上传并替换当前的系统启动文件”。

步骤3单击“浏览”按钮,选择要上传的系统软件。

步骤4单击“上传”按钮上传系统软件。

在升级过程中,设备不能断电。

升级过程中,请不要切换、刷新页面或关闭IE浏览器,以便及时得到升级结果。

步骤5当出现“执行成功”提示框后,升级过程结束。

步骤6重新启动设备,自动运行新加载的主机软件。

----结束

四、升级后的操作

升级完成后即可执行命令行操作

natserverprotocoltcpglobalinterfacedialer08850inside192.168.1.188850

建议/总结:

虽然升级到V100R005版本也能解决该问题,但同一版本的兼容性更好

解决L2TP连接后总部主动和分支通信的问题

现象描述:

某客户利用USG2130BSR做LNS端和分支路由器SRG设备做LAC端建立L2TP隧道,分支通过拨号和总部建立L2TP隧道后,总部LNS端可以主动和各个分支路由器进行通信。

客户询问实现的方法

客户拓扑如下:

原因分析:

一般L2TP应用场景是LAC拨号和LNS建立连接后,可以和LNS内部主机或内部服务器通信。

该客户提出的应用场景,可以通过建立域账号方式和配置静态路由来实现,即每个分支路由器拨号分配固定IP地址,再在LNS端指一条明细路由到各个分支,可以实现总部和各个分支之间的通信问题,即可以在路由上,或是路由器下PC可以和LNS总部之间建立连接并通信。

处理过程:

关键配置如下:

LNS:

总部

[USG2130BSR]l2tpenable//开启L2TP功能

[USG2130BSR]l2tpdomainsuffix-separator@//设置域分割符为@

[USG2130-aaa]local-usertest@huaweipasswordsimpletest//本地域用户

[USG2130-aaa]local-usertest@hauweilevel3//配置用户等级

[USG2130-aaa]local-usertest@huaweiserverppp//配置允许PPP协议

[USG2130-aaa]domainhuawei//配置域名称

[USG2130-aaa]ippool3192.168.3.100192.168.3.100//为域用户分配的地址池

//为域用户分配的地址池,一个分支定义一个域,一个地址池,这样每个分支分配的IP肯定都是固定的了。

再配置一条路由

[USG2130]iproute-static192.168.3.10032Virtual-Template1

LAC:

分支配置

[SRG]l2tpenable//开启L2TP功能

[SRG]l2tpdomainsuffix-separator@//设置域分割符为@

[SRG]aaa

[SRG-aaa]domainhauwei

[SRG-aaa]local-usertest@huaweipasswordsimpletest//建立域账号

[SRG-aaa]local-usertest@huaweilevel3

[SRG-aaa]local-usertest@huaweiserverppp

//定义了一个“huawei”域中的用户,终端PC或服务器进行拨号时会进行帐号的认证,通过拨LAC后,可以实现总部和服务端通信。

再配置一条默认路由上网即可。

建议/总结

ADSL接口不能配置PVC命令问题

现象描述:

用户通过ADSL接口卡和专线对接,地址获取方式为上游提供固定IP,无需用户名密码拨号,在配置接口卡ATM口时,配置PVC的命令不成功,需要配置的命令如下:

interfaceAtm2/0/0

pvc8/35

mapbridgeVirtual-Ethernet1

但是输入命令,却不成功,如下:

[USG2130BSR-Atm2/0/0]pvc?

<0-255>/<32-65535>EntervalueofVPI/VCI

[USG2130BSR-Atm2/0/0]pvc8/35

Error:

Setfailed

原因分析:

1、ADSL接口卡异常。

2、配置命令不正确。

3、设备不支持等

处理过程:

1、接口卡不知此pvc8/35命令,说明是单PVC,可以通过modifypvc修改,但是输入该命令后,在输入命令mapbridgeVirtual-Ethernet1时,提示不支持该操作。

[USG2130BSR-atm-pvc-Atm2/0/0-8/35]mapbridgeVirtual-Ethernet1

Info:

Thiscarddoesnotsupportthisoperation.

2、由于接口卡是单PVC,所以ATM接口下不需要配置pvc8/35,也不需要配置映射到虚接口,即不需要配置mapbridgeVirtual-Ethernet1,而是直接在接口下配置上游设备提供的固定IP地址即可

建议/总结:

PVC命令只适用于多PVC的ATM接口,不需要绑定VT口

V.35SA卡双串口绑定与LOOPCONVERTER无法连通

现象描述:

我司产品USG2120BSRV100R005版本,做V.35SA卡双串口绑定后,与对端串口中继器LOOPCONVERTER连接后,linkprotocol无发起来,物理端口可以起来。

把我司设备更换为友商设备后,link可以起来。

原因分析:

在DebuggingPPPinformation后,发现我们设备串口可以发包,但不能正常收包,且在接口发现收到的包全是错误的包。

表明,串口在收包时无法区别是否为正确信息,通常情况下,是由于两端的时钟频率配置不一致所致。

处理过程:

在两个串口的物理视图下,分别执行“invertreceive-clock”命令,将接口置为接收时钟信号,问题解决

建议/总结:

我们的SAV.35串口目前只支持同步时钟频率,这点需要注意;同时,众多友商设备串口类型也较多,在做对接配置时,若能了解对端情况,将更有利于问题解决。

UTM模式下,更换部署网络,签名库/病毒库无法更新

现象描述:

UTM模式下,在局点A中,签名库/病毒库在线更新成功;删除flash下的规则目录,将设备带到局点B进行演示,签名库/病毒库无法在线更新。

原因分析:

UTM签名库/特征库是通过主动FTP方式连接到安全服务器进行下载,UTM设备若是通过我司安全产品NAT上网,域间没有开启natalgenableftp,会出现如下情形

UTM签名库/特征库是通过主动FTP方式连接到安全服务器进行下载,UTM设备若是通过我司安全产品NAT上网,域间没有开启natalgenableftp,会出现如下情形:

1、UTM设备使用端口N(N>1024)连接到服务器21端口;

2、UTM设备开始监听端口N+1;

3、服务器21端口对端口N进行应答;

4、UTM设备使用端口N发送端口N+1到服务器;

5、服务器21端口对端口N+1进行数据链路初始化;

6、由于UTM设备在我司安全设备之后,并且只做了端口监听的动作,我司安全设备中未建立端口N+1的NAT表项,该报文未能到达UTM设备,数据链路建立失败。

导致可以正常上网却无法更新签名库/病毒库的情况

处理过程:

在客户出口处,找到进行NAT的设备,在设备上开启域间NATALG

[sysname]displayinterzonetrustuntrust

interzonetrustuntrust

detectftp

#

建议/总结:

打开NATALG功能后,签名库/病毒库升级成功

采用QoS限制其中一个子网访问外网的速率

现象描述:

要求限制192.168.1.0进出公网的速率为1M,但是局域网内部访问速率不限制。

对192.168.2.0网络不做限制。

合作方做了QoS策略并应用于E0/0/2,出现访问速率时缓时快,并且内部访问慢,并不能满足客户的要求

原因分析:

1、ACL存在问题;

2、速率值不正确;

3、应用的端口不正确。

处理过程:

1、修改ACL为

aclnumber3201

rule5permitipsource192.168.1.00.0.0.255

aclnumber3300

rule5permitipdestination192.168.1.00.0.0.255

2、修改QoS策略为

trafficclassifierlimit_source_1operatorand

if-matchacl3201

trafficclassifierlimit_destination_1operatorand

if-matchacl3300

#

trafficbehaviorlimit_source_1

carcir1024000cbs1024000ebs0greenpassreddiscard

trafficbehaviorlimit_destination_1

carcir1024000cbs1024000ebs0greenpassreddiscard

qospolicylimit_source_1

classifierlimit_source_1behaviorlimit_source_1

qospolicylimit_destination_1

classifierlimit_destination_1behaviorlimit_destination_1

3、修改应用端口为公网出口E0/0/3

interfaceEthernet0/0/4

ipaddress1.1.1.1255.255.255.252#此IP为虚构的#

qosapplypolicylimit_source_1outbound

qosapplypolicylimit_destination_1inbound

建议/总结:

注意根据环境,灵活应用端口,正确配置ACL是关键的一环

SSLVPN网页访问找不到问题

问题与原命令行

SSLVPN完成如下配置后,https:

//x.x.x.x,点击“继续浏览此网站(不推荐)”后显示无法找到网页

#

v-gatewaysslvpnx.x.x.xpublic

v-gatewaysslvpnipaddressx.x.x.x

#****BEGIN***sslvpn**1****#

v-gatewaysslvpn

basic

dns-serverx.x.x.xx.x.x.x

sslversionallversion

ssltimeout5

ssllifecycle1440

sslciphersuitcustomaes256-shades-cbc3-sharc4-sharc4-md5aes128-shades-cbc-sha

logo&logo&.gif

welcome&welcome&.txt

title&title&.txt

service

network-extensionenable

network-extensionnetpool172.16.253.100172.16.253.254255.255.255.0

network-extensionmodefull

security

policy-default-actionpermituser-src-ip

policy-default-actionpermituser-dst-ip

policy-default-actionpermituser-url

policy-default

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 党团工作 > 党团建设

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1