Issues encountered when upgrading from SecurePlatform to Gaia

When upgrading from SecurePlatform to Gaia, you may encounter a variety of issues. This article discusses a number of the more common issues that we have encountered and dealt with.

Additional important articles and documents include:

• R77 Versions Installation and Upgrade Guide for Gaia Platforms
• sk70260: Upgrade to Gaia: Reference and Known Limitations
• sk70380: Gaia FAQ - Frequently Asked Questions
• sk85500: How to upgrade/migrate Multi-Domain Security Management Server from SecurePlatform OS R75 to Gaia OS R75.40
• sk68140: Migration from SecurePlatform OS to Gaia OS
• sk103083: Member of ClusterXL HA Legacy Mode is Down after upgrading from SecurePlatform OS to Gaia OS
• sk98341: Core dump files are not compressed on Gaia OS after upgrading from SecurePlatform OS

Table of Contents

• Scenario 1: Dynamic Routing configuration is not maintained during upgrade from SecurePlatform to Gaia
• Scenario 2: Configuration created with tools other than sysconfig and Web UI may be lost during upgrade from SecurePlatform to Gaia
• Scenario 3: Configuration loss when Upgrading from SecurePlatform to Gaia+ with PPPoE configured
• Scenario 4: SNMPD crash after upgrade from SecurePlatform to Gaia
• Scenario 5: After an Open Server upgrade from SecurePlatform to Gaia, Gaia Snapshot does not work
• Scenario 6: RADIUS users cannot log in through SSH after upgrade from SecurePlatform to Gaia
• Scenario 7: Failed to create snapshot of system when upgrading machine to Gaia from Gaia (previously upgraded from SecurePlatform)
• Scenario 8: Unable to connect to the Gaia Portal after an upgrade or fresh install
• Scenario 9: Upgrade to Gaia from SecurePlatform fails with error message:"Gated configured cannot proceed with the upgrade exiting"
• Scenario 10: "CLINFR0819 User: admin denied access via CLI" error when trying to log in via CLI after upgrading from R75.40 SecurePlatform to R76 Gaia
• Scenario 11: "Cannot Resolve Name!" error when connecting with SmartDashboard / SmartDomain Manager to Security Management Server / Multi-Domain Security Management Server using the FQDN (hostame) of the Server

Scenario 1

Title: Dynamic Routing configuration is not maintained during upgrade from SecurePlatform to Gaia

Symptoms:

• Upgrade from SecurePlatform to Gaia stops when dynamic routing protocols are defined.
• Dynamic routing protocols configuration is not maintained after an upgrade from SecurePlatform to Gaia

Cause:

The database used in Gaia differs in format from the one used in SecurePlatform. During upgrade, the SecurePlatform configuration is converted into a Gaia database.

An exception to this process is the Dynamic Routing configuration, which is not converted during the upgrade from SecurePlatform to Gaia.

Solution:

The upgrade process will not start as long as Dynamic Routing is enabled on SecurePlatform.

In order to perform the upgrade, follow these steps:

1. Issue the router command on SecurePlatform, and type "show running-config".

2. Copy the resulting output to an external storage.

3. Turn off Dynamic Routing. This can be done by issuing "pro disable".

4. Perform the upgrade to Gaia.

5. Configure the Dynamic Routing protocols using the Gaia Web UI or Clish.

6. More details on Dynamic Routing in Gaia can be found in the Gaia Administration Guide.

If the above solution does not resolve the issue, it will be necessary to delete the following files from the gateway and reboot:

• /etc/gated.ami
• /etc/gated.ami.0
• /etc/gated_xl.ami

---

Scenario 2

Title: Configuration created with tools other than 'sysconfig' and WebUI may be lost during upgrade from SecurePlatform to Gaia

Symptoms:

• After upgrade from SecurePlatform to Gaia, SNMP configuration is not retained.

Cause:

