How to send G-ARP manually?

[Jeff_Gao]

Dear team

      I encounter a problem. I replace a juniper firewall with checkpoint application,all dnat is not accessible when i online checkpoint application.I believe this is a arp cache problem,because the dnat is accessible when i modify checkpoint wan interface mac and replace it with juniper wan interface mac.

    I think if i can send a g-arp manually,all problem will be solved.So,how to i can send a g-arp  manually,thanks!

[Maarten_Sjouw]

Gratuitous ARP to force a new MAC addess towards the router

When you want to send the G-ARP for an address that is not configured on a interface you need to enable binding to non-local IP addresses on-the-fly:
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind <---- 0=off, 1=on
arping -c 4 -A -I eth3 10.10.10.10
Replace interface and IP with the ones you need.

[Timothy_Hall · Accepted solution]

THE ISSUE

A new firewall has been procured and you've configured it with all the same IP addresses/routing and security policy as the old firewall. When cut into production, traffic doesn't seem to be flowing between the new firewall and a directly-attached Layer 3 switch/router. Running a:

Code:

Expert# tcpdump -eni ethX

Shows outbound traffic leaving your firewall to the router and replies coming back, but the destination MAC address on the reply frames is still showing the MAC address of the old firewall.

THE SOLUTION

Obviously the optimal solution is to clear the ARP cache on the router, but what if administrative access to it cannot be obtained? Physical access will of course allow a quick power-cycle of the router to clear the cache; one can also try unplugging the physical router interface which may flush any ARP cache entries associated with that interface. With a cluster of firewalls, initiating a failover will cause the new active member to send a gratuitous ARP for the firewall's cluster address and all NAT addresses for which proxy ARP is being performed to solve the problem (this assumes of course that "Use cluster MAC" is not set on the cluster object).

However if there is just a single firewall and not a cluster is there a way to force the firewall to send a gratuitous ARP not only for itself but all NAT addresses that it is supposed to perform proxy ARP for?

THE ARPING COMMAND

Built into SecurePlatform and Gaia is a little-known tool called arping. This command allows the creation of ARP traffic including gratuitous ARPs. For example if the external IP address of your firewall is 129.82.102.32/24 on interface eth1, the following command will cause the firewall to send 4 gratuitous ARPs for its own address, thus updating the ARP cache of any directly adjacent routers on that interface:

Code:

Expert# arping -c 4 -A -I eth1 129.82.102.32
ARPING 129.82.102.32 from 129.82.102.32 eth1
Sent 4 probes (4 broadcast(s))
Received 0 response(s)

This works great for the firewall's address, but what about all those other IP addresses we have plucked from 129.82.102.0/24 for purposes of NAT like 129.82.102.222?

Code:

Expert# arping -c 4 -A -I eth1 129.82.102.222
bind: cannot assign requested address

Oops. Well as it turns out this can be made to work even for addresses that are not physically assigned to interface eth1:

Code:

Expert# echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
Expert# arping -c 4 -A -I eth1 129.82.102.222
ARPING 129.82.102.222 from 129.82.102.222 eth1
Sent 4 probes (4 broadcast(s))
Received 0 response(s)

Taking this a step further, the command fw ctl arp shows a list of addresses plucked from our ISP-assigned range for which the firewall believes it needs to perform proxy ARP so NAT will work for those addresses. For arping to send gratuitous ARPs for every IP address in this list the following command sequence will strip out the IP addresses and feed them one by one to the arping command:

Code:

Expert# fw ctl arp | cut -d\( -f2 | cut -d\) -f1 | xargs -i -t arping -c 4 -A -I eth1 {}

This command will update the ARP cache of a directly-attached Layer 3 switch/router without having to access it or wait the usual default ARP timeout of 4 hours. Obviously this will not work with a router that has been configured to ignore gratuitous ARPs

[steven_dolan7]

Funny i came across this topic as i'm using arping at the moment, 

The issue is it dosent appear to be installed . 

[Expert@sIFirewall]# arping
bash: arping: command not found

Product version Check Point Gaia R77.20
OS build 124
OS kernel version 2.6.18-92cp
OS edition 32-bit

[Timothy_Hall]

It is definitely there as /usr/sbin/arping on R80.30 kernel 3.10 and R80.10 kernel 2.6.18.  I know it was in SecurePlatform too.

[Jeff_Gao]

Thanks

[Giacomo_Arduini]

What if I need to send G-ARP using Cluster VMAC and not PHI node MAC. Using the "standard" "arping -c 4 -A -I  <int> <ip address>" sends and arp reply with PHI MAC ( i.e. arp reply <ip address> is-at <PHI MAC). Is there any way to force the VMAC?

That would be the proper way to do it when you have a cluster with VMAC... Otherwise the peer router learns the PHI mac of the active node... and only when the peer router issues another ARP request will it update its ARP table with the right VMAC...

On many Linux distributions arping gives you the possibility to specify the MAC  address on the arp reply. On Gaia this doesn't seem possible.

Thank you for a feedback

[Luis_Miguel_Mig]

Is there any trick to send gratuitous arps through all the interfaces automatically when you have multiple interfaces?
I guess a failover may be easiest way, but it would be great to have a command too

[Timothy_Hall]

I don't think the arping command itself would be able to do that.

However I guess you could take the ClusterXL VIPs and interface names from the output of cphaprob -a if and feed them into multiple arping commands similarly to what I did above with NAT addresses and the fw ctl arp command.

[Luis_Miguel_Mig]

That is brilliant. But it would be great if checkpoint could do that for us with clusterXL_admin or sth like that 😉

[Timothy_Hall]

So I guess what you are looking for is an "ARP Refresh" for a cluster member that is already active, essentially have it send all gratuitous ARPs as if it had just gone active but without an actual  cluster state change?

[Luis_Miguel_Mig]

Yes, the user case is a cluster hardware replacement. So just to make sure that all the arp tables are up to date after a hardware swap

[Timothy_Hall]

After some digging, it does appear to be possible in ClusterXL to force the gratuitous ARPs to be sent again without an actual failover:  fw ctl set int test_arp_refresh 1

This variable is only documented in the Scalable Platforms/Maestro guides (quoted below), but I checked and test_arp_refresh does exist on the regular gateways as well so I see no reason why it shouldn't work the same:

Verification

To send GARP Requests manually, on the SMO, run:

# g_fw ctl set int test_arp_refresh 1

This causes GARP Requests to be sent (same as was failover).

[Luis_Miguel_Mig]

Hats off Tim. Thanks so much.
I have tested it and it works like a treat.

I noticed that test_arp_refresh  remains 0 for a while. So I  set it manually to 0 after  a while - fw ctl set int test_arp_refresh 0