In my previous post I have explained why one needs just a single SGM in the Security Group while defining VSX object.
The second pitfall is about control connections during provisioning. When converting GW to VSX, management server pushes an automatically compiled policy to the GW before and after conversion. Users have some limited options to add to that policy, mostly about HTTPS, SSH and SNMP connectivity to the gateway. Control connections are not explicitly mentioned.
It is assumed that control connections are allowed by Global Policy settings in the implied rules. On the field this assumption does not really work. If a customer disabled control connections, the auto-generated VSX policy will cut of provisioning after the first push.
It would be very unwise to try unloading policy on the gateway. In this case it will be converted to VSX, rebooted, and then the same auto-compiled policy will be pushed again, cutting VSX GW out of MGMT server the second time, now for good.
In any case you will be stuck in the middle of provisioning, with VSX object created on the MGMT side, with SGM side provisioning either not started or only partially completed.
If that would be R77 VSX environment, you should be able to run reset_gw command, described in SK101690. Unfortunately, 61/41K VSX deployment is using R76.x0 SP versions, where this command is not available.
In this particular situation you will have to re-image your SMO SGM again. If so, do not forget to reapply Jumbo hotfix package after installing the main version.
So, the bottomline here is: before starting VSX provisioning in general, and especially when dealing with 61/41K chassis, make sure you re-enable, even temporarily, control connections, before starting VSX object creation.
I can only imagine why Check Point assumes that control connections are always enabled by default, especially in case of complex security systems where it is mostly not the case. I hope in the future releases Check Point will be able to take this issue into consideration and will at least add a warning to VSX wizard or, better, allow administrators to modify default VSX object policy to some extend.
Some additional info about 41/61K deployment to follow.
-------
To support this blog and Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets
The second pitfall is about control connections during provisioning. When converting GW to VSX, management server pushes an automatically compiled policy to the GW before and after conversion. Users have some limited options to add to that policy, mostly about HTTPS, SSH and SNMP connectivity to the gateway. Control connections are not explicitly mentioned.
It is assumed that control connections are allowed by Global Policy settings in the implied rules. On the field this assumption does not really work. If a customer disabled control connections, the auto-generated VSX policy will cut of provisioning after the first push.
It would be very unwise to try unloading policy on the gateway. In this case it will be converted to VSX, rebooted, and then the same auto-compiled policy will be pushed again, cutting VSX GW out of MGMT server the second time, now for good.
In any case you will be stuck in the middle of provisioning, with VSX object created on the MGMT side, with SGM side provisioning either not started or only partially completed.
If that would be R77 VSX environment, you should be able to run reset_gw command, described in SK101690. Unfortunately, 61/41K VSX deployment is using R76.x0 SP versions, where this command is not available.
In this particular situation you will have to re-image your SMO SGM again. If so, do not forget to reapply Jumbo hotfix package after installing the main version.
So, the bottomline here is: before starting VSX provisioning in general, and especially when dealing with 61/41K chassis, make sure you re-enable, even temporarily, control connections, before starting VSX object creation.
I can only imagine why Check Point assumes that control connections are always enabled by default, especially in case of complex security systems where it is mostly not the case. I hope in the future releases Check Point will be able to take this issue into consideration and will at least add a warning to VSX wizard or, better, allow administrators to modify default VSX object policy to some extend.
Some additional info about 41/61K deployment to follow.
-------
To support this blog and Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets
No comments:
Post a Comment