R80.10 - Hide behind many question

[VENKAT_S_P]

Started loving R80.10, but still need to explore more.

Have a question :Whether R80.10 supports Hide behind many ip address (like range or pool of address), or still we need to divide the sources if the scaling crosses 50k ports.

[PhoneBoy]

It's a little more complicated than just 50,000 connections going to the same destination, as described here: Dynamic NAT port allocation feature 

In general, though, you can only specify one address as the source IP for a HIDE address, which should still also apply to R80.10.

[VENKAT_S_P]

probably in future releases.
Thanks Dameon for prompt reply.

[Timothy_Hall · Accepted solution]

Sorry to come in so late on this thread, but what I would call "many-to-fewer" hide NAT is most definitely possible via manual NAT rules and has been around since R75.  It is not really documented but it definitely does work, subject to the following:

1) Manual NAT must be used

2) In Original Source put the inside network object to hide

3) Translated Source of the manual NAT rule MUST be a IP Address Range object (a network object will not work), configured with the routable range of "fewer" addresses to hide behind

4) By default after adding the range object in Translated Source it will be set to static, right-click and force it to Hide

5) Because you are almost certainly plucking these "fewer" addresses from your routable range of addresses located on the dirty subnet between the firewall's external interface and the perimeter router, you must add manual static proxy ARPs for ALL addresses in the "fewer" range.  Failing to add static proxy ARPs for every address in the "fewer" range will cause random-looking failures for some internal hosts and not others.

If you are running R80.10 gateway though check out sk114395: Automatic creation of Proxy ARP for Manual NAT rules on Security Gateway R80.10.  Edit: I recently saw a many-to-fewer NAT setup utilizing this new Auto Proxy ARP feature on a R80.10 gateway and it worked great!

As I recall the selection of which "fewer" IP address to hide a particular internal host behind depends on that host's IP address.  So if we are using 192.168.1.0/24 internally and hiding behind 129.82.102.32 - 129.82.102.35, internal host 192.168.1.3 might draw 129.82.102.33 for all its connections while 192.168.1.134 might draw 129.82.102.35 for all its connections.  I don't think the "fewer" address associated to an internal IP will ever change though (unless the "fewer" IP range changes) so there must be some kind of static hash function at work here.  This behavior is mentioned here:

sk105302: Traffic NATed behind an Address Range object is always NATed behind the same IP address

The even distribution of internal addresses to external "fewer" addresses will never be perfect of course, but will allow one to go well beyond the 50k limit of concurrent connections to the same destination being hidden by a single hide NAT rule.  I just tried it in my R80.10 lab for grins and this setup still works.

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

[VENKAT_S_P]

Thanks a lot Tim, this really helps. 

[Timothy_Hall]

Here is a screenshot from the Second Edition of my book Max Power that nicely summarizes how to set this up:

--
My Book "Max Power: Check Point Firewall Performance Optimization"
Second Edition Coming Soon

[Carlos_Machado1]

Hi, Timothy. I was presented with this case today and your answer was very helpful! Still, I'm having trouble with the proxy ARP configuration, since I have to do it manually.

I created an address range object and configured the NAT rule accordingly, but I can't seem to add the proper Proxy ARP entry for source NAT, since I'm having trouble recognizing which would be the advertised IP and the real IP.

Could you please elaborate on this? Thanks in advance.

[Timothy_Hall]

Precisely how the Proxy ARPs are added will depend on whether ClusterXL is in use and some other factors such as hardware platform.  Please check out the fairly lengthy sk30197: Configuring Proxy ARP for Manual NAT for the correct steps to use in your specific environment.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Vladimir]

Tim,

Can you remind me if the Proxy ARP is still necessary when we are configuring manual NAT rule for hiding our encryption domain behind the IP/Range provided by the peer?

[PhoneBoy]

If the packets for those IPs would only arrive encrypted, proxy ARPs shouldn't be necessary.

[Timothy_Hall]

As Dameon mentioned any IP addresses being tunneled by IPSec do not need a proxy ARP (even if they are plucked from your ISP-assigned routable range or dirty subnet) as the outside destination IP address on the ESP packet is just the external IP of the firewall for which it will already automatically answer ARP requests.

