About the SK69480

[Jones_Jardel_Po]

Hello guys!

I would like to discuss with you about some ways to prevent the scenario below:

'NAT Hide failure - there are currently no available ports for hide operation' log appears repeatedly in SmartView Tracker - SK69480

Well, I have here two security gateways running with SecureXL and CoreXL (only 2 cores) enabled and having more than 30K concurrent connection from my internal network (many different sources) to the same external IP address performing the same NAT and using a lot of my static or dynamic (I already tested it) NAT ports available and having the message above many times during the day, causing packet dropping and problems with the users.

I was reading the performance tunning for R77 - Admin Guide and other non-Check Point papers about the SecureXL NAT template and it seems to not be a good road to get to help me on this scenario....

What is the best way to increase the number of high ports to use on NAT scenarios?

Besides to set the NAT_limit to 0 (unlimited) sk36708 do we have another way to solve this?

Thank you guys!

[PhoneBoy]

There is going to be an upper limit no matter what you do.

This is because you are doing a "many to one" NAT.

The way this is disambiguated is source port, and there are only so many of those (65535, of which the system needs to use some as well).

If you can allocate more than one public HIDE NAT IP, this should mitigate the issue.

You would allocate a specific public address to specific networks in your environment (i.e. multiple HIDE NAT rules).

If you only have one public IP available for this purpose, then there's really not much you can do.

[Kaspars_Zibarts]

Have you seen this SK 103656? Dynamic NAT port allocation feature 

Also, in case of only one public IP available, you may play around with TCP/UDP session timeouts depending on what service you are running to this destination. Assuming it's HTTP/S, reduce timeouts to absolute minimum just for this one connection (create special dedicated HTTP/S service), say to 5-10 mins. This way you might kill any "zombie" sessions faster and have less concurrent connections.