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

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

USG系列防火墙故障案例集
目录
USG2100攻击防范导致地址映射不成功
接口MTU不匹配导致OSPF邻居卡在 ExStart 状态
MTU参数问题导致无法访问外网网站
解决ADSL拨号上网NAT SERVER 外网IP不固定问题
解决L2TP连接后总部主动和分支通信的问题
ADSL接口不能配置PVC命令问题
V.35 SA卡双串口绑定与LOOP CONVERTER无法连通
UTM模式下,更换部署网络,签名库/病毒库无法更新
采用QoS限制其中一个子网访问外网的速率
USG2100攻击防范导致地址映射不成功
现象描述:用户需要将内部地址8000端口和8999等端口通过地址映射发布到外网,然而在外网访问发布的端口却发现,只有8000端口能够访问进来,其他做了映射的端口均不能访问成功
原因分析:
1:运营商阻止映射端口的通信
2:防火墙包过滤未打开。

3:其它原因。

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

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

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

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

4、打开抓包功能,检查访问时数据包是否到了防火墙,当外网发起访问时能看到有数据包到达防火墙:
[shanxi09]disp firewall packet-capture statistic
QueueID CapturedNumber SentState TCP UDP ICMP Other -----------------------------------------------------------------------------
0 4( 0%) Unsent 100.00% 0.00% 0.00% 0.00%
1 0( 0%) Unused 0.00% 0.00% 0.00% 0.00%
2 0( 0%) Unused 0.00% 0.00% 0.00% 0.00%
3 0( 0%) Unused 0.00% 0.00% 0.00% 0.00%
4 0( 0%) Unused 0.00% 0.00% 0.00% 0.00% 证明访问的报文已经到了防火墙,说明是防火墙将报文丢弃。

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

firewall defend syn-flood zone trust tcp-proxy on
firewall defend syn-flood zone untrust tcp-proxy on
firewall defend syn-flood interface Ethernet1/0/0 tcp-proxy on
firewall defend syn-flood interface Vlanif1 tcp-proxy on
将该攻击防范关闭,外网访问映射端口正常
建议/总结:
如果默认开启了firewall defend syn-flood enable功能,不能再开启tcp代理攻击,否则可能导致访问映射端口失败
接口MTU不匹配导致OSPF邻居卡在ExStart 状态
现象描述:组网拓扑如下
一台USG2205BSR (在上图中Router-ID为20.1.1.2)与另一厂商防火墙之间建立GRE 隧道,并运行OSPF,两设备的Tunnel0口参与OSPF 进程。

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

[USG2205BSR]dis ospf peer brief
08:59:32 2011/11/03
OSPF Process 1 with Router ID 20.1.1.2
Neighbor Statistics
Area ID Down Attempt Init 2-Way ExStart Exchange Loading Full Total
0.0.0.14 0 0 0 0 1 0 0 0 1
Total 0 0 0 0 1 0
0 0
原因分析:OSPF 总共有8种可能的启动过程,但并不是一定会经历这8个过程,具体过程如下:
Down → Attempt → Init → Two-way → Exstart → Exchange → Loading → Full
除了Two-way和Full这两个状态,邻居停留在任何状态,都是不正常。

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

2、使用命令检查两端设备的Tunnel 口参数
[USG2205BSR]dis interface Tunnel 0
09:00:02 2011/11/03
Tunnel0 current state : UP
Line protocol current state : UP
Tunnel0 current firewall zone : untrust
Description : Huawei, USG2200BSR Series, Tunnel0 Interface
The Maximum Transmit Unit is 1500 bytes
而另一端Tunnel 口的MTU 值为6400,修改另一端Tunnel 口的MTU 值为1500。

再看邻居状态正常:
[USG2205BSR]dis os peer brief
09:01:32 2011/11/03
OSPF Process 1 with Router ID 20.1.1.2
Neighbor Statistics
Area ID Down Attempt Init 2-Way ExStart Exchange Loading Full Total
0.0.0.14 0 0 0 0 0 0 0 1 1
Total 0 0 0 0 0 0 0
建议/总结:
实验验证,当MTU 不匹配导致OSPF 邻居卡在ExStart/ExChange 状态时,Router-ID 大的一端为ExStart 状态,Router-ID 小的一端为ExChange 状态。