For NAT the only time proxy ARPs are required is when "plucking" NAT addresses from a subnet that is directly attached to the firewall itself.  In the real world this is most typically the so-called "dirty" subnet sitting between the firewall and the Internet perimeter router.  In most implementations all or at least a chunk of the ISP-assigned routable address space exists on the dirty subnet.  Any addresses plucked from that directly-attached dirty subnet for NAT will need Proxy ARP service provided by the firewall. 

However other portions of ISP-assigned space (whether they be different subnets adjacent or near to the dirty subnet, or a completely different routable subnet assigned by the ISP later when the original one was exhausted) are merely using the dirty subnet as a transit to reach the firewall and do not need Proxy ARPs as a result.  There will be static routes on the Internet perimeter router for these other routable subnets designating the firewall's outside address as the next hop, so there is no need for the Internet perimeter router to ARP for the destination IP addresses in those packets.  Proxy ARP is usually just for the benefit of the Internet perimeter router, regardless of whether your organization owns it or your ISP manages it.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Vladimir]

Thank you.

I typically break down the public range and use it's small subnet between gateways/clusters and the ISP router. The other subnets of the public range are forwarded from the router to the external IP of the gateway or cluster for either use in DMZ(s) or NAT. This does remove the need for the Proxy ARP.

[Kristof_Vermael]

Hello,

I'm in the assumption that Proxy ARP is not needed when you translate the source address only. The router will learn the MAC address from the initial packet and everything will work. ( I'm never been in a situation where the return packet exceeded the time-out of the mac table. )

I'm only configuring Proxy ARP when doing a Destination NAT since the first packet will come from a router.

If a customer doesn't like proxy arp, you can always ask your ISP to put host routes to your VIP ip address for your "plucked" IP's.

[Jennifer_Wilson]

Cheers Tim, can confirm this works great on a 41K on R76SP.50.

This is with the Dynamic Port allocation turned on (which is default), which we have been told to run off by support as it's causing us issues.

We needed to add a couple of /16s as Hide NAT addresses and this has saved us loads of time as we haven't had to create 500+ objects and NAT rules.

Hopefully it still works OK when we turn off Dynamic NAT port allocation, will let you know.

[Jennifer_Wilson]

Just confirming this is still working fine after turning Dynamic NAT off (also after having installed Hotfixes 002 and 050 for CCP issues causing blades and chassis to failover).

[Zaw_Hein_Aung]

Hello,

I am not CheckPoint employee, is there any chance that I can buy your book?

I need to configure hide NAT using public IP pool for a customer. Thank you.

Regards

AZH

[Timothy_Hall]

Hi Zaw,

All the steps you need to set up a many-to-fewer NAT are contained earlier in this thread, however if you still want to buy the book head to maxpowerfirewalls.com to look at the different PDF and/or hardcopy purchase options.

[Yuvy_Ruhee]

Just bought the Edition2 of the book and i highly recommend this, specially if you are running R80+, lots if insightful tips covered and best practices

[Timothy_Hall]

To update this old thread, looks like Check Point has now formally documented this many-to-fewer NAT setup here:

sk142833: How to create manual NAT rules in Many-To-Few mode

Also it has been officially confirmed by Check Point in the thread below that Hide NAT can support more than 50k concurrent connections through the same single Hide NAT address, as long as the destination IP addresses are unique.  Never got an answer as to when exactly that changed (I know for a fact that it didn't used to be that way, but that was a VERY long time ago) but I suspect it was version R75:

https://community.checkpoint.com/message/32343 

--

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30

[Bill_Ng]

Hi Tim,

Does the NAT space have to be contiguous IP space?  Could a network group be used with non contiguous IP space?

[Timothy_Hall]

It has to be an IP Range object so by definition the addresses will have to be contiguous, at least in a single NAT Rule.  Trying to use a network object will cause a policy verification error; I'm pretty sure you are not allowed to use a group either.  Only one manual NAT rule can be matched for a particular connection, so unless you break up your internal networks as the source into multiple manual NAT rules I don't see how you could use non-contiguous ranges of addresses.

--

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30