[ScreenOS] Unable to manage Backup firewall even with 'set flow mac-cache mgt' from remote subnet

Summary:

Customer is unable to manage backup device running on ScreenOS 6.2 from a single remote subnet even though he has configured ‘set flow mac-cache mgt’ command on the device.

Symptoms:

A customer is unable to manage the backup firewall from a remote subnet 10.10.10.15/32, through manage IP assigned to E1/1. The command ‘set flow mac-cache mgt’ was configured on the backup.Traffic is hitting the interface E1/1, however the reverse route is pointing to E1/2, which is inactive.

Example command and debug output:

get interface

Name       IP Address             Zone
   mgt     192.168.1.1/24         MGT
eth1/1     172.27.201.193/24      Untrust
eth1/2     10.10.10.10/24         Trust

Routing Table :

  ID         IP-Prefix        Interface  Gateway       P      Pref  Mtr   Vsys
   7      10.10.10.10/32      eth1/2     0.0.0.0       H      0     0     Root
 * 2      192.168.1.1/32      mgt        0.0.0.0       H      0     0     Root
   8      172.27.199.15/32    eth1/2     172.27.201.1  S      20    1     Root
 * 3      172.27.201.0/24     eth1/1     0.0.0.0       C      0     0     Root
* 1       192.168.1.0/24      mgt        0.0.0.0       C      0     0     Root
   4      172.27.201.193/32   eth1/1     0.0.0.0       H      0     0     Root
   6      10.10.10.0/24       eth1/2     0.0.0.0       C      0     0     Root

get nsrp

group priority preempt holddown inelig       master            PB          other members myself uptime
    0       100          no           3               no       10523776     myself              00:15:41
total number of vsd groups: 1
Total iteration=945,time=1811211,max=389190,min=1054,average=1916

RTO mirror info: run time object sync: disabled route synchronization: disabled ping session sync: enabled coldstart sync done nsrp data packet forwarding is disabled

In the debug, it is noticed that the firewall is caching the route; however a reply packet is not generated.

**st: <Untrust|ethernet1/1|Root|0> 4814cc0: 3d1d:10.10.10.15/200->10.10.10.194/4a0a,1,60 01387.0: ethernet1/1(i) len=74:00101863902a->002283a0aa87/0800 10.10.10.15 -> 10.10.10.194/1 vhl=45, tos=00, id=15645, frag=0000, ttl=127 tlen=60 icmp:type=8, code=0 ****** 01387.0: <Untrust/ethernet1/1> packet received [60]****** ipid = 15645(3d1d), @04814cc0 packet passed sanity check. flow_decap_vector IPv4 process ethernet1/1:10.10.10.15/18954->10.10.10.194/512,1(8/0)<Root> no session found flow_first_sanity_check: in <ethernet1/1>, out <N/A> existing vector list 20-2884c6a4. create a self session (flag 0x206), timeout=60sec. flow_first_install_session======> handle cleartext reverse route search route to (self, 10.10.10.194->10.10.10.15) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet1/1 cached route 0 for 10.10.10.15 no route to (0.0.0.0->10.10.10.15) in vr trust-vr/0 ifp2 ethernet1/1, out_ifp ethernet1/1, flag 00000601, tunnel ffffffff, rc 0 cache src mac in session for reverse direction flow got session. flow session id 524274 flow_main_body_vector in ifp ethernet1/1 out ifp N/A flow vector index 0x20, vector addr 0x2884c6a4, orig vector 0x2884c6a4 post addr xlation: 10.10.10.15->10.10.10.194. packet is for self, copy packet to self copy packet to us.

Solution:

For the ‘set flow mac-cache mgt’ command to work, an active route for the source subnet (doesn’t matter to which interface it is pointing), is required because the reply packet is handled by kernel protocol stack at first and in current implementation, the kernel protocol stack does not care about the status of 'set flow mac-cache mgt'.
The kernel always looks up the route table. If kernel cannot find an active route, the packet is dropped. There must be an active route for the source subnet, although it is not necessary to use the interface specified in this route, as the outgoing interface for the reply traffic.

As per KB13985 - After upgrade to ScreenOS 6.2.0, the VSI state of a backup device changes from Inactive to Down. Why?, in ScreenOS 6.2 or later, if NSRP data forwarding is disabled and there is no manage IP on the interface, then the route linked to that interface is shown as down. In this case as the route for source subnet is pointing to E1/2 and there was no manage-ip configured on that interface, it is shown as down. After configuring a manage-ip on E1/2, the route becomes active and backup device is accessible from that source subnet.

Knowledge Base