OSPF 邻居正常状态只有Two-way 和full ,否则不正常,邻居不正常的可能原因如下:
1、接口未参与OSPF进程;
2、Area ID不一致;
3、Stub-bit或NSSA-bit不一致;
4、OSPF验证类型不一致或者密码不一致;
6、Rrouter ID 是否冲突;
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通外网,却无法打开网页。

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

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

故让客户提
供WRX150相关配置信息,如下:
PPPOE advance setting of MTU Setting as 1400 and DNS
218.248.255.212
218.248.255.139
于是,我们怀疑MTU参数有问题,因为我司设备的每个接口的MTU默认参数时1500字节。

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

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

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

处理过程:建议客户更改每一个VLANIF接口的MTU为1400,如下:
#
interface Vlanif1
mtu 1400
ip address 192.168.120.1 255.255.255.0
#
interface Vlanif2
mtu 1400
ip address 192.168.121.1 255.255.255.0
#
interface Vlanif3
mtu 1400
ip address 192.168.122.1 255.255.255.0
#
interface Vlanif4
mtu 1400
ip address 192.168.123.1 255.255.255.0
#
interface Vlanif5
mtu 1400
ip address 192.168.124.1 255.255.255.0
#
interface Vlanif6
mtu 1400
ip address 192.168.125.1 255.255.255.0
#
interface Vlanif7
mtu 1400
ip address 192.168.126.1 255.255.255.0
#
interface Vlanif8
mtu 1400
ip address 192.168.127.1 255.255.255.0
#
通过更改配置,内网PC机可以正常访问外网网站。

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

解决ADSL拨号上网NAT SERVER 外网IP不固定问题
现象描述:客户ADSL拨号后,由于获取IP地址不断变动,NAT SERVER失效
原因分析:V100R003C01SPC700以前的版本不支持接口映射
处理过程:一、需求:V100R003其他版本无法实现使用接口作NAT SERVER 的功能,升级到V100R003C01SPC700即可解决问题
二、升级后的版本为V100R003C01SPC700
三、升级过程
为了客户操作方便这里我们使用WEB界面升级
操作步骤
通过Web方式,从V100R003C01版本升级V100R003C01SPC700版本的具体步骤如下。

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

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

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

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

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

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

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

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

----结束
四、升级后的操作
升级完成后即可执行命令行操作
nat server protocol tcp global interface dialer0 8850 inside 192.168.1.18 8850
建议/总结:虽然升级到V100R005版本也能解决该问题,但同一版本的兼容性更好
解决L2TP连接后总部主动和分支通信的问题
现象描述:某客户利用USG2130BSR做LNS端和分支路由器SRG设备做LAC端建立L2TP 隧道,分支通过拨号和总部建立L2TP隧道后,总部LNS端可以主动和各个分支路由器进行通信。

客户询问实现的方法
客户拓扑如下:
原因分析:一般L2TP应用场景是LAC拨号和LNS建立连接后,可以和LNS内部主机或内部服务器通信。

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

处理过程:关键配置如下:
LNS: 总部
[USG2130BSR]l2tp enable //开启L2TP功能
[USG2130BSR]l2tp domain suffix-separator @ //设置域分割符为@
[USG2130-aaa]local-user test@huawei password simple test //本地域用户
[USG2130-aaa]local-user test@hauwei level 3 //配置用户等级
[USG2130-aaa]local-user test@huawei server ppp //配置允许PPP 协议
[USG2130-aaa] domain huawei //配置域名称
[USG2130-aaa]ip pool 3 192.168.3.100 192.168.3.100 //为域用户分配的地址池
//为域用户分配的地址池,一个分支定义一个域,一个地址池,这样每个分支分配的IP肯定都是固定的了。

再配置一条路由
[USG2130]ip route-static 192.168.3.100 32 Virtual-Template 1
LAC: 分支配置
[SRG]l2tp enable //开启L2TP功能
[SRG]l2tp domain suffix-separator @ //设置域分割符为@
[SRG]aaa
[SRG-aaa]domain hauwei
[SRG-aaa]local-user test@huawei password simple test //建立域账号
[SRG-aaa]local-user test@huawei level 3
[SRG-aaa]local-user test@huawei server ppp
//定义了一个“huawei”域中的用户,终端PC或服务器进行拨号时会进行帐号的认证,通过拨LAC后,可以实现总部和服务端通信。

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