SecurePlatform configuration is done primarily via 'sysconfig' and WebUI. Some advanced configuration, such as for SNMP, can be done by directly manipulating configuration files. Such files are not always upgraded to Gaia. This can cause such advanced configuration to not survive the upgrade.

Solution: Manually configure the missing configuration on Gaia.

---

Scenario 3

Title: Configuration loss when Upgrading from SecurePlatform to Gaia+ with PPPoE configured

Symptoms:

• Configuration related to interfaces and routing is lost when upgrading from SecurePlatform (any version) to Gaia+, if prior to the upgrade, the setup had PPPoE configured.

Cause:

Incorrect conversion of PPPoE configuration from SecurePlatform to Gaia+.

Solution:

To avoid losing interfaces and routing configuration, when upgrading from SecurePlatform to Gaia+, remove any PPPoE configuration prior to the upgrade and re-configure it once the upgrade is completed.

---

Scenario 4

Title: SNMPD crash after upgrade from SecurePlatform to Gaia

Symptoms:

• SNMPD crash after SecurePlatform to Gaia upgrade.

Cause:

There are left over SNMP configuration files from SecurePlatform:

/var/net-snmp/snmpd.conf

/var/lib/net-snmp/snmpd.conf

Solution:

To resolve the issue do the following on the machine that crashed:

1. Rename relevant files:
   EXPERT#mv /var/net-snmp/snmpd.conf /var/net-snmp/snmpd.BAK
   EXPERT#mv /var/lib/net-snmp/snmpd.conf /var/lib/net-snmp/snmpd.BAK
2. Restart SNMP:
   clish#set snmp agent off
   clish#set snmp agent on

---

Scenario 5

Title: After an Open Server upgrade from SecurePlatform to Gaia, Gaia Snapshot does not work

Symptoms:

• Snapshot creation does not work.
• Revert from imported snapshot does not work.
• Errors during snapshot operations from Clish:
  "Snapshot mechanism is not supported in this system".
• Snapshot Management page does not appear in Gaia Portal.

Cause:

Logical Volume Management (LVM) system is enabled on all Gaia installations on all supported Check Point appliances and Open Server machines.

However, SecurePlatform installation on Open Server does not include support for LVM. Adding the LVM support requires formatting of the hard drive disk. As a result, on Open Servers that were upgraded from SecurePlatform to Gaia, the LVM system cannot be added and is not supported.

Solution:

No fix is required; the system is functioning as designed.

The following two options are available:

• On Open Server upgraded from SecurePlatform OS, instead of "Snapshot Management" the user should use "System Backup" in Gaia Portal.
  
  
• Perform clean installation of Gaia OS.

---

Scenario 6

Title: RADIUS users cannot log in through SSH after upgrade from SecurePlatform to Gaia

Symptoms:

• Remote RADIUS users are unable to connect through SSH after upgrade from SecurePlatform to Gaia.
• Error: "User xxx from x.x.x.x not allowed because none of user's groups are listed in AllowGroups".
• Web access works fine.

Cause:

The /etc/ssh/sshd_config file contains the line "AllowGroups root" that is commented out on Gaia.

This restricts the SSH access only to root.

Solution:

To allow the SSH connection, edit the /etc/ssh/sshd_config file and under the AllowGroups section specify the groups you would like to grant access.

Example: AllowGroups root users

Then restart the SSH daemon.

Run: service sshd restart.

Related solution: sk33079 - How to add user without root permission on SecurePlatform and Gaia

---

Scenario 7

Title: Failed to create snapshot of system when upgrading machine to Gaia from Gaia (previously upgraded from SecurePlatform)

Symptoms:

• System snapshot creation during upgrade from Gaia to Gaia is not possible in some circumstances. The upgrade mechanism will not be able to create a snapshot. The user sees the message "Snapshot cannot be created. Logical volume not found".
• Failed to create snapshot of system when upgrading machine to Gaia from Gaia (that had previously been upgraded from SecurePlatform OS).

Cause:

