Hi all!
In one of my previous posts I have mentioned some troubles concerning R70 to R75 upgrade, blaming (together with CP support engineers) IPS database.
In fact the issue was related to something completely different. The customer has had a time object, like one on the picture.
As you can see, the second, not the first "Restrict" checkbox is enabled. If the first checkbox is not marked, this object causes policy compilation failure on R75. Mind it was working just fine on R70.
This is a professional blog of Check Point Certified Master Architect (CCMA). It does not represent position of my current employer.
Tuesday, January 31, 2012
Friday, January 20, 2012
UTM 27x HD free space upgrade issue
I have performed R75.10 to R75.20 upgrade on UTM 27x yesterday for one of my customers. It was not smooth.
The customer has a "classic" UTM cluster: both MGMT HA and FW ClusterXL HA are configured.
The upgrade went smooth on the secondary node, but failed on the primary one.
Short troubleshooting has shown it failed because of lack of free space on the main partition. I have mentined several disturbing issues:
1. HD space is apparently not monitored.
Root partition only contains binaries and configuration files. On this particular system HD is partitioned to provide around 10 GB for root partition and around 80 GB for /var/opt/log one. In our case root was used for at least 70%, and in the middle of DB conversion it jumped to 100%. Apparently you should have this partition used for not more then 50-60% to succeed with upgrade to R75.20. It does not seem that the upgrade script monitors this particular part of the hard drive at all.
2. Upgrade script does report cause of the failure.
The appliance can only be upgraded via WebUI. You cannot even un-cjeck safe upgrade option. If failed, it automatically reverts to the pre-upgrade image, and there are no logs left to see what went wrong.
This issue is quite similar to IPSO flash based upgrade troubles, which is bad considering that IPSO usually fails an upgrade with 1 GB flash but succeeds with 2 GB. Come one, Check Point, how comes you need 3-4 GB of free space on the main partition to upgrade a standalone UTM system? That should not be right.
The customer has a "classic" UTM cluster: both MGMT HA and FW ClusterXL HA are configured.
The upgrade went smooth on the secondary node, but failed on the primary one.
Short troubleshooting has shown it failed because of lack of free space on the main partition. I have mentined several disturbing issues:
1. HD space is apparently not monitored.
Root partition only contains binaries and configuration files. On this particular system HD is partitioned to provide around 10 GB for root partition and around 80 GB for /var/opt/log one. In our case root was used for at least 70%, and in the middle of DB conversion it jumped to 100%. Apparently you should have this partition used for not more then 50-60% to succeed with upgrade to R75.20. It does not seem that the upgrade script monitors this particular part of the hard drive at all.
2. Upgrade script does report cause of the failure.
The appliance can only be upgraded via WebUI. You cannot even un-cjeck safe upgrade option. If failed, it automatically reverts to the pre-upgrade image, and there are no logs left to see what went wrong.
This issue is quite similar to IPSO flash based upgrade troubles, which is bad considering that IPSO usually fails an upgrade with 1 GB flash but succeeds with 2 GB. Come one, Check Point, how comes you need 3-4 GB of free space on the main partition to upgrade a standalone UTM system? That should not be right.
Tuesday, January 17, 2012
Riddle: Check Point User Group, but not CPUG
I have came across a quite interesting Check Point event: Check Point User Group gathering in Omaha.
Considering CPUG to Check Point relations do not exist, I hardly believe this event to be related to CPUG at all.
The question is whether Barry ownes the name "Check Point User Group". I sure think Check Point does not.
What do you say?
Update: Barry tells me he only own CPUG trademark, but not "Check Point User Group", so case is closed.
Considering CPUG to Check Point relations do not exist, I hardly believe this event to be related to CPUG at all.
Update: Barry tells me he only own CPUG trademark, but not "Check Point User Group", so case is closed.
Monday, January 16, 2012
R7x to R75 upgrade - policy compilation issue
I have written already about some issues concerning upgrade and/or migration to R7x.
It is time to mention even more of them.
If you are upgrade or migrate your R65, R70 or R71 MGMT station to R75, brace yourself. In many cases you will not be able to compile policy anymore. The issue is related to incorrect handling of IPS configuration files.
Symptoms: you will get at least one of the error messages bellow:
Sometimes policy compilation fails for existing FWs with "old" versions, R65, R70 or R71. In other situations the problem only surfaces when you lift your FWs to R75. To be absolutely sure your upgrade went well, and you do not have the described symptoms, create a dummy FW object with the target software version and try to push policy on it. If it fails on connectivity, you are the lucky one.
To fix the situation, according to SK61326, you will have to open a support request. Support engineer will provide you with "proper" files. You will then have to replace them manually, one by one.
Now, imagine you have this issue over multiple CMAs in Multi-Domain environment...
It is time to mention even more of them.
If you are upgrade or migrate your R65, R70 or R71 MGMT station to R75, brace yourself. In many cases you will not be able to compile policy anymore. The issue is related to incorrect handling of IPS configuration files.
Symptoms: you will get at least one of the error messages bellow:
- The Converter failed to convert policy. Possibly wrong policy name. Policy_Name
- INTERNAL ERROR in execval: optimization disabled: displacement too large
- ERROR: function undefined Network Security cpp: line Line_Number Error: Redefining defined variable 'ADP_ENABLE_SLAMMER_PROT' /opt/CPNGXCMP-R7X/conf/updates.def
Sometimes policy compilation fails for existing FWs with "old" versions, R65, R70 or R71. In other situations the problem only surfaces when you lift your FWs to R75. To be absolutely sure your upgrade went well, and you do not have the described symptoms, create a dummy FW object with the target software version and try to push policy on it. If it fails on connectivity, you are the lucky one.
To fix the situation, according to SK61326, you will have to open a support request. Support engineer will provide you with "proper" files. You will then have to replace them manually, one by one.
Now, imagine you have this issue over multiple CMAs in Multi-Domain environment...
Tuesday, January 10, 2012
Client Authentication on VSX with SSL support
If you ever want to enable Client Authentication on VSX with SSL support, here are some tips for you.
First, read carefully SK37001 and How-To-Install-3rd-party-SSL-Certificate.pdf document from Check Point support site.
You will have to modify cpauthd.conf in order to enable SSL-based client authentication. Mind in VSX environment you can do it either globally (for all Virtual System at once) or per VS. The last on is the recommended way. The file is located in $FWDIR/CTX/CTX00xxx/conf/ folder, where xxx is VS ID.
Change file configuration as marked in underlined bold bellow:
---
:clauth_port (259)
:clauth_http_port (443) << change listening port
:clauth_http_ssl (1) << enable SSL
:clauth_http_wap (0)
:clauth_http_nickname (Your certificate Nickname) << put third party certificate
---
Mind you will have to prepare a third party certificate to use. Some CAs, such as Verisign do not accept default Check Point CSR. You will have to increase the key size to at least 2048. To do that go to Global properties / SmartDashboard Customization / Advanced Configuration and change host_certs_key_size parameter to the required number.
Do not forget to install the certificate on VS as described in "How to" document.
All mentioned changes will be in effect after reboot of your VSX boxes.
First, read carefully SK37001 and How-To-Install-3rd-party-SSL-Certificate.pdf document from Check Point support site.
You will have to modify cpauthd.conf in order to enable SSL-based client authentication. Mind in VSX environment you can do it either globally (for all Virtual System at once) or per VS. The last on is the recommended way. The file is located in $FWDIR/CTX/CTX00xxx/conf/ folder, where xxx is VS ID.
Change file configuration as marked in underlined bold bellow:
---
:clauth_port (259)
:clauth_http_port (443) << change listening port
:clauth_http_ssl (1) << enable SSL
:clauth_http_wap (0)
:clauth_http_nickname (Your certificate Nickname) << put third party certificate
---
Mind you will have to prepare a third party certificate to use. Some CAs, such as Verisign do not accept default Check Point CSR. You will have to increase the key size to at least 2048. To do that go to Global properties / SmartDashboard Customization / Advanced Configuration and change host_certs_key_size parameter to the required number.
Do not forget to install the certificate on VS as described in "How to" document.
All mentioned changes will be in effect after reboot of your VSX boxes.
Wednesday, January 4, 2012
Software Blade training sessions in my ATC
I am happy to announce that Check Point is providing two training session in Dimension Data's ATC in Lausanne: 13.02 to 15.02 and 15.02 to 17.02.
Quoting the official Check Point announce:
Training is delivered using our new, cutting-edge Training Blades and includes:
Quoting the official Check Point announce:
Training is delivered using our new, cutting-edge Training Blades and includes:
- In-depth study of Check Point Application Control, Identity Awareness, URL Filtering, DLP and IPS Software Blades
- Hands-on lab exercises based on real life scenarios and support cases
- Exams that extend your Check Point certification by another year
You are welcome to attend, it is only $200 for two and a half days of training and exams!
Subscribe to:
Posts (Atom)