Proxy Arp's for subnet not on firewall

[Juan_Concepcion]

I have run into this several times where I create proxy arp(s) on external interface of the firewall for a distinct subnet so for example:

Firewall interface 1.1.1.2

NAT: 2.2.2.2

add arp proxy ipv4-address 2.2.2.2 interface eth1 real-ipv4-address 1.1.1.2

the firewall does not respond for the proxy arp(s) but rather routes it back to it's default gateway.  It's not until I add in a static route with reads:

add static-route 1.1.1.2/32 nexthop gateway logical eth1

that it will start responding for the arps.  Is this expected behavior??

--Juan 

[Timothy_Hall]

The correct procedure to add your own manual static proxy ARPs will vary substantially depending on code version, OS, and/or the presence of a firewall cluster.  Please see the following:

sk30197: Configuring Proxy ARP for Manual NAT

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

[Juan_Concepcion]

As stated in original post R80.10 is the version and adding in the manual proxy arps is not suffice. When I do this the arp entries are seeing via ‘fw ctl arp’ but when you run an ‘fw monitor’ on the firewall you see that it just simply tries to route the traffic back out if there is not s subsequent “dummy” route provisioned for the address space that does not pertain to the subnet configured on it’s external interface.

--Juan

[PhoneBoy]

You can only arp for IPs on the same subnet as one of your interfaces.

This is how arp works.

I suppose adding static routes like you described is another way to achieve the same result. 

[Juan_Concepcion]

So how am I supposed to handle NAT's when they are not located on the same subnet as the external interface of the firewall and you don't have control of upstream router (to route traffic to firewall)??  In previous versions all you had to do was add in manual proxy arps and the firewall received the traffic and processed it correctly.  Now it receives the traffic correctly but then incorrectly just tries to route it out unless you have the dummy static route in place.

[PhoneBoy]

I'm actually surprised it worked like you described at all. 

Your workaround reminds me of NAT in the old days

[Juan_Concepcion]

That is what came to mind in how to fix it ☺

That is the behavior it’s exhibiting…

[PhoneBoy]

Seriously, though, it might be worth a TAC case.

[Norbert_Bohusch]

You should handle such cases by routing the required IPs / subnets from your nexthop to the gateway(-cluster)-IP.

So if your gw/cluster has IP 1.1.1.2 and router in front has 1.1.1.1, there should be a route from the router for 2.2.2.2 (or corresponding subnet like 2.2.2.0/x) to the IP 1.1.1.2

[Juan_Concepcion]

Doesn’t work – customer has the traffic routed to his firewall and it just routes it back out without the configuration I put in.

--Juan

[Sergio_Alvarez]

Hello,

I noticed your post is from sep 2017, do you know if, by any chance, they have fixed this in recent Jumbos or maybe R80.20?

Regards