Check Point listens, guys.
One of the most demanded features for years was an ability to migrate Provider-1 systems not only between different pieces of hardware but also between OS platforms.
It became quite hot when decent SPLAT was out. Once upon a time it was only possible with CMA migration. It was a painful and long procedure. And you could not do this if you had VSX managed.
This is not the case anymore. With new Multi-domain systems of R7x you can do it fast and easy.
First, insert Provider-1 target version installation CD to your MDS. Mount cdrom and go to linux folder on it. Run the usual mds_setup script from there.
You will have 4 options, and the last one is to export your existing MDS configuration. Choose it and continue. As a result you will get MDS export file.
On the target machine install the desired version from the CD. Pre-configure it as required (Primary MDS, etc).
Copy the export file to it.
To import go to $MDSDIR/system/install and run mds_import script from there pointing to your export file.
Say, your export file is placed in /var/tmp and called export_mds_12345.tgz. Then your import command will look ./mds_import /var/tmp/export_mds_12345.tgz.
The script will re-build your MDS on the new machine and will upgrade database, if necessary.
In about ten to twenty minutes you will have new migrated and upgraded system. No more mds_backup and mds_restore hassle, no more upgrade in place and disk space wasted by old versions. You can easily use it with VSX, you can finally change your old Solaris MDS to a shiny new SPLAT box without spending 10 days migrating CMAs with stopped production management operations.
Hooray! Check Point, thanks a lot!
Tuesday, May 31, 2011
Friday, May 27, 2011
Mobile Access Software Blade platform support
I am regulary getting the same question from my sales: "Can one add Mobile Access Software Blade functionality on IP appliance?"
The answer is:
No, Mobile Access is only supported on Secure Platform. It means it is applicable to UTM-1, Power-1 and open server based systems, but not to IPSO based ones.
You can find the answer on Check Point site, under Specification tab.
The answer is:
No, Mobile Access is only supported on Secure Platform. It means it is applicable to UTM-1, Power-1 and open server based systems, but not to IPSO based ones.
You can find the answer on Check Point site, under Specification tab.
Thursday, May 19, 2011
R65.4 is still dead end
As you may mentioned already, R75.10 is recently released.
There were some hopes on the field that this release would unblock some dead end upgrade paths for versions such as R65.4 and R71.30.
That did not happen. There is no direct upgrade to R75.10 from any version bellow R75. You can check out the updated upgrade diagram from fileserve.org here.
It means that someone having R65.4 is still blocked.
This is quite painful considering R65 is out of support for some time now. Check Point, what's going on?
There were some hopes on the field that this release would unblock some dead end upgrade paths for versions such as R65.4 and R71.30.
That did not happen. There is no direct upgrade to R75.10 from any version bellow R75. You can check out the updated upgrade diagram from fileserve.org here.
It means that someone having R65.4 is still blocked.
This is quite painful considering R65 is out of support for some time now. Check Point, what's going on?
Wednesday, May 18, 2011
Migration problems with SmartMap, R75
I have encountered today an interesting problem while migrating MGMT server from R65 to R75 Smart-1 appliance.
The customer has enormous network setup with lots and lot different subnets. He has had SmartMap disabled on R65, but after migration to R75 it is enabled again. As a result, we just could not start SmartDashboard, it was taking forever to build SmartMap on the GUI client machine.
There is a quick and dirty solution for that. Instead of starting with SmartDashboard, you can open GUIDBEdit. Find there totally_disable_VPE parameter and set it to true. That will disable SmartMap on the client side.
I have found this on CPUG in this discussion. Well done, guys!
The customer has enormous network setup with lots and lot different subnets. He has had SmartMap disabled on R65, but after migration to R75 it is enabled again. As a result, we just could not start SmartDashboard, it was taking forever to build SmartMap on the GUI client machine.
There is a quick and dirty solution for that. Instead of starting with SmartDashboard, you can open GUIDBEdit. Find there totally_disable_VPE parameter and set it to true. That will disable SmartMap on the client side.
I have found this on CPUG in this discussion. Well done, guys!
Tuesday, May 17, 2011
SmartSPLAT - new release is available
One more follow-up post.
SmartSPLAT utility that I was recommending in March has a new release, 4.0. There are lots of improvements.
Check it out here.
SmartSPLAT utility that I was recommending in March has a new release, 4.0. There are lots of improvements.
Check it out here.
CCMA's requirements - CCMSE is not one of them
In January this year I have posted some info about CCMA prerequisites. I have mentioned there that CCMSE was a new requirement before taking CCMA certification.
This information was based on official Check Point statement of that time. Since then some things changed. In particular, Check Point lifted CCMSE prerequisite.
For the record, you do not have to have active CCMSE status to start CCMA certification. It is back to the way it was originally designed.
This information was based on official Check Point statement of that time. Since then some things changed. In particular, Check Point lifted CCMSE prerequisite.
For the record, you do not have to have active CCMSE status to start CCMA certification. It is back to the way it was originally designed.
Tuesday, May 10, 2011
Mystery of propagated static routes on VSX (solved)
Two last weeks I was dealing with an unpleasant case where VSX customer of mine could not provision some changes on VSX cluster.
The issue seemed to be MGMT DB corruption. There were some "wrong" static routes propagated to iVR and eVR from a Virtual System. The funny part was that these routes were not defined on VS itself, at least that what we thought at the beginning.
We have tried to adjust DB manually, to remove warp links, etc. Nothing helped. As soon as we have touched the VS in question, all these deleted routes were back on VRs again.
It was absolutely weird, because we could not find any reference for propagated networks in any of MGMT databases, neither on Main CMA, nor on Target one.
Finally when playing with the system we have mentioned that system is pushing new static routes to VRs if VS NAT Addresses definition is touched.
Here is the deal. If VS is connected to VR and has some static NAT rules, to make them work you can define explicit static routes on VS and then propagate them to adjacent VRs to make NAT work. On physical system a similar case would be to create static APR entries on an adjacent router to point it to FW.
On VSX there is a better way to make the same. If you go to VS topology tab, there is "NAT Addresses" button just bellow static routes table. If you press the button, you can add all static NAT IP addresses there. Once you are done, the system will calculate the closest IP network to cover the defined IP addresses and then will propagate this network static route to VRs.
That was our problem. Someone put there some IP addresses but then decided to go on with explicit static routes instead. There were two conflicting static routes, on explicitly defined, the other one manually added on VS and propagated. Provisioning did not catch an error, but VSX behavior after both routes were getting there was... well.. was not ideal.
Check Point PS engineer involved in the resolution has promised to add a new SK entry for the matter.
The issue seemed to be MGMT DB corruption. There were some "wrong" static routes propagated to iVR and eVR from a Virtual System. The funny part was that these routes were not defined on VS itself, at least that what we thought at the beginning.
We have tried to adjust DB manually, to remove warp links, etc. Nothing helped. As soon as we have touched the VS in question, all these deleted routes were back on VRs again.
It was absolutely weird, because we could not find any reference for propagated networks in any of MGMT databases, neither on Main CMA, nor on Target one.
Finally when playing with the system we have mentioned that system is pushing new static routes to VRs if VS NAT Addresses definition is touched.
Here is the deal. If VS is connected to VR and has some static NAT rules, to make them work you can define explicit static routes on VS and then propagate them to adjacent VRs to make NAT work. On physical system a similar case would be to create static APR entries on an adjacent router to point it to FW.
On VSX there is a better way to make the same. If you go to VS topology tab, there is "NAT Addresses" button just bellow static routes table. If you press the button, you can add all static NAT IP addresses there. Once you are done, the system will calculate the closest IP network to cover the defined IP addresses and then will propagate this network static route to VRs.
That was our problem. Someone put there some IP addresses but then decided to go on with explicit static routes instead. There were two conflicting static routes, on explicitly defined, the other one manually added on VS and propagated. Provisioning did not catch an error, but VSX behavior after both routes were getting there was... well.. was not ideal.
Check Point PS engineer involved in the resolution has promised to add a new SK entry for the matter.
Subscribe to:
Posts (Atom)