No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>


To have a better experience, please upgrade your IE browser.


Usg5500 firewall communicate in transparent mode appears fault

Publication Date:  2012-10-09 Views:  542 Downloads:  0
Issue Description
1, usg5500 firewall enabled AV anti-virus functions. Working in transparent mode (the second layer)
2, PC, switch SW, router headquarters are in the same network segment
3, PC’s gateway is in exchange, exchange’s gateway is in the headquarters router.
4, from the branch router to ping headquarters PC ( often appears the phenomenon that ping impassability. Through the following two ways can recovery:
1), if long ping, fault happens, about 20 minutes can resume ping
2), unable to ping, if in the usg5500 firewall ping the PC, then branch ping can also ping the PC
Alarm Information
Handling Process
Solution a: take out the IP address of internal network switch’s Vlanif, migrate the Vlanif’s IP address( to the headquarters router’s internal network port through the sub IP way.
Solution b: set the gateway of internal network PC to router IP(
Solution c:: adjust the headquarters router internal network port’s ARP aging time to 3 minutes.
Root Cause
1, branch ping headquarters PC, if can ping (communication normal), in our firewall session table and MAC forward table, are all right
2, if ping impassability, the MAC forwarding table and session table do not exist.
A, View MAC forwarding table, the table item does not exist:
[cc-shiyuan_usg5530]dis mac-add 3-3-3
MAC Address    VLAN ID  Left Time(s)  Port                      Type      LSP 
Total 0 ,0 printed
B, Check session table, session table also does not exist:
[cc-shiyuan_usg5530]display firewall session table verbose protocol icmp
Current Total Sessions : 0
C, Check firewall packet loss statistics:
[cc-shiyuan_usg5530-hidecmd]display firewall debug_statistic
Current Show sessions count: 1 
Discard detail information:
  DP_Input_Eth                  :exit 1:     11
  DP_L3Fwd_ProcessIpv4          :exit 2:     11
  DP_L3Fwd_DataProcess          :exit 2:     11
  DP_L3Fwd_StatusChk        :exit 2:    11 //State detection packet loss, firewall did not detect the session, received the reply message of ping, packet will be lost
Through checking it is because of the first packet did not establish session, the came back packet did not detect the session and packet loss
Through the principle analysis of the reasons:
1, firewall’s MAC forwarding table learning:
When the branch first launch a access to headquarters PC192.168.1.3, through the ARP request, in the firewall to learn the MAC forwarding table as follows, it has learnt three MAC forwarding table items, including exchange vlanif (internal network PC’s gateway), router (exchange gateway) and PC MAC address
2, firewall MAC forwarding table refresh aging:
When do subsequent long ping operation, firewall only refresh message source MAC forwarding table items (branch access headquarters, refresh MAC forwarding table items, the PC response branch, refresh MAC forwarding table items), and MAC address forwarding table hasn’t been refreshed and gradually aging, when reaches aging time, the table item is deleted
3, session in firewall loss packets due to PC’s MAC forwarding table item aging:
When the firewall PC’s MAC forwarding table item aging, at this time to the message from a branch to visit headquarters, because purpose MAC forwarding table items (3-3-3) has been aging, the message directly radio in the corresponding VLAN, will not create conversation, when reply message pass through the firewall, due to the lack of conversation it will loss packets.
Note: to TCP message or ICMP message, firewall will check message state, to ensure the network security, only ICMP Request or TCP Syn packet can create conversation, other status message can only according to the conversation forwarding, if conversation does not exist, the packet will be lost.