The problem that cross the network segment to access to usg5300 management address failure in transparent mode

Publication Date:  2012-10-23 Views:  507 Downloads:  0
Issue Description
PC gateway in the core layer , connect Layer 2 switch and usg5300 in the middle, firewall is in transparent mode, PC and equipment management address is not in the same management vlan, PC can't ping passably firewall management address, network structure as shown in figure:


The related devices configuration:
FW configuration
#
firewall packet-filter default permit  all
#
interface GigabitEthernet0/0/0
  port trunk allow-pass vlan 1 51 to 53 1000 to 1001
#
interface GigabitEthernet0/0/3
  port trunk allow-pass vlan 1 51 1001
#
firewall zone trust
  add interface GigabitEthernet0/0/1
#
firewall zone untrust
  add interface GigabitEthernet0/0/0
#
interface Vlanif1001
  ip address 172.254.2.135 255.255.255.192
#
ip route-static 0.0.0.0 0.0.0.0 172.254.2.129
Core SW
#
interface GigabitEthernet 1/1
  switchport mode trunk
#
interface VLAN 51
  no ip proxy-arp
  ip address 172.254.3.2 255.255.255.192
  vrrp 1 priority 120
  vrrp 1 timers advertise 3
  vrrp 1 version 3
  vrrp 1 ip 172.254.3.1
  vrrp 1 track 172.254.2.140 30
#
interface VLAN 1001
  no ip proxy-arp
  ip address 172.254.2.130 255.255.255.192
  vrrp 1 priority 120
  vrrp 1 timers advertise 3
  vrrp 1 version 3
  vrrp 1 ip 172.254.2.129
convergence SW
#
interface GigabitEthernet 0/16
  switchport access vlan 51
#
interface GigabitEthernet 0/17
  switchport mode trunk
#
interface VLAN 1001
  ip address 172.254.2.141 255.255.255.192
#
ip route 0.0.0.0 0.0.0.0 172.254.2.129
Alarm Information
none
Handling Process
1, check the router configuration such as packet filtering etc. and there is no problem.
2, according to the configuration, access usg management address message need pass FW many times, as the chart:
Ping FW management address, check session:
  icmp  VPN:public --> public
  Zone: trust--> untrust  TTL: 00:00:20  Left: 00:00:09
  Interface: GigabitEthernet0/0/1  NextHop: 172.254.2.135  MAC: 00-00-5e-00-01-02
  <--packets:0 bytes:0   -->packets:5 bytes:420
  172.254.3.3:57-->172.254.2.135:2048
According to the above message trend to analysis, the above session is established in the first time passing the firewall to, but the message second pass the FW back to the usg from the core switch should also build a session, the direction is from untrust to local, but because the source and destination address is the same, and the firewall session table forwarding relationship, firewall think it is a illegal message, do not build a new session, and discard message, access failure.
3、solution: add firewall management vlan to virtual firewall, adding configuration is as follows:
#
ip vpn-instance vfw1 vpn-id 1
  route-distinguisher 1:1
#
vlan 1001
   binding vpn-instance vfw1
#
firewall zone vpn-instance vfw1 trust
  add interface GigabitEthernet0/0/1
#
ip route-static vpn-instance vfw1 0.0.0.0 0.0.0.0 172.254.2.129
After configure access successfully, FW create a two session table to distinguish the scene pass the FW between the first time and the second time.
icmp  VPN:vfw1--> vfw1
  Zone: trust--> local  TTL: 00:00:20  Left: 00:00:09
  Interface: GigabitEthernet0/0/0  NextHop: 172.254.2.135  MAC: 00-00-5e-00-01-02
  <--packets:5 bytes:420   -->packets:5 bytes:420
  172.254.3.3:57-->172.254.2.135:2048
icmp  VPN:public --> public
  Zone: trust--> untrust  TTL: 00:00:20  Left: 00:00:09
  Interface: GigabitEthernet0/0/1  NextHop: 172.254.2.135  MAC: 00-00-5e-00-01-02
  <--packets:5 bytes:420  -->packets:5 bytes:420
  172.254.3.3:57-->172.254.2.135:2048
Root Cause
1、the configuration is wrong
2、do not support this access scene.
3、other
Suggestions
As the session table, message access firewall failure twice, need to secondary access to establish a session again.

END