建议/总结
ADSL接口不能配置PVC命令问题
现象描述:用户通过ADSL接口卡和专线对接,地址获取方式为上游提供固定IP,无需用户名密码拨号,在配置接口卡ATM口时,配置PVC的命令不成功,需要配置的命令如下:interface Atm2/0/0
pvc 8/35
map bridge Virtual-Ethernet1
但是输入命令,却不成功,如下:
[USG2130BSR-Atm2/0/0]pvc ?
<0-255>/<32-65535> Enter value of VPI/VCI
[USG2130BSR-Atm2/0/0]pvc 8/35
Error: Set failed
原因分析:1、ADSL接口卡异常。

2、配置命令不正确。

3、设备不支持等
处理过程:1、接口卡不知此pvc 8/35命令,说明是单PVC,可以通过modify pvc修改,
但是输入该命令后,在输入命令map bridge Virtual-Ethernet1时,提示不支持该操作。

[USG2130BSR-atm-pvc-Atm2/0/0-8/35]map bridge Virtual-Ethernet 1
Info:This card does not support this operation.
2、由于接口卡是单PVC,所以ATM接口下不需要配置pvc 8/35,也不需要配置映射到虚接
口,即不需要配置map bridge Virtual-Ethernet1,而是直接在接口下配置上游设备提供的固定IP地址即可
建议/总结:PVC命令只适用于多PVC的ATM接口,不需要绑定VT口
V.35 SA卡双串口绑定与LOOP CONVERTER无法连通
现象描述:我司产品USG2120B SR V100R005版本,做V.35 SA卡双串口绑定后,与对端串口中继器LOOP CONVERTER连接后,link protocol无发起来,物理端口可以起来。

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

原因分析:在Debugging PPP information后,发现我们设备串口可以发包,但不能正常收包,且在接口发现收到的包全是错误的包。

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

处理过程:在两个串口的物理视图下,分别执行“invert receive-clock”命令,将接口置为接收时钟信号,问题解决
建议/总结:我们的SA V.35 串口目前只支持同步时钟频率,这点需要注意;同时,众多友商设备串口类型也较多,在做对接配置时,若能了解对端情况,将更有利于问题解决。

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

原因分析:UTM签名库/特征库是通过主动FTP方式连接到安全服务器进行下载,UTM设备若是通过我司安全产品NA T上网,域间没有开启nat alg enable ftp,会出现如下情形UTM签名库/特征库是通过主动FTP方式连接到安全服务器进行下载,UTM设备若是通过我司安全产品NA T上网,域间没有开启nat alg enable ftp,会出现如下情形:
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设备,数据链路建立失败。

导致可以正常上网却无法更新签名库/病毒库的情况
处理过程:在客户出口处,找到进行NA T的设备,在设备上开启域间NA T ALG
[sysname] display interzone trust untrust
interzone trust untrust
detect ftp
#
建议/总结:打开NAT ALG功能后,签名库/病毒库升级成功
采用QoS限制其中一个子网访问外网的速率
现象描述:
要求限制192.168.1.0进出公网的速率为1M,但是局域网内部访问速率不限制。

对192.168.2.0网络不做限制。

合作方做了QoS策略并应用于E0/0/2,出现访问速率时缓时快,并且内部访问慢,并不能满足客户的要求
原因分析:
1、ACL存在问题;
2、速率值不正确;
3、应用的端口不正确。

