Troubleshooting Tip: Problems after changing the supervisor IP address in FortiSIEM

[MauricioOliva]

Description	This article describes how to troubleshoot issues that occur after changing the IP address of the FortiSIEM Supervisor, focusing on identifying residual references to the old IP address at the backend level using the grep command on Rocky Linux. It also describes the requirement to manually update the IP address in the graphical user interface so that Workers and internal services correctly point to the Supervisor.
Scope	This article applies to FortiSIEM deployments running on Rocky Linux (version 6.4.0 and later) where the Supervisor IP address has been changed. It is applicable to environments using Supervisor and Worker nodes, including ClickHouse-based architectures.
Solution	Symptoms or problems observed after changing the Supervisor IP address: After changing the Supervisor IP address, the following symptoms may be observed: Workers remain in a Critical or Disconnected state. Collectors fail to reconnect or only partially send events. ClickHouse ingestion errors or missing events. Backend errors such as connection timeouts or upload failures. REST API integrations stop functioning even though network connectivity is present. These symptoms usually indicate that the old IP address is still referenced internally, either in backend configuration files or in the graphical user interface. Required verification in the graphical user interface: After changing the Supervisor IP address at the operating system level, the IP address must also be updated manually in the FortiSIEM graphical user interface. Verify and update the following paths: Go to System -> Admin -> Settings -> Cluster Config. Confirm that the Supervisor IP address reflects the new IP. Go to System -> Admin -> License -> Nodes. Select each Worker and confirm that the Supervisor IP address is updated accordingly. Failure to update these values causes backend services to continue using the old IP address even if the operating system configuration is correct. Backend validation using grep on Rocky Linux: If issues persist after updating the graphical user interface, verify whether the old IP address is still referenced at the backend level. Use the following command from the FortiSIEM Supervisor or affected Worker: grep -R X.X.X.X /opt/phoenix /etc 2>/dev/null Replace X.X.X.X with the old Supervisor IP address. Explanation of the command behavior: The command performs a recursive search for the specified IP address across key directories: /opt/phoenix contains FortiSIEM backend configuration, services, parsers, and internal references. /etc contains operating system and service-level configuration files. 2>/dev/null suppresses permission and system errors to keep the output clean and readable. The output shows the exact file paths and lines where the old IP address is still present. Interpreting the output: Typical output may look like the following: /opt/phoenix/config/phoenix_config.xml:<supervisorIp>X.X.X.X</supervisorIp> /etc/hosts:X.X.X.X fsm-supervisor This indicates that backend services are still referencing the old IP address, which explains why communication failures persist. Common locations where old IP addresses are found: During troubleshooting, the old IP address is commonly found in: Phoenix configuration XML files. ClickHouse node definitions. REST endpoint configurations. /etc/hosts entries. Service configuration files loaded by Phoenix processes. Each occurrence must be reviewed carefully before making changes. Important handling considerations: Do not modify backend configuration files unless the exact purpose of the file is understood. Always create a backup of any file before editing. Do not restart all services unless required. After correcting references, verify service status: phstatus Restart only the affected services if required. Conclusion: Residual references to an old Supervisor IP address are a common root cause of post-change issues in FortiSIEM environments. Using the grep command provides a fast and reliable method to identify backend inconsistencies that are not visible in the graphical user interface. When combined with correct manual updates in the graphical user interface, this approach significantly reduces recovery time and avoids unnecessary re-installation.