USG5530S部署nat-server业务出现用户无法访问故障

发布时间:  2013-03-13 浏览次数:  228 下载次数:  0
问题描述
客户使用USG5530S通过NAT Server发布内网web服务器到Internet,Internet用户无法访问web服务。
业务组网图:
Webserver------USG5530S-----S9303---[传输]----S9306-----ME60-----internet用户
业务简介:
HTTP、TCP、UDP、ICMP等
版本信息:
USG5500 V300R001C00SPC600
其中USG5530S使用VRRP与运营商链路对接。
告警信息
处理过程
通过调整配置,在物理接口GigabitEthernet0/0/6上配置虚MAC使能功能,使防火墙发送的报文源MAC地址使用虚MAC地址后,业务可以正常访问。
根因
1、根据USG5530S NAT Server的配置,在业务不通的时候根据目的IP过滤查看USG5530S上的会话,可以看到源地址为58.251.159.60的主机访问X.X.X.X的80端口,经过NAT转换目的IP地址后转发到内网IP地址192.168.253.2的80端口,从内网IP地址192.168.253.2返回的报文经过NAT转换源地址为X.X.X.X后经从出接口GigabitEthernet0/0/6.6转发,下一跳地址是Y.Y.Y.Y。
nat server 10 protocol tcp global X.X.X.X www inside 192.168.253.2 www vrrp 8

HRP_M[HRB-S-SHJCLOUD-USG5530S-F1-diagnose]display firewall session table verbose-hide both-direction destination global X.X.X.X
11:33:29  2013/01/21
  http  VPN:public --> public
  Zone: gongsiweboutside--> gongsiwebinside  TTL: 00:00:05  Left: 00:00:03
  Interface: GigabitEthernet0/0/2.5  NextHop: 192.168.253.2  MAC: 00-16-3e-00-00-13
  <--packets:0 bytes:0   -->packets:1 bytes:44
  58.251.159.60:49939-->X.X.X.X:80[192.168.253.2:80]

  http  VPN:public --> public
  Zone: gongsiwebinside--> gongsiweboutside  TTL: 00:00:05  Left: 00:00:03
  Interface: GigabitEthernet0/0/6.6  NextHop: Y.Y.Y.Y  MAC: 28-6e-d4-94-91-5b
  <--packets:0 bytes:0   -->packets:2 bytes:88
  192.168.253.2:80[X.X.X.X:80]-->58.251.159.60:49939
 
2、分析USG5530S的流量统计,针对源IP为58.251.159.60,源端口为49939,目的IP为X.X.X.X,目的端口为80的这条流,防火墙正向和反向报文都正常转发,没有丢包。
HRP_M[HRB-S-SHJCLOUD-USG5530S-F1-diagnose]dis firewall statistic acl
11:35:02  2013/01/21

Protocol(TCP) SourceIp(58.251.159.60) DestinationIp(X.X.X.X) 
SourcePort(49939) DestinationPort(80) VpnIndex(public) 
           Receive           Forward           Discard 
Obverse : 3          pkt(s) 3          pkt(s) 0          pkt(s) 
Reverse : 5          pkt(s) 5          pkt(s) 0          pkt(s)
 
Discard detail information:

3、在查看USG5530S会话的同时,在用户侧的S9303上跟传输相连接的接口镜像抓包。分析抓包文件,在抓包文件中抓到的报文跟防火墙流统统计到的报文个数相同,3个正向的58.251.159.60到X.X.X.X的syn报文,5个X.X.X.X到58.251.159.60的syn+ack报文。可以说明经过USG5530S的报文均已经正常转发。


4、在USG5530S正常转发syn+ack报文给上行设备后,正常情况下,上行设备应该回应ack报文给USG5530S,完成TCP三次握手。但是实际上S9303没有收到ack报文,怀疑是上行设备将syn+ack丢弃导致。

5、协调运营商侧配合,采集运营商侧ME60的相关信息,发现防火墙是以用户侧方式接入ME60,即在ME60上有防火墙(作为接入用户)的IP和MAC地址的接入用户表项,ME60会以此检查用户侧报文的源MAC地址,如果报文的源MAC地址不是接入用户表项中的MAC地址就会丢包。ME60是通过ARP报文学习到防火墙虚IP对应的虚MAC地址的。
<ME60>display access-user ip-address X.X.X.X
  -------------------------------------------------------------------
  User MAC                      : 0000-5e00-0108
  User IP address               : X.X.X.X
  Configured accounting method  : No accounting
  6、进一步分析抓包文件中的报文,从USG5530S回去的syn+ack报文的源MAC地址是以接口GigabitEthernet0/0/6的实MAC地址0022-a10d-b8f3转发的。结合上面的第5点,ME60会检查这个syn+ack报文的源MAC地址,由于不是接入用户表项中的User MAC地址(即:0000-5e00-0108)而丢包。 
建议与总结
VRRP场景下,未启用vrrp virtual-mac enable时,USG设备响应对端设备的ARP请求时,会使用虚拟mac,而在发送时,会使用物理接口的mac地址封装数据。若对端设备会检测过滤往返数据的mac地址(例如本例中ME60过滤user-mac),则可能造成转发失败。
该情况下,可以通过在接口上启用vrrp virtual-mac enable,使发送数据时使用虚拟mac封装数据来解决问题。
另外必须注意,目前USG产品仅支持在主接口下配置该命令,子接口下无法配置。 

END