处理过程:
1、修改ACL为
acl number 3201
rule 5 permit ip source 192.168.1.0 0.0.0.255
acl number 3300
rule 5 permit ip destination 192.168.1.0 0.0.0.255
2、修改QoS策略为
traffic classifier limit_source_1 operator and
if-match acl 3201
traffic classifier limit_destination_1 operator and
if-match acl 3300
#
traffic behavior limit_source_1
car cir 1024000 cbs 1024000 ebs 0 green pass red discard
traffic behavior limit_destination_1
car cir 1024000 cbs 1024000 ebs 0 green pass red discard
qos policy limit_source_1
classifier limit_source_1 behavior limit_source_1
qos policy limit_destination_1
classifier limit_destination_1 behavior limit_destination_1
3、修改应用端口为公网出口E0/0/3
interface Ethernet0/0/4
ip address 1.1.1.1 255.255.255.252 #此IP为虚构的#
qos apply policy limit_source_1 outbound
qos apply policy limit_destination_1 inbound
建议/总结:注意根据环境,灵活应用端口,正确配置ACL是关键的一环
问题与原命令行
SSL VPN完成如下配置后,https://x.x.x.x,点击“继续浏览此网站(不推荐)”后显示无法找到网页
#
v-gateway sslvpn x.x.x.x public
v-gateway sslvpn ip address x.x.x.x
#****BEGIN***sslvpn**1****#
v-gateway sslvpn
basic
dns-server x.x.x.x x.x.x.x
ssl version allversion
ssl timeout 5
ssl lifecycle 1440
ssl ciphersuit custom aes256-sha des-cbc3-sha rc4-sha rc4-md5 aes128-sha des-cbc-sha
logo &logo&.gif
welcome &welcome&.txt
title &title&.txt
service
network-extension enable
network-extension netpool 172.16.253.100 172.16.253.254 255.255.255.0
network-extension mode full
security
policy-default-action permit user-src-ip
policy-default-action permit user-dst-ip
policy-default-action permit user-url
policy-default-action permit vt-src-ip
password-setting password-intension low 1 high 31 digits 0 letters 0 unmix
password-setting safe-policy 1
password-setting lifetime 0 alarm 0
certification cert-anonymous cert-field user-filter subject cn group-filter subject cn certification cert-anonymous filter-policy permit-all
certification cert-challenge cert-field user-filter subject cn
certification user-cert-filter key-usage any
#****END****#
解决方法:
v-gateway sslvpn x.x.x.x public 修改为v-gateway sslvpn x.x.x.x private . 共享型虚拟网关只能通过域名访问,独占型网关可以通过域名或ip访问
【故障现象描述】
某局点采用E200E双机热备,配置NAT Server后,出现如下告警:
%2013-03-07 12:47:14 Firewall1 %%01ARP/4/DUP_IPADDR(l): Receive an ARP packet with duplicate ip address x.x.145.140 from GigabitEthernet0/0/0, source MAC is 0022-a10e-0682!
【组网描述】
如附件中所示,E200E做双机热备,VRRP虚拟网关地址是x.x.145.248,两台E200E上均配置NA T Server,
golbal地址为x.x.145.140,该global地址与虚拟网关地址在同一网段。

【配置描述】
查看当前配置,两台防火墙的NA T Server配置一致:
[Eudemon200E-1]nat server 0 protocol tcp global x.x.145.140 www inside 172.16.10.203 www
[Eudemon200E-1]interface GigabitEthernet0/0/0
ip address x.x.145.240 255.255.255.0
vrrp vrid 5 virtual-ip x.x.145.248 master
[Eudemon200E-2]nat server 0 protocol tcp global x.x.145.140 www inside 172.16.10.203 www
[Eudemon200E-2]interface GigabitEthernet0/0/0
ip address x.x.145.241 255.255.255.0
vrrp vrid 5 virtual-ip x.x.145.248 slave
【定位分析】
当internet用户向x.x.145.140发起ARP请求时,由于是NA T Server的global地址,没有特殊配置的话主备
防火墙都会响应ARP Reply,interne用户以最后收到的应答为主,这就是防火墙上出现告警信息的根因。

【解决方案】
防火墙采用双机热备组网,如果NA T Server的global地址与VRRP虚拟网关地址在同一网段,需要将NA T
Server与VRRP绑定。

修改为如下配置后,问题解决。

[Eudemon200E-1]nat server 0 protocol tcp global x.x.145.140 www inside 172.16.10.203 www VRRP 5
[Eudemon200E-2]nat server 0 protocol tcp global x.x.145.140 www inside 172.16.10.203 www VRRP 5。

相关文档
最新文档