problem with proxy arp

[Andrew25]

I need to perform a simple operation to publish the server to the Internet.
For this:
1. I create a manual static nat
2. Add the address in the proxy arp via WEB-UI (85.21.100.105 - Public server IP)
3. I turn on the global settings option "Merge manual proxy ARP configuration"
4. install policy.

But unfortunately, the firewall does not respond to arp requests for the published server

What did not I finish?

FW-r80.10, MNG-r80.10

show arp proxy all
IP Address MAC Address / Interface Real IP Address
85.21.100.105 eth8 85.21.100.111

85.21.100.111 - ext ip

[Timothy_Hall]

What does the output of "fw ctl arp" show from expert mode?

What is the subnet mask of 85.21.100.X?  Are you SURE that 85.21.100.105 and 85.21.100.111 exist in the same subnet?  Proxy ARP will only be performed by the firewall for NAT addresses plucked from what it thinks is a directly-attached IP range.

Is a firewall cluster involved? 

Also make sure it is a *proxy* ARP you added via the Gaia web interface, not a *static* ARP.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Andrew25]

[]# fw ctl arp
(85.21.100.105) at 00-1c-7f-83-b7-7f interface 85.21.100.111

Yes this one subnet

This is not a cluster

This is not statics ARP, you can see from the output of commands

[Timothy_Hall]

If you run "tcpdump -eni eth8 arp" from expert mode, are you seeing an inbound ARP request for 85.21.100.105 from your perimeter router?

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Andrew25]

There are queries, no answers

17:12:15.468575 6c:c2:17:78:7c:2a > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 85.21.100.105 tell 85.21.100.112 - my test PC

17:12:16.384090 d4:6d:50:6b:c5:61 > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 85.21.100.105 tell 85.21.100.97

17:12:16.468832 6c:c2:17:78:7c:2a > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 85.21.100.105 tell 85.21.100.112

17:12:24.468699 6c:c2:17:78:7c:2a > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 85.21.100.105 tell 85.21.100.112

[Timothy_Hall]

I'm suspecting that the firewall object topology definition for eth8 does not match the underlying Gaia interface configuration.  Please provide a screenshot of eth8's topology in the SmartConsole, and the output from following expert mode commands:

ifconfig eth8

fw stat

arp -an | grep 85.21.100.

netstat -rn | grep 85.21.100.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Andrew25]

ifconfig eth8
eth8 Link encap:Ethernet HWaddr 00:1C:7F:83:B7:7F 
inet addr:85.21.100.111 Bcast:85.21.100.127 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:60326 errors:0 dropped:0 overruns:0 frame:0
TX packets:42250 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 
RX bytes:34872545 (33.2 MiB) TX bytes:10041607 (9.5 MiB)

 fw stat
HOST POLICY DATE 
localhost CO_test 9Oct2017 15:45:59 : [^eth1] [^eth1] [^eth8] [^eth8]

arp -an ^ grep 85.21.100.
? (85.21.100.97) at D4:6D:50:6B:C5:61 [ether] on eth8

netstat -rn ^ grep 85.21.100.
85.21.100.96 0.0.0.0 255.255.255.224 U 0 0 0 eth8
0.0.0.0 85.21.100.97 0.0.0.0 UGD 0 0 0 eth8

[Timothy_Hall]

Well everything looks correct here, has anything in the config of the underlying Gaia eth8 interface been changed on the fly at all since the last boot? Try tcpdump again, but this time with the -p option to suppress promiscuous mode as shown below, do you still see the ARP requests for 85.21.100.105 coming in:

tcpdump -p -eni eth8 arp

If you don't seem them coming in any more it is a network problem.  If you do still see them coming in, try running

fw ctl zdebug drop

Is it logging any kind of drop or other difficulty handling ARP in the zdebug?

Next try reinstalling policy, then try this next from expert mode:

ifdown eth8;ifup eth8

If that still doesn't work only thing I can suggest at this point is a reboot, lame as that sounds.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Andrew25]

Very interesting, this firewall is not a cluster

;[cpu_1];[fw4_0];fw_log_drop_ex: Packet proto=-1 ?:0 -> ?:0 dropped by fwha_process_incoming_arp Reason: The packet is designated to an ip address that is proxied, but I'm not an active member

[Timothy_Hall · Accepted solution]

You may not have the ClusterXL box checked on the firewall object in the SmartConsole, but I can pretty much guarantee that clustering is enabled in cpconfig which is the problem.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Andrew25]

Yes, you were right! I disabled clustering - the proxy arp earned. It's great, thanks a lot, excellent troubleshooting!!!

[Timothy_Hall]

Glad to hear, as it turns out there is actually a SK documenting this that I'll link here for future reference:

sk34453: Automatic Static NAT does not work on Security Gateway

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Stefano_Bucci]

Thanks for this.

[Andrejs__Андрей]

hello All,

Andrey, try move your NAT rules above implied rules.

regards,

--

ak.

[Andrew25]

These are the highest rules, there is nowhere to go

[Yatiraj_Panchal]

Hi @Andrew25 

You can configure the below configuration on the CLI of each cluster member.

1. Modify the $CPDIR/tmp/.CPprofile.sh script:
1. Back up the current $CPDIR/tmp/.CPprofile.sh script:

[Expert@HostName:0]# cp -v $CPDIR/tmp/.CPprofile.sh $CPDIR/tmp/.CPprofile.sh_ORIGINAL

1. Edit the current $CPDIR/tmp/.CPprofile.sh script:

[Expert@HostName:0]# vi $CPDIR/tmp/.CPprofile.sh

1. Before the last line, add:

_cpprof_add CP_AUTO_ARP_FOR_MANUAL_NAT_RULES "1" 0 0

1. Save the changes and exit the Vi editor.
1. Modify the $CPDIR/tmp/.CPprofile.csh script:
1. Back up the current $CPDIR/tmp/.CPprofile.csh script:

[Expert@HostName:0]# cp -v $CPDIR/tmp/.CPprofile.csh $CPDIR/tmp/.CPprofile.csh_ORIGINAL

1. Edit the current $CPDIR/tmp/.CPprofile.csh script:

[Expert@HostName:0]# vi $CPDIR/tmp/.CPprofile.csh

1. Before the last line, add:

setenv CP_AUTO_ARP_FOR_MANUAL_NAT_RULES "1"

1. Save the changes and exit from Vi editor.
1. Reboot the Security Gateway.
2. Verify that the relevant environment variable was set:

1. In the Bash shell:
1. Log into the Expert mode.
2. Check the value of the variable:

[Expert@HostName:0]# echo $CP_AUTO_ARP_FOR_MANUAL_NAT_RULES

Output should show a value of 1.

1. In the Csh shell:
1. Log into the Expert mode.
2. Log into the Csh shell:

[Expert@HostName:0]# csh

1. Check the value of the variable:

[admin@HostName ~]# echo $CP_AUTO_ARP_FOR_MANUAL_NAT_RULES

Output should show a value of 1.