- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
hi guys
quick one
I've got a MTO customer who due to the migration process is required to provide following data:
1. NAT usage/utilisation on each of the DC firewalls (4000/5000 series of HA's) - bear in mind that NAT rules are per-gateway.
2. NAT differentiations (Machine NAT, Network NAT, Static NAT, Hide NAT etc.)
Question:
how they can get that information by the most convinient way from the Gateways (SMS) should they NOT have CPVIEW capability on R80.40 which shows lots on Advance tab, should they have expert/admin access to each device but so much decapacitated due to the age of the Gaia build? All they need is the stats of the usage of their NAT policies (there is roughly around 150-200 NAT policies only with mixture mentioned above.
T.files - yes, but in HEX - any other clues?
Any hints? They'd much appreciate it.
Cheers
I assume the reason cpview doesn’t show information in versions prior to R81 is because the infrastructure to track NAT rule utilization simply doesn’t exist in earlier versions.
The only other way to do this is analyzing the logs, which has its own issues.
You can try poking around in the NAT cache to get some idea of the most commonly hit NAT rules. This was mentioned in my Max Power book which was written before the extra NAT cpview screens were added:
-
hi
yes I know that FAQ and there is nothing related to my topic I'm afraid, did you understand what my customer is after?
There are no issues with NAT except ... CP Build - R80.40 (as this cannot be upgraded at this time) hence our hands are tight as we do not have much tools (including CCC) which shows NAT rules utilisation. None of the links you've provided leads to any conclusions though nor to any useful information sorry. Am I blind then or I'm missing something here?
-
CPVIEW by R80.40 does not show NAT at all hence my reiteration on that. Due to this missing bit (it isn't there simply until R81) they've got no other option to see utilisation/usage of their NAT rules. FAQ has nothing to do with it as PORT USAGE is not what I was asking about.
-
NAT:
2376649/0 forw, 2897027/0 bckw, 69484456 tcpudp,
340322 icmp, 32985755-16777499 alloc
*** not really of use so much ***
-
is that seriously R80.40? it seems to me that this isn't really that one, instead R81. See Dameon's post here. There was no facilty in CPVIEW code to gather NAT's in Adcance-NAT pattern.
-
Perhaps it’s related to the JHF level.
Having said that, there’s no obvious mention in the R80.40 JHF notes
-
All lovely but unfortunately still it does not help my Customer who by running R80.40 cannot effectively assess which of their NAT rules should be considered as priority for the MTO.
As a unlucky factor they also noted that by not using any 3rd party policies orchestartion nor any SIEM they've shoot themselves in the foot now when the time has come for the MTO preparations and migartions off CP. They plan to eliminate "anything CP" within the next year as most of their stuff runs out of support and many are already EOL H/W wise so I believe you can guess which vendor they decided to go for instead hence now the priority is to assess whatever possible (on gaia, smartconsole) and take this forward with us (MSP) towards another architecture.
shame we cannot assess other than by the logs, which NAT rules are used and/or completely unused.
any hints/tips highly welcomed as always chaps.
I assume the reason cpview doesn’t show information in versions prior to R81 is because the infrastructure to track NAT rule utilization simply doesn’t exist in earlier versions.
The only other way to do this is analyzing the logs, which has its own issues.
-
nobody will risk an upgrade process on already outdated H/W so knowing that R80.40 is the latest supported build for their 4000/5000 gear would make no sense I'm afirad 😞
-
I do read english and have no issues with that mate 🙂 I'm happy you've corrected your post so quickly but emails shows your complete ignorance of the fact that I have wrote above one little line: "nobody will risk an upgrade process" - that INCLUDE take/jhf install. so now who's english lacks? 😛
anyway, that's not the place for arguments hence I was hoping I'm making myself clear enough, looks like many bi-lingual ppl here still struggle, fair enough so let's make sure we're on the same page.
Customer is not willing to touch their builds just to see NAT page on CPVIEW. Period.
Hope that this is indeed clarified 4ever now.
Reg. the issue itself - I presume R80.40 JHF 139 as it stands does NOT support NAT details by CPVIEW. Am I correct?
@Jerry & @G_W_Albrecht, please refrain from personal attacks in this forum. We expect all the members to behave professionally.
Thanks,
admin team
hi Val, ABSOLUTELY AGREE, I never ever intend to do anything like that but unfortunatelly I've just defended myself. It's not me who started, see below:
Please stop, both of you. Or else 🙂
You can try poking around in the NAT cache to get some idea of the most commonly hit NAT rules. This was mentioned in my Max Power book which was written before the extra NAT cpview screens were added:
Grand Tim! That's the answer I was waiting for 🙂 excellent and spot on!
Much appreciate it, we'll give it a try with the Customer and update you all due course,
Cheers and thanks to all!
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
19 | |
12 | |
8 | |
7 | |
6 | |
6 | |
6 | |
4 | |
4 | |
3 |
Tue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasTue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY