Gaia 80.40 arp cache time out issue

[GeorgeF]

Hi Experts,

We have a Gaia 80.40 security gateway cluster ( Active,Standby) , and  its VLAN21's interface acts as the gateway of Cisco WLC+APs VLAN21. 

 The end users complains about no internet after connected to WIFI.(passed 802.1x authentication). DHCP server is on CiscoWLC VLAN21 SVI and laptop got a dynamic IP address.

On gateway(Gaia), the Dynamic ARP table seems no update. (The validity timeout is 60s, and Announce Restriction level is 2.)

We find the ARP entry is not right for the non-working laptop. If we delete the ARP entry on gateway, or ping 8.8.8.8 on the laptop, the ARP entry on gateway will update to the right MAC address in a few seconds. ( I think the reply packets was sent to wrong MAC address, which caused the laptop "no internet" before we deleted the wrong one)

It is very weird that the ARP entry on the gateway will stay a very long time, and didn't update.(An example is that: there are only 3 WIFI users, but there are still 80 entries in the gateway's ARP table) . I assume that if the laptop leave the office, its gateway(Gaia) ARP entry should be deleted, as the validity timeout is 60s. I checked the ARP table on WLC, it will delete the laptop's MAC address when users dropped off.

I captured packets form non-working laptop, it seems gateway replied its MAC to laptop when laptop requests, and the laptop also announced itself's MAC address. I assume that during this process, gateway should learn and update ARP table. But it didn't. The IP was still bond to its previous MAC address.( Unless you ping 8.8.8.8 from laptop, or delete ARP entry on the gateway, which is mentioned above)

Is there any mechanic to trigger the gateway(Gaia)'s ARP entry update? Why the dropped off user's ARP entries are still shown in the ARP table? It should be deleted after dropped off for 60s, isn't it?  ( there is no static ARP entry configured, all talking about dynamic entry)

Thanks very much.

[the_rock]

Hey @GeorgeF .

Couple of things I would check. Please run fw ctl arp from expert mode and verify the output, as well as settings from below (global properties in smart console)

Andy

 

[GeorgeF]

Hi 

Thanks for your reply.

1.  the command fw ctl arp output is  " No proxy ARP entries "

2. NAT settings is attached.

By the way, On Saturday  and there are only 3 devices connected to wifi, and on the WLC, the DHCP pool has only 3 active IP addresses. Also I checked the ARP table on the WLC, it has only 3 entries.

But , on the gateway, I find that all the DCHP pool scope entries are there. I mean from 192.168.21.20 - 192.168.21.200, entries are all there! I assume it should be deleted if no one answers its arp request when reached the validity timeout (60s).   

[update] On Sunday, there are only 1 devices connected to wifi, and on the WLC there is only 2 ARP entries (DHCP server and gateway) , But on the gateway, there are still 66 ARP entries... (VLAN21)

It seems the ARP entry stuck for a long time and can't update automatically!  It can only update until Ping or  until many days later it was deleted automatically. 

On the other hand, about the validity timeout, I found it is explained as below:

" Configures the time, in seconds, to keep resolved dynamic ARP entries in the ARP cache table.
If the entry is not referred to and is not used by traffic before this time elapses, the dynamic ARP entry is deleted from the ARP cache table.
Otherwise, an ARP Request will be sent to verify the MAC address. "

How can I check the condition: be referred and be used by traffic ?  I see that all echo-requests ICMP traffic to to gateway ( from 192.168.21.x to 192.168.1.1) are dropped by Clean-up rules, is it "referred" and "used"?  (client to gateway echo-request is allowed)

Thanks again

[GeorgeF · Accepted solution]

It seems someone has the same issue with me:

https://community.checkpoint.com/t5/Security-Gateways/Stale-ARP-Entries/td-p/131577

https://support.checkpoint.com/results/sk/sk175603 

This is the output for command:  cpinfo -y all

This is Check Point CPinfo Build 914000234 for GAIA
[IDA]
No hotfixes..
[MGMT]
HOTFIX_R80_40_JUMBO_HF_MAIN Take: 48
[CPFC]
No hotfixes..
[FW1]
HOTFIX_R80_40_MAAS_TUNNEL_AUTOUPDATE
HOTFIX_GOT_TPCONF_AUTOUPDATE
HOTFIX_R80_40_JUMBO_HF_MAIN Take: 48

FW1 build number:
This is Check Point's software version R80.40 - Build 088
kernel: R80.40 - Build 079
[SecurePlatform]
HOTFIX_R80_40_JUMBO_HF_MAIN Take: 48
[PPACK]
HOTFIX_R80_40_JUMBO_HF_MAIN Take: 48
[CPinfo]
No hotfixes..
[AutoUpdater]
No hotfixes..
[CVPN]
HOTFIX_R80_40_JUMBO_HF_MAIN Take: 48
[CPUpdates]
BUNDLE_CPVIEWEXPORTER_AUTOUPDATE Take: 27
BUNDLE_CPOTELCOL_AUTOUPDATE Take: 25
BUNDLE_GENERAL_AUTOUPDATE Take: 13
BUNDLE_CPSDC_AUTOUPDATE Take: 23
BUNDLE_CORE_FILE_UPLOADER_AUTOUPDATE Take: 21
BUNDLE_R80_40_MAAS_TUNNEL_AUTOUPDATE Take: 49
BUNDLE_HCP_AUTOUPDATE Take: 59
BUNDLE_GOT_TPCONF_AUTOUPDATE Take: 112
BUNDLE_R80_40_JUMBO_HF_MAIN Take: 48
BUNDLE_INFRA_AUTOUPDATE Take: 58
BUNDLE_DEP_INSTALLER_AUTOUPDATE Take: 25
BUNDLE_R80_40_JUMBO_HF_MAIN_SC Take: 45
[CPDepInst]
No hotfixes..
[hcp_wrapper]
HOTFIX_HCP_AUTOUPDATE
[DIAG]
No hotfixes..
[core_uploader]
HOTFIX_CHARON_HF
[cpsdc_wrapper]
HOTFIX_CPSDC_AUTOUPDATE
[CPotelcol]
HOTFIX_OTLP_GA
[CPviewExporter]
HOTFIX_OTLP_GA

[GeorgeF · Accepted solution]

Updated to the hotfix take 197 and set the new added parameter to 1, then solved the issue, the arp table's updates works well.