While the Gaia operating system supports the Logical Volume Management (LVM) system on all supported Check Point appliances and Open Server machine installations, SecurePlatform supports it on Check Point appliances only.

Adding LVM support requires formatting the hard drive disk. As a result, the LVM system cannot be added to Gaia, when it is being upgraded from SecurePlatform.

On Gaia systems that were upgraded from SecurePlatform on an Open Server (non Check Point appliances), there is no LVM support.

Solution:

There are several possible solutions for this:

• Instead of in place upgrade, the user can do a clean install of Gaia.
• Use advanced upgrade procedure.
• Instead of snapshot, user can manually take a backup of the system via Clish or Web UI. If after upgrade, he would like to revert to an older version, the user can clean install it, and restore the backed up configuration.

---

Scenario 8

Title: Unable to connect to the Gaia Portal after an upgrade or fresh install

Symptoms:

• Unable to connect to the Gaia Portal after an upgrade from SecurePlatform OS to Gaia OS, or on fresh installation of Gaia OS.
• Output of "ps auxw" command on the problematic Gaia machine shows that httpd2 daemon is not running.

• /var/log/httpd2_error_log file shows:

  [error] (1)Operation not permitted: mod_mime_magic: can^t read magic file /web/conf/magic
[alert] (EAI 3)Temporary failure in name resolution: mod_unique_id: unable to find IPv4 address of "HostName"
Configuration Failed
• The certificate error is displayed but after selecting "continue to this website (not recommended)" the page only displays a white blank page.

Cause:

During the upgrade from SecurePlatform OS to Gaia OS, old hostname.suffix.domain format (used in SecurePlatform OS) was preserved in the /etc/hosts file. Gaia OS (more so, Apache) is looking to resolve the "hostname", without a suffix.

It is also possible that the /tmp directory has improper permissions.

Solution:

Follow these steps:

1. Connect to command line on problematic Gaia machine (over SSH, or console).
   
   
2. Log in to Expert mode.
   
   
3. Define management interface:
   
   
   • In Clish: "set management interface <interface name>"


4. Set the IP address of the interface, if not already defined.


5. Restart the httpd2 daemon:
   
   [Expert@HostName]# tellpm process:httpd2
[Expert@HostName]# tellpm process:httpd2 t
   
   
6. Verify that httpd2 daemon is running:
   
   [Expert@HostName]# ps aux | grep -v grep | grep httpd2
   
   
7. Verify that httpd2 daemon is listening:
   
   [Expert@HostName]# netstat -anp | grep -v grep | grep httpd2
   
   Should see:
   

   tcp     0    0 0.0.0.0:443         0.0.0.0:*           LISTEN    PID_of_Parent/httpd2
   

8. Connect to Gaia Portal in web browser:
   
   
   • On Security Management Server:
     
     https://IP_address_of_MGMT_object
     
     
   • On Multi-Domain Security Management Server:
     
     https://IP_address_of_MDS_server

 

If editing the hosts file and restarting the httpd2 process does not resolve the issue, verify that the /tmp directory's permissions are correct as described in Scenario 11 of sk91380 - How to troubleshoot Gaia Portal (WebUI)

Permissions of the /tmp directory should be as follows:

drwxrwxrwt 5 admin root 4096 Jan 2 11:21 /tmp

To veiw the current permissions of a directory, use the "ls -ld" command on the directory:

[Expert@HostName]# ls -ld /tmp

Related solutions:

• sk73380 -Gaia Portal shows a blank page
• sk84561 - How to debug the Gaia Portal

---

Scenario 9

Title: Upgrade to Gaia from SecurePlatform fails with error message:"Gated configured cannot proceed with the upgrade exiting"

 

Symptoms:

• Upgrade to Gaia from SecurePlatform fails with error message:"Gated configured cannot proceed with the upgrade exiting" in CPupgrade.elg.
• Already disabled Advanced Dynamic Routing through cpconfig.

Cause:

