USG5530S(V3R1)双机公网无法访问映射服务器

发布时间:  2014-12-31 浏览次数:  238 下载次数:  0
问题描述
业务组网图:
Webserver------USG5530S-----S9303---[传输]----S9306-----ME60-----internet用户
业务简介:
各种业务都有,HTTP、TCP、UDP、ICMP等
版本信息:
USG5500 V300R001C00SPC600B067
故障现象
客户使用USG5530S通过NAT Server发布内网web服务器到Internet,Internet用户无法访问web服务。
处理过程
1、根据USG5530S NAT Server的配置,在业务不通的时候根据目的IP过滤查看USG5530S上的会话,可以看到源地址为58.251.159.60的主机访问222.32.72.192的80端口,经过NAT转换目的IP地址后转发到内网IP地址192.168.253.2的80端口,从内网IP地址192.168.253.2返回的报文经过NAT转换源地址为222.32.72.192后经从出接口GigabitEthernet0/0/6.6转发,下一跳地址是222.32.72.1。
nat server 10 protocol tcp global 222.32.72.192 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 222.32.72.192
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-->222.32.72.192: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: 222.32.72.1  MAC: 28-6e-d4-94-91-5b
  <--packets:0 bytes:0   -->packets:2 bytes:88
  192.168.253.2:80[222.32.72.192:80]-->58.251.159.60:49939
  
2、分析USG5530S的流量统计,针对源IP为58.251.159.60,源端口为49939,目的IP为222.32.72.192,目的端口为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(222.32.72.192)  
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到222.32.72.192的syn报文,5个222.32.72.192到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地址的。
<ZX-ME60-X16>display access-user ip-address 222.32.72.192
  -------------------------------------------------------------------
  User access index             : 13390
  State                         : Used
  User name                     : ZX-ME60-X16-03000320700000@jtip
  Domain name                   : jtip
  User access interface         : GigabitEthernet3/0/0.3200
  User access PeVlan/CeVlan     : 3207/-
  User MAC                      : 0000-5e00-0108
  User IP address               : 222.32.72.192
  User Primary-DNS              : 211.98.2.4
  User Secondary-DNS            : 61.236.93.33
  User MSIDSN name              : -
  Vpn-Instance                  : Public
  User access type              : VLAN-ARP
  User authentication type      : Bind authentication
  Server-template of second acct: -
  Agent-Circuit-Id              : -
  Agent-Remote-Id               : -
  Option82(18) information      : -
  Current authen method         : No authentication
  Authen result                 : Success
  Current author method         : Idle
  Author result                 : Idle
  Action flag                   : Idle
  Authen state                  : Authed
  Author state                  : Idle
  Configured accounting method  : No accounting
  Quota-out                     : Offline
  Current accounting method     : No accounting
  Realtime-accounting-switch            : Close
  Realtime-accounting-interval(sec)     : -
  Realtime-accounting-send-update       : No
  Access start time             : 2013-01-21 10:25:32
  Accounting start time         : 2013-01-21 10:25:32
  Online time (h:min:sec)       : 00:11:45
  Accounting state              : Ready
  Idle-cut-data (time,rate,idle): 0 minute, 60 kbyte/min, 0 min 0 sec
  Multicast-profile             : -
  Multicast-profile-ipv6        : -
  Max Multicast List Number     : 4
  User-Group                    : -
  Up packets number(high,low)   : (0,0)
  Up bytes number(high,low)     : (0,0)
  Down packets number(high,low) : (0,485)
  Down bytes number(high,low)   : (0,42644)
  IPV6 Up packets number(high,low)     : (0,0)
  IPV6 Up bytes number(high,low)       : (0,0)
  IPV6 Down packets number(high,low)   : (0,0)
  IPV6 Down bytes number(high,low)     : (0,0)
  -------------------------------------------------------------------

6、进一步分析抓包文件中的报文,从USG5530S回去的syn+ack报文的源MAC地址是以接口GigabitEthernet0/0/6的实MAC地址0022-a10d-b8f3转发的。结合上面的第5点,ME60会检查这个syn+ack报文的源MAC地址,由于不是接入用户表项中的User MAC地址(即:0000-5e00-0108)而丢包。

7、通过调整配置,在物理接口GigabitEthernet0/0/6上配置虚MAC使能功能,使防火墙发送的报文源MAC地址使用虚MAC地址后,业务可以正常访问。

根因
综上分析,故障的原因是防火墙以用户侧方式接入运营商ME60,ME60设备存在接入用户表项机制,对经过ME60转发的报文会检查源MAC跟接入用户表项中的用户MAC是否一致。ME60上通过ARP报文学习防火墙的虚IP地址对应的虚MAC地址,作为接入用户表项的User MAC地址,USG5530S以接口GigabitEthernet0/0/6的实MAC地址转发报文,ME60检查源MAC地址不一致而丢包造成业务故障。
解决方案
方案1:协调修改运营商ME60配置,防火墙以网络侧方式接入ME60,不存在用户接入表项相关机制,排除ME60对报文源MAC地址进行检查。

方案2:调整USG5530S配置,在GigabitEthernet0/0/6上配置虚MAC使能功能,使用虚MAC地址作为源MAC地址发送报文。
#                                                                                                                                  
interface GigabitEthernet0/0/6                                                                                                     
combo enable fiber                                                                                                                
description to_[HRB-G-SHJDATA-S9303-S1]GE1/0/2                                                                                    
ip address 192.168.200.1 255.255.255.0                                                                                            
vrrp vrid 8 virtual-ip 222.32.72.192 255.255.255.0 master                                                                         
vrrp virtual-mac enable                                                                                                           
#  

END