Troubleshooting
For the integrations on this page, a problem shows up as a Resource Errors alert on the account's Provision page (with the message under Error Details), as a warning icon on the account under Settings > Accounts, or on the target system for an export. The tables below map what you find to a fix.
For Panorama, NSX, and Infoblox, whose work runs through the Connector, see the Connector troubleshooting page instead.
Any integration
| Symptom | Likely cause / fix |
|---|---|
| Saving the Provision page is blocked with "… is required" on the password, secret, or token field, and you didn't change it | Expected. Those fields are write-only, so they're blank every time the page opens and have to be re-typed on every save, including one that only changes another field. Your other edits are still in the form: re-enter the value and save again. |
| The account saved, but nothing appears in Inventory | Saving doesn't test the connection, and the first discovery takes a little while. Wait a few minutes, refresh the Integrations page, and check the Provision page for Resource Errors. Discovery re-runs daily, so a fix to credentials is picked up by the next daily run. |
| Resource Errors shows an authentication or authorization error | The credentials are wrong, expired, or under-privileged. Re-enter them on the Provision page and confirm the account has what that integration's page lists under Before you start. |
| Resource Errors shows a connection or timeout error | Connect couldn't reach the system from the cloud. Confirm the hostname or URL is right and that the system accepts HTTPS from the internet. A system only reachable inside your network can't be used with these integrations; contact FireMon Support. |
| An error that was fixed still shows | Errors clear when a later discovery reads the same region without hitting them. Wait for the next run. |
| Items that were removed from the source are still in Inventory | The run that should have removed them hit an error, so nothing was removed. Fix the error; a clean run removes them. |
Illumio (Inventory Discovery)
| Symptom | Likely cause / fix |
|---|---|
| Authentication error | The Username must be the API key's authentication username (api_…), not your login name, and the Secret its secret. Create a new key in the PCE if the old one was revoked or expired. |
| "Not found" or an HTML page in the error | The API URL is missing the API path. It must end in /api/v2/, for example https://example.illum.io/api/v2/. |
| Discovery is slow, or the first run takes a long time | A PCE with more than 500 workloads takes longer to read. Let the run finish. |
| A workload is missing its IPs | Illumio reports no public IP or interface addresses for it. Check the workload's Interfaces in the PCE. |
SentinelOne (Inventory Discovery)
| Symptom | Likely cause / fix |
|---|---|
| Authentication error | The API Token has expired or was revoked. Generate a new one and re-enter it. Tokens on a service user can be given a longer expiry than a personal token. |
| "Not found" or an HTML page in the error | The API Base URL should be the console URL with no path, for example https://example.sentinelone.net. |
| Discovery is slow | A large fleet takes proportionally longer. Let the run finish. |
| An asset has no IP | SentinelOne reported none for it. Check the asset in the console. |
Guardicore
| Symptom | Likely cause / fix |
|---|---|
| Discovery: authentication error | Wrong username or password, or the user can't read assets. Re-enter the credentials on the Provision page. |
| Discovery: connection error | The Hostname should be the management center's hostname only, such as customer-12345.saas.guardicore.com, with no https:// or path. |
| Export: no rules appear in Guardicore after a change request passed | Check, in order: the Boundary's Target(s) includes the Guardicore account; the account has Export checked on its Provision page; the result was Pass or Review (Fail and error results don't export); and the change request contains nothing Guardicore can't express (a negated source or destination, a custom IP protocol, a port-range-size service, or a rule with no services), since any of those cancels the whole export. |
| Export: rules appear but are disabled | Expected for a Review result. Enable them in Guardicore once someone has approved them. |
| Export: a second copy of a rule appeared | Its comments were edited in Guardicore, so Connect couldn't match it on re-export. Delete the older copy and leave the comments alone. |
Export: unpublished draft rules are sitting in the connect-change-requests ruleset | An export failed partway through. Drafts don't enforce. Discard them in Guardicore, then re-evaluate the change request. |
| Deleted the change request, but its rules are still in Guardicore | Expected. Connect doesn't remove rules when a change request is deleted. Remove them by hand. |
ServiceNow
| Symptom | Likely cause / fix |
|---|---|
| Discovery: authentication error | Wrong username or password, or the account can't read the table. Re-enter the credentials and check the table's access controls. |
| Discovery: "Invalid table" or no items | Table Name doesn't match a table in your instance. Use the table's internal name (cmdb_ci_server), not its label. |
| Discovery: items appear but have no IPs | IP Field Name doesn't match the field's internal name, or the field is empty on those records. |
| Export: rows never reach the staging table | The staging table may not exist. Provisioning creates it when you save, but a failure there (usually the service account lacking access to sys_db_object) doesn't block the save. Confirm both u_connect_change_requests_staging and u_connect_decommissioned_assets_staging exist under System Definition > Tables; if not, fix the account's roles and re-save the Provision page. |
| Export: rows arrive in the staging table but the target table stays empty | No transform map is running. Its Name must be exactly Change Request Transformation Map or Decommissioned Asset Transformation Map, with the matching staging table as the Source table. |
| Export: duplicate records in the target table | Every evaluation or match exports again. Add coalesce fields to the transform map (u_id and u_rule_id for change requests; u_workflow_id and u_id for decommissioned assets). |
| Export: a change request row lists more addresses than its rule | Expected for a request with several rules. u_sources and u_destinations hold the combined resolved addresses of every rule in the request. Map each rule's own sources and destinations from u_raw. |
| Decommission History shows Error | Hover the tag for the message. It's usually credentials, or the staging table missing (see above). |
| Change request export: no way to tell if it worked | Nothing in Connect records it. Check the staging table in ServiceNow. |
Security Manager (Inventory Discovery)
| Symptom | Likely cause / fix |
|---|---|
| Security Manager isn't in the Cloud Provider list | It's hidden until FireMon Support enables it for your client. Ask them to, then refresh the page; if it still doesn't appear, sign out and back in. |
| Discovery error mentioning registration not found | Security Manager isn't registered with FireMon Insights yet. Complete Connect Your SIP Instance; discovery resumes on its own afterward. |
| No items after the first run | Confirm the Insights connection is active (Security Manager's Administration > Settings > Insights shows Registration Details), that the application server can reach ws.insights.prod.firemon.cloud on TCP 443, and that devices exist in the default domain. Only the default domain is discovered. |
| Discovery stopped after Security Manager moved to a new server | Insights rejects the new host by default. Ask FireMon Support to allow the new hostname. |
| Items disappeared and reappeared under new names | Objects are identified by device and name, so a rename in Security Manager is a new item. Expected. |
AWS
| Symptom | Likely cause / fix |
|---|---|
| Verify Account Access fails | The stack hasn't finished, or its registration step failed. In the AWS console, check the stack's Events for a failed resource. Once the stack shows CREATE_COMPLETE, verify again. |
| The stack fails on the StackSet | A region in EventRegions is disabled in your account. Remove disabled regions from the parameter and create the stack again. |
| Resource Errors with Access Denied or not authorized | The role is behind the current template. Run the update command shown on the CloudFormation tab of the Provision page. |
| Changes take a day to appear in Inventory | Events aren't arriving. Confirm the stack created the event StackSet in the regions you use. Free-tier clients don't receive events. |
| Deleted the stack | Discovery stops with permission errors. Delete the account in Connect too. |
Azure
| Symptom | Likely cause / fix |
|---|---|
| The provisioning command fails on the role definition or role assignment | Your user lacks permission to create custom roles or role assignments in the subscription. Owner, or User Access Administrator plus Contributor, is required. |
| Resource Errors mentioning the federated identity credential, subject, audience, or issuer | The Tenant ID or Client ID on the Provision page doesn't match the identity the command created. Copy the Client ID from the FireMonCloudDefenseIdentity identity in the FireMonCloudDefense resource group, confirm the tenant, and re-save. |
| Group export: no IP Group appears in Azure | Check, in order: the account was created with Read & Write (the Provision page's Access shows Read/Write (No IAM); a Read Only account can't be changed, so create a new one); Default Region is set on the Provision page; the Azure account is under the Group's Export To; and the Group's IPv4 members don't exceed 5,000, since Connect doesn't export a Group over the limit and the Groups page doesn't show export status. |
| Group export: the IP Group is missing addresses | IPv6 members are never exported. Otherwise the Group's filters currently match fewer items than expected; check the preview under Group Candidates. |
| Group export: the IP Group stopped updating | The Group has grown past 5,000 IPv4 entries. Connect stops exporting it rather than send a truncated list, and leaves the existing IP Group as it was. Split the Group into narrower Groups and export each. |
| Renamed the Group, and now there are two IP Groups | Expected. The IP Group follows the Group's name, so a rename creates a new one and leaves the old one for any rules still referencing it. Repoint those rules at the new IP Group, then delete the old one in Azure. |
| Deleted the Group, but the IP Group is still in Azure | Azure won't delete an IP Group a firewall policy still references, and Connect only retries the delete for a few minutes. Remove the reference, then delete the IP Group in Azure. |