> Source: [sk116861](https://support.checkpoint.com/results/sk/sk116861) # sk116861 - Policy installation fails with "SIC General Failure [ SIC error no. 148 ]" error | Property | Value | |----------|-------| | Solution ID | sk116861 | | Date Created | 2017-04-13 | | Last Modified | 2024-05-06 | | Technical Level | General | | Products | Security Gateway, Spark Firewall (Locally Managed), Scalable Platforms | | Versions | R82.10, R82, R81.20, R82.00.X, R81.10.X, R82, R81.20 | | OS | Gaia | ## Solution ### Introduction This article describes different scenarios when security policy installation fails with the "`SIC General Failure [ SIC error no. 148 ]`" error. Each Scenario has its own cause and solution. See the Table of Contents below. **Table of Contents:** 1. Policy Installation fails with the "`SIC General Failure [ SIC error no. 148 ]`" error. 2. In Load Sharing mode, a ClusterXL member is shown as '*Disconnected* ' in SmartView Monitor, and policy installation fails on that cluster member with the *"* `[ SIC error no. 148 ]`" error. 3. Policy installation on an SMB appliance fails with the "`SIC General Failure [ SIC error no. 148 ]`" error. 4. CPD process on a Security Gateway consumes CPU at a high level due to low value of "`Status Checking Interval`" defined in SmartDomain Manager. 5. The *sfwd* and *fw_worker* processes on an SMB appliance consume CPU at a high level. 6. Policy installation on a 60000 / 40000 chassis fails with the "`SIC General Failure [ SIC error no. 148 ]`" error. 7. CPD process crashes on a Security Gateway, and policy installation fails with the "`SIC General Failure [ SIC error no. 148 ]`" error.
Show the Entire Article
This error means a timeout has occurred during the SIC process. First, follow these steps: 1. Check the physical connectivity between the Security Management server and Security Gateway. 2. Correct any issue in communication between the Security Management server and Security Gateway. 3. Test SIC again. If policy installation succeeds, then the problem lies with the Policy and not with SIC. If policy installation fails again, continue to the scenarios. ### 1. Policy Installation fails with "`SIC General Failure [ SIC error no. 148 ]`" error. {#Scenario 1} **Symptoms:** * Policy Installation fails with "SIC General Failure \[ SIC error no. 148 \]" error message. * The *$CPDIR/log/cpd.elg* file shows these error messages: "`add_mgmt_addrs_pool_from_cpobj: failed to get DB from cpobj`" "`build_mgmt_addrs_pool: failed to get interfaces from objects.C will try umis_objects.C`" Show / Hide solution **Cause:** SIC Communication with the Security Gateway is unstable. **Solution:** > Perform a SIC Reset per [sk65764](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65764). ### 2. In Load Sharing mode, SmartView Monitor shows a ClusterXL member as '*Disconnected* ', and policy installation fails on that cluster member with the "\[ *SIC error no. 148* \]" {#Scenario 2} **Symptoms:** * ClusterXL works correctly in High Availability mode, but these symptoms appear in Load Sharing mode for the last member that joined the cluster: 1. Cluster member appears as '*Disconnected*' in SmartView Monitor. 2. Policy installation in SmartDashboard intermittently fails on that cluster member with `"`*SIC General Failure [ SIC error no. 148 ]*`"` message (which appears as **Disconnected**in SmartView Monitor). Show / Hide solution **Cause:**Internal 'Hide NAT' settings in the cluster object are incorrect. This can happen, for example, during cluster OS migration. **Solution:** Rarely, the properties of the cluster object (stored in the *$FWDIR/conf/objects_5_0.C* file) are set incorrectly either by SmartDashboard, or during the upgrade. Follow these steps to correct the internal **Hide NAT** setting in the cluster object, and to stabilize the communication between cluster members: 1. Go to **SmartDashboard** \> **Cluster object** \> **Properties** : 1. In the left pane, in **General Properties** uncheck the box **ClusterXL** . In the list of Products / Blades, the third option in the left pane changes from **ClusterXL** to **3rd Party Configuration** . 2. In the left pane, in **3rd Party Configuration** uncheck the box **Hide Cluster Members' outgoing traffic behind the Cluster's IP Address** . 3. In the left pane, in **General Properties** check the box **ClusterXL** in the list of Products / Blades. The third option in the left pane changes from **3rd Party Configuration** to **ClusterXL** . 4. Click **OK** to close the Properties window. 5. Go to the **File** menu and click **Save** to save all changes. 6. Install the policy on the cluster object.

2. Check Point software relies on the */etc/hosts* file. Edit this file on all cluster members per [sk42952 - Configuring /etc/hosts on cluster members](http://supportcontent.checkpoint.com/solutions?id=sk42952). ### 3. Policy installation on an SMB appliance fails with the "SIC General Failure \[ SIC error no. 148 \]" error {#Scenario 3} **Symptoms:** * Policy installation on Centrally Managed SMB appliance fails with these error messages: *"* `SIC Status for : Not Communicating`*" "* `SIC General Failure [ SIC error no. 148 ]`*"* * After SIC is reset, policy installation from the Management succeeds, but only once - all additional policy installations fail. * Policy fetch from the SMB appliance WebUI always succeeds. Show / Hide solution **Solution:** > To solve the problem, configure the SMB appliance to point to the internal DNS server. Run this command: > > `set dns primary ipv4-address ` > > For more information about the command, see [Check Point 600, 1100, and 1200R Appliance CLI Guide](http://supportcontent.checkpoint.com/documentation_download?id=41405) > >
> > In addition, the DNS server can be configured in the SMB appliance's WebUI -\> "Device" tab -\> "DNS" pane. > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk105736/DNS1506210049.png) ### 4. CPD process on a Security Gateway consumes CPU at a high level due to low value of "Status Checking Interval" defined in SmartDomain Manager {#Scenario 4} **Symptoms:** * Policy installation onto Security Gateway / Cluster fails with "`SIC General failure [error no. 148]`" error. * The*Test SIC Status*command in Security Gateway / cluster member object succeeds and fails randomly. * Output of the *top* command on Security Gateway / cluster member shows that CPD process consumes CPU at high level. Show / Hide solution **Cause:** The **Status Checking Interval**in the SmartDomain Manager GUI was set to a very low value. This causes the Multi-Domain Management server to send too many status requests for each managed Security Gateway / cluster member / Virtual System. These multiple status requests cause high CPU utilization by the CPD process on Security Gateway / cluster member. **Solution:** > Set the **Status Checking Interval** in the SmartDomain Manager GUI to a higher value: > > The default status collection cycle takes 300 seconds, i.e. each system entity is monitored once every 5 minutes. This value can be changed per Multi-Domain Server in the SmartDomain Manager: > > 1. Connect with SmartDomain Manager GUI to Multi-Domain Security Management Server. > > 2. Click on the **General** tab. > > 3. Click on the **Multi-Domain Server Contents** . > > 4. Double-click on the involved a Multi-Domain Server. > The **Multi-Domain Server Configuration** window opens. > > 5. Click on the **Additional Information** tab. > > 6. In the **Status Checking Interval** field, set the desired value. > > Notes: > * This value is effective immediately, with no need to restart the Multi-Domain Server. The higher you raise this value, the longer it takes to detect a change in a Security Gateway status. > * This value is saved in the *$MDSDIR/tmp/status_interval.dat* file. > >
> >
> > 7. Click **OK**. > > Refer to *Multi-Domain Security Management Administration Guide* ([R75.40](http://supportcontent.checkpoint.com/documentation_download?id=13950), [R75.40VS](http://supportcontent.checkpoint.com/documentation_download?id=16201), [R76](http://supportcontent.checkpoint.com/documentation_download?id=22916), [R77](http://supportcontent.checkpoint.com/documentation_download?id=24807), [R80](https://sc1.checkpoint.com/documents/R80/CP_R80_MultiDomainSecurity/html_frameset.htm), [R80.10](https://sc1.checkpoint.com/documents/R80.10/WebAdminGuides/EN/CP_R80.10_Multi-DomainSecurityManagement_AdminGuide/html_frameset.htm), [R80.20](https://sc1.checkpoint.com/documents/R80.20_GA/WebAdminGuides/EN/CP_R80.20_Multi-DomainSecurityManagement_AdminGuide/html_frameset.htm), [R80.20.M2](https://sc1.checkpoint.com/documents/R80.20.M2/WebAdminGuides/EN/CP_R80.20_M2_Multi-DomainSecurityManagement_AdminGuide/html_frameset.htm), [R81](https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Multi-DomainSecurityManagement_AdminGuide/Default.htm) ). ### 5. The *sfwd* and *fw_worker* processes on an SMB appliance consume CPU at a high level {#Scenario 5} **Symptoms:** * The *sfwd* and *fw_worke*r processes on an SMB appliance consume CPU at a high level when this SMB appliance participates in a VPN community as a Satellite Gateway. * Connectivity issues from Management Server to the SMB appliance ("*SIC General Failure [ SIC error no. 148 ]*" message during policy installation). * Many *ghost* static routes through the WAN port are seen on the SMB appliance. * Running `cpstop ; cpstart` commands on the SMB appliance resolves the SIC issue and CPU issue temporarily. Show / Hide solution **Cause:**RIM is configured on the SMB appliance. This configuration is not supported by Gaia Embedded OS. **Solution:** Disable RIM in the VPN community: > 1. In the SmartDashboard, go to the **IPSec VPN** tab > 2. Go to **VPN communities** and open the specific VPN Community object. > 3. Go to **Tunnel Management**. > 4. Disable RIM (on the satellites in case of a Star community or the whole community). > 5. Install policy to all involved Security Gateways. > 6. Verify CPU usage is back to normal. ### 6. Policy installation on a 60000 / 40000 chassis fails with the "*SIC General Failure \[ SIC error no. 148 \]*" error {#Scenario 6} **Symptoms:** * Policy installation on a 60000 / 40000 chassis fails with the "*SIC General Failure \[ SIC error no. 148 \]* " error. * Traffic capture (on the 60000 / 40000 chassis / Management Server) shows that communication between the 60000 / 40000 chassis and Security Management Server is closed after 35 seconds. * Debug of the FWM daemon (per [sk86186](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk86186) / [sk33207](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk33207)) on the Security Management Server shows: ``` fwasync_do_end_conn: closing connection 15 (conn=...) sic_client_end_handler: for conn id = 15 opsec_auth_client_connected: connect failed (148) opsec_auth_client_connected: SIC Error for InstallPolicy: timeout elapsed during authentication protocol. OPSEC_SET_ERRNO: err = 8 Comm is not connected/Unable to connect (pre = 0) ``` * Debug of CPD daemon (per [sk86320](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk86320)) on the 60000 / 40000 chassis does not show any policy installation attempt. * Additional policy installation attempt succeeds. Show / Hide solution **Issue**: 02447818 , 02488076 **Solution:** > This problem was fixed. The fix is included in: > > * [Data Center Security Appliances R76SP.30 - Jumbo Hotfix Accumulator - Take 66.](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk108901) > > Check Point recommends to always upgrade to the most recent version. ### 7. CPD process crashes on the Security Gateway, and policy installation fails with the "SIC General Failure \[ SIC error no. 148 \]" error {#Scenario 7} **Symptoms:** * Policy installation fails with the error "`SIC General Failure [ SIC error no. 148 ]`". * The CPD process is crashing on the Security Gateway / VSX Virtual System. To examine this, run: `cpwd_admin list | grep -i cpd | grep ' T '` * Starting the CPD daemon in the debug mode on the Security Gateway shows these lines in the *$CPDIR/log/cpd.elg* file: ` [CPD ]@[