GateD is no longer used in Gaia.

Simply turning off Advanced Dynamic Routing will not resolve this issue.

Must remove the GateD files in /etc.

Solution:

1. Disable SecurePlatform Pro.
   

   # pro disable

2. Remove the GateD files in /etc.
   

   # cd /etc

   # rm gated.ami
   # rm gated.ami.0
   # rm gated_xl.ami

3. Reboot. Perform upgrade again through WebUI.

---

Scenario 10

Title: "CLINFR0819 User: admin denied access via CLI" error when trying to log in via CLI after upgrading from R75.40 SecurePlatform to R76 Gaia

 

Symptoms:

• Unable to login via CLI (into Clish) after upgrading from R75.40 SecurePlatform to R76 Gaia:
  
  CLINFR0819 User: admin denied access via CLI
  
  
• Issue occurs only when upgrading from R75.40 SecurePlatform to R76 Gaia.
• There are no login issues after upgrading from R75.40 SecurePlatform to R76 SecurePlatform.

Cause:

Login fails because confd daemon is not running because it crashed during boot (operating system is not able to handle more than 10 Hard Disk Drives on the machine - e.g. Dell PowerEdge R710).

Solution:

This problem was fixed. The fix is included in:

• Check Point R77

Check Point recommends to always upgrade to the most recent version.

 

The code fix was improved to handle the first 10 HDD on the machine.

 

For other versions, Check Point can supply a Hotfix. Contact Check Point Support to get a Hotfix for this issue.
A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.

Applies To: 01170384 , 01171099 , 01184599 , 01207506 , 01171098

---

Scenario 11

Title: "Cannot Resolve Name!" error when connecting with SmartDashboard / SmartDomain Manager to Security Management Server / Multi-Domain Security Management Server using the FQDN (hostame) of the Server

 

Symptoms:

• "Cannot Resolve Name!" error when connecting with SmartDashboard / SmartDomain Manager to Security Management Server / Multi-Domain Security Management Server / Domain Management Server using the FQDN (hostame) of the Server.
  After clicking "OK", the SmartDashboard / SmartDomain Manager opens successfully.
• Output of "nslookup" command on SmartConsole computer shows the correct information.

Cause:

After upgrade from SecurePlatform to Gaia, need to add the FQDN to the /etc/hosts file on Security Management Server / Multi-Domain Security Management Server.

Solution:

To resolve the issue, add the relevant entry to the /etc/hosts.

Example: The FQDN of Security Management Server is management.mydomain.com

In /etc/hosts file, change from:

    <IP_Address>	management
    127.0.0.1	localhost
    ::1	localhost

To:

    <IP_Address>	management	management.mydomain.com
    127.0.0.1	localhost 
    ::1 localhost

Notes:

• HostName and FQDN in the /etc/hosts file must be separated by a white space - at least one space, or one tab character.
• On Gaia OS, the /etc/hosts file is automatically generated after any change in the Hosts settings:
  
  • Either in Gaia Portal - "Network Management" section - "Hosts and DNS" pane (in "System Name" field, or in "Hosts" field)
  • Or in Gaia Clish ("set host name" command / "set hostname" command)
• If manual changes in the /etc/hosts file do not survive reboot, then the following workaround can be used (to replace the relevant line in the /etc/hosts file during each boot):
  
  1. Backup the current /etc/rc.d/rc.local scipt:
     [Expert@HostName]# cp /etc/rc.d/rc.local /etc/rc.d/rc.local_ORIGINAL
  2. Edit the current /etc/rc.d/rc.local script:
     [Expert@HostName]# vi /etc/rc.d/rc.local
  3. Add the following line at the bottom:
     sed -i '/IP_Address/s/HostName/HostName HostName.Domain.Suffix/g' /etc/hosts
     Example:
     sed -i '/192.168.33.44/s/management/management management.mydomain.com/g' /etc/hosts
  4. Save the changes and exit from Vi editor.