[ScreenOS] The downstream router does not automatically obtain the ARP

Summary:

This article describes the issue of the downstream router not automatically obtaining the ARP, when the Ignore IP conflict option is enabled on the virtual router and the loopback interface IP is provided in the same subnet as that of the other interface IP.

Symptoms:

Network diagram:

Firewall 1 (eth0/0) 88.88.88.1/24-------88.88.88.2/24 (eth0/0) and (loopback .1)88.88.88.8/30 Firewall 2

Firewall 1 has the eth0/0 interface directly connected to Ethernet 0/0 of Firewall 2 in the same subnet.

Firewall 2 has the loopback.1 interface bounded to Ethernet0/0 within the same subnet, with ignore subnet conflict being enabled.

Firewall 1 wants to communicate to Firewall 2 via the loopback interface.

To communicate to 88.88.88.8 from Firewall 1, an ARP entry has to be manually added, as Firewall 2 does not take care of this; although, 88.88.88.8 is in the same subnet of eth0/0.

After manually adding the ARP entry on Firewall 1(or downstream router) with the MAC address of eth0/0 of Firewall 2, communication was successful.

Cause:

Solution:

ARP table of Firewall 1:

----------------------------------------------------------------------------
IP           Mac         VR/Interface   State    Age   Retry PakQue Sess_cnt
----------------------------------------------------------------------------
88.88.88.2 0010dbff2000 trust-vr/eth0/0 VLD    1134 0      0      1

After manually adding the ARP entry on Firewall 1(or downstream router) with the MAC address of eth0/0 of Firewall 2, communication was successful:

Command :

set arp 88.88.88.8 0010dbff2000 ethernet0/0

-------------------------------------------------------------------------------------
IP              Mac         VR/Interface   State    Age    Retry  PakQue Sess_cnt
-------------------------------------------------------------------------------------
88.88.88.2  0010dbff2000 trust-vr/eth0/0 VLD        1161   0      0      1
88.88.88.8  0010dbff2000 trust-vr/eth0/0 STS               0      0      0

When ARP is not successful, the following output is generated:

cached arp entry with MAC 000000000000 for 88.88.88.8 add arp entry with MAC 000000000000 for 88.88.88.8 to cache table wait for arp rsp for 88.88.88.8 ifp2 ethernet0/0, out_ifp ethernet0/0, flag 00000600, tunnel ffffffff, rc 0 outgoing wing prepared, not ready

After adding the MAC entry:

cached arp entry with MAC 0010dbff2000 for 88.88.88.8 arp entry found for 88.88.88.8 ifp2 ethernet0/0, out_ifp ethernet0/0, flag 00800600, tunnel ffffffff, rc 1 outgoing wing prepared, ready

However on Firewall 2, the packet never reached; when the MAC entry was not manually provided.

Note: This kind of scenario is required, when Firewall 1 and Firewall 2 want to configure two active VPNs; but they have only one 1 ISP.

Firewall 1 --------- ISP 1 ++++++++++++++++++ ISP2 -------------firewall 2

So, in this case, Firewall 2 can create the loopback interface as the same subnet as the untrust IP; so Firewall 2 will have two gateway IP addresses for Firewall 1.

Knowledge Base