Troubleshooting
An integration problem shows up on the job first, under Settings > Connectors > Jobs. On a failed job, hover its Status to read the reason.
A problem Connect expects to clear on its own, such as a host that was briefly unreachable, holds the job at In Progress and retries it instead of showing Error. A job that stays In Progress is usually retrying, not stuck. See Watching jobs.
Start with the Test button on the account's Provision page. It queues a Test Connection job, and reports DNS, TCP, TLS, and sign-in as separate steps, so it names the layer that is broken ahead of the next scheduled job.
To look up the exact text of a message instead, see Error Messages.
Connector status
| Symptom | Likely cause / fix |
|---|---|
| Connector shows red (disconnected) in Connect | The Connector isn't running, or it can't open its WebSocket connection to Connect. If its jobs still complete, only WebSocket traffic is blocked. Check Network Requirements and run firemon-connector --check-connectivity. |
| Pairing fails ("Failed to register") | The registration code expired (24-hour TTL) or was mistyped. Generate a fresh one from Settings > Connectors. |
| Jobs stall, restart from scratch, or a discovery never completes | More than one Connector is running under the same Connector ID: a cloned appliance, or a paired install's credentials copied to another machine (a second start from the same install is refused automatically). Stop every copy and start one. See Installation: run one Connector per identity. |
Connectivity
| Symptom | Likely cause |
|---|---|
| All hostnames fail DNS | Resolver unreachable, or *.firemon.cloud isn't allowed through |
| DNS resolves, but 443 fails for every host | Egress firewall blocks all outbound 443 |
| API works, WebSocket fails | Firewall allows the API hostname but not WebSocket Secure (WSS) |
| Registration succeeds, but runtime errors appear afterward | NTP failure, leading to clock drift and TLS certificate failures |
See Network Requirements for the full destination list and the built-in connectivity check.
Accounts and Groups
| Symptom | Likely cause / fix |
|---|---|
| Test sits on Waiting for connector and then times out | The Connector didn't pick the job up. Confirm it shows green under Settings > Connectors, then test again. A test that did run reports on the Jobs page as a Test Connection job. |
Test says may be offline | The message names the Connector and says when it last checked in. Start it, confirm it shows green under Settings > Connectors, then test again. |
Test says A test is already queued for connector <name>. | An earlier test is still waiting for that Connector. Wait for it to report, or check why the Connector isn't picking it up. |
| Test is greyed out | The form has unsaved changes. Save, then test. |
| The Password field is empty when the Provision page opens | Expected. Password fields are write-only. Leave it blank to keep the saved password, or type a new one to replace it. See Common to every integration. |
| A Group's Update or Project field is greyed out | Expected. Both are fixed when the Group is created. Create a replacement Group with the right values and delete the original. See Creating a Group. |
A Group's counts show Members: 10,000+ | The Group's filters match more than the 10,000-item cap, so it holds a partial membership and stops removing members. Narrow the filters or split the Group. See Group size limits. |
A Manual Group looks cut off but shows no + | Counts are only recalculated for Automatic Groups, so a Manual Group over the cap shows stale numbers that look exact. Judge it by its filters rather than its counts. |
| A Group keeps members that have left inventory | Same cause. Removals are skipped while a Group is over the cap. Bring it under the cap and it settles on the next refresh. |
OVA appliance
| Symptom | Likely cause / fix |
|---|---|
| The appliance booted to the pairing wizard even though you set a registration code | The vApp properties never reached the VM, or arrived but couldn't be applied. See If the appliance didn't pair itself. |
| Auto-pair failed with the properties present | Usually an expired or already-used registration code. Pair from the console with a fresh one, or power off, update the vApp property, and power back on. |
| The appliance came up on DHCP despite a static IP being set | Either the properties didn't arrive (check View OVF environment), or the static configuration was rejected, and View first-boot logs shows the error. Setting IP Address also makes subnet mask, gateway, and DNS servers required. |
| Editing vApp properties on a paired appliance changes nothing | Expected. First-boot processing is skipped once the appliance has credentials. Use the console menu instead, including Re-pair connector. |
Panorama (Group Export)
| Symptom | Likely cause / fix |
|---|---|
| Job errors with a TLS/certificate failure | Your Panorama uses a self-signed certificate and Allow Self-Signed Certificate is off. Turn it on under Integrations > (your account) > Provision. |
| Job errors with an authentication failure | Wrong Panorama username or password. Re-enter them under Provision. |
Test or a job fails with Device group '<name>' not found on Panorama. Available: … | The name has to match a device group that already exists in Panorama, exactly and case-sensitively, since device groups are created there. Pick a name from the message's Available list and fix it under Provision. |
| Job completes, but nothing changes in Panorama | The Group's Export To isn't set, or it targets a different account than expected. |
| DAG exists but has no members | The Group's filters match no inventory items. Reopen the Group and check the candidate-members preview under Group Candidates. |
| DAG exists in Panorama but not on the firewall | Share Unused Address and Service Objects with Devices is disabled and no enabled policy references the DAG. See Panorama: Details and edge cases. |
Job retries, then errors with No connected firewalls in the device group | No firewall in the device group was connected to Panorama when the job ran. Reconnect one, or name a different device group under Provision; the export runs again when the Group next changes or the Connector restarts. Test on the Provision page reports how many of the device group's firewalls are connected. |
| Deleted the Group in Connect, or removed the Palo Alto account from its Export To, but the DAG is still in Panorama | Expected. Connect leaves the DAG and its tagged IPs in place so live policy keeps a valid reference. Remove them in Panorama when no longer needed. |
VMware NSX (Group Export)
| Symptom | Likely cause / fix |
|---|---|
| Job errors with a TLS/certificate failure | Your NSX Manager uses a self-signed certificate (the default) and Allow Self-Signed Certificate is off. Turn it on under Integrations > (your account) > Provision. |
| Job errors with an authentication failure | Wrong username or password, or an account that lacks permission to create and update Groups. Re-enter the credentials under Provision. NSX locks the account for 15 minutes after five failed logins and restarts the lockout on every attempt made during it, so correct the credentials before saving or testing again. |
| Job error starts Reached NSX Manager at …, but it answers as a … | Manager Type does not match your NSX deployment. A Local Manager and a Global Manager (Federation) serve their APIs at different roots, and the Connector read the other one to be sure. Set Manager Type under Advanced to the type named, save, and press Test. Saving does not re-run the job; the export resumes when the Group next changes or the Connector restarts. |
| Job error starts NSX Manager answered 404 | The configured API root is absent and the other one did not answer either: the host is not an NSX Manager, or it was unreachable at the time. Check NSX Manager Host and press Test on the Provision page. |
| Group appears in NSX but membership looks out of date | Allow a short delay. NSX accepts the update immediately but applies it in the background. Recheck after a minute. |
| Job error starts NSX accepted and says NSX could not apply it | NSX took the update and then failed to realize the group. The usual cause is your environment's limit on group members. Split the Connect Group into narrower Groups. See NSX: Details and edge cases. |
| Job completed with a warning that NSX had not applied the group yet | NSX was still applying it when the Connector's 30-second wait ended, which happens on a busy Manager or a Global Manager fanning the group out to its sites. Check the group's Status column under Inventory > Groups; if it stops short of Success, see the row above. |
| A tag or description added to the NSX Group by hand disappeared | Expected. Every sync replaces the group's tags and description. See NSX: Details and edge cases. |
| Deleted the Group in Connect, or removed the NSX account from its Export To, but the group still exists in NSX | Expected. Connect leaves NSX objects in place so live enforcement keeps working, and the group keeps its last membership. Remove it manually in NSX Manager (Inventory > Groups) once you're done with it, deleting the group before any (IPv4) or (IPv6) member groups it nests. |
Groups named <name> (IPv4) and <name> (IPv6) appeared in NSX | Expected for a Group holding both address families: the group named after your Connect Group nests one member group per family. Reference the nesting group in rules and leave the member groups to Connect. See NSX: Details and edge cases. |
Cisco Firewall Management Center (Group Export)
| Symptom | Likely cause / fix |
|---|---|
| Test fails with is version 6.x | The FMC is older than 7.0 and has no dynamic object API. Upgrade it, or point the account at an FMC on 7.0 or later. |
| Test or a job fails with Domain '…' was not found | The account's Domain is not one the API user can see. The message lists the names that are; set Domain under Advanced to one of them, written exactly as shown, or leave it blank for Global. |
| Job errors with a TLS/certificate failure | Your FMC uses a self-signed certificate (the default) and Allow Self-Signed Certificate is off. Turn it on under Integrations > (your account) > Provision. |
| Job errors with an authentication failure | Wrong username or password. Re-enter them under Provision. |
| Job error starts Signed in to Cisco Firewall Management Center at …, but this user cannot manage dynamic objects | The API user's role lacks Object Manager > Modify Object Manager in that domain. Grant it and the export resumes when the Group next changes or the Connector restarts. |
Job error says FMC already has a dynamic object named firemon_… | The object exists in a domain the account cannot see, usually after Domain was changed. Delete it there (after removing it from any rule) or set Domain back. |
| Job error says the domain cannot change this dynamic object, which belongs to another domain | The object lives in an ancestor domain. Point the account at that domain, or delete the object there. |
| Job completes, but nothing changes in FMC | The Group's Export To isn't set, or it targets a different account than expected. Also check you are looking at the account's Domain in FMC. |
| Object exists in FMC but the firewall does not match the addresses | No deployed rule references the object yet; the job that created the object said so in a note. Add it to an access control rule and deploy that policy once; later mapping changes need no deployment. |
| A description typed on the object by hand disappeared | Expected. Every sync replaces it with FireMon Connect: <Group name>. |
| A mapping added or removed on the object by hand came back | Expected. The mappings always match the Connect Group. |
| Deleted the Group in Connect, or removed the FMC account from its Export To, but the object is still there | Expected. Connect leaves FMC objects in place so live enforcement keeps working. Remove it from any rule, deploy, then delete it under Objects > Object Management > External Attributes > Dynamic Objects. |
| A Group member written as a range appears in FMC as several CIDRs | Expected. FMC maps hosts and CIDRs only, so a range is exported as the CIDRs that cover it. |
| The Connector's user keeps getting logged out of the FMC web interface | FMC ends a user's web session when the same user signs in through the API. Give the account its own API user. |
Fortinet FortiManager (Group Export)
| Symptom | Likely cause / fix |
|---|---|
| Test or a job fails with ADOM '…' was not found | The account's ADOM is not one the administrator can see. The message lists the names that are; set ADOM under Advanced to one of them, written exactly as shown, or leave it blank for root. |
| Job errors with a TLS/certificate failure | Your FortiManager uses a self-signed certificate (the default) and Allow Self-Signed Certificate is off. Turn it on under Integrations > (your account) > Provision. |
| Job errors with an authentication failure | Wrong username or password, or the administrator has no JSON API access. Re-enter the credentials under Provision, and check JSON API Access on the administrator in FortiManager. |
| Job error starts Signed in to Fortinet FortiManager at …, but this administrator cannot work in ADOM | The Admin Profile cannot change policy objects in that ADOM. Grant it read-write access to policy objects and the export resumes when the Group next changes or the Connector restarts. |
| Job stays In Progress with Another administrator holds the workspace lock | The ADOM runs in workspace mode and someone else holds its lock. The job retries for a while, then errors with that message, and runs again when the Group next changes or the Connector restarts. A lock left behind by a closed session can be released under System Settings > All ADOMs. |
| Job completes, but nothing changes in FortiManager | The Group's Export To isn't set, or it targets a different account than expected. Also check you are looking at the account's ADOM in FortiManager. |
| The group exists in the ADOM but the FortiGate does not match the addresses | The package has not been installed since the change. Install it yourself, or turn on Install policy packages after a sync on the account. The job that created the group said so in a note. |
| Job summary says Install skipped … preview carries changes this sync did not make | The policy package also holds changes made by someone else, so the Connector left the install to you. Install the package once those changes are meant to go out. |
| Job summary says Install failed | The install ran and FortiManager or the device rejected it; the summary quotes the task's reason. The group is correct in the ADOM. Fix the cause and install the package yourself. |
| A comment typed on the group by hand disappeared | Expected. Every sync replaces it with FireMon Connect: <Group name>. |
| A member added or removed on the group by hand came back | Expected. The members always match the Connect Group. |
| Deleted the Group in Connect, or removed the FortiManager account from its Export To, but the group still exists | Expected. Connect leaves FortiManager objects in place so live enforcement keeps working. Remove it from any policy, then delete it under Policy & Objects > Object Configurations > Firewall Objects > Addresses. |
Groups named firemon-<id> and firemon-v6-<id> appeared | Expected for a Group holding both address families: FortiOS keeps IPv4 and IPv6 in separate tables. Reference the one your policy needs. |
Address objects named firemon-net-… that no group uses | Expected after a Group shrinks: dropped member objects stay in the ADOM. Delete them by hand if no longer needed; FortiManager refuses while anything still references them. |
Infoblox (Inventory Discovery)
| Symptom | Likely cause / fix |
|---|---|
| Discovery job errors with a TLS failure | Your grid uses a self-signed certificate and Allow Self-Signed Certificate is off. Turn it on under Provision. |
| Job errors with an authentication failure, and the API user is now locked out | A rejected login ends the run at once, precisely so repeated attempts can't lock the account, but the first rejection still counts. Unlock the user in Grid Manager, correct the credentials under Provision, and press Test before the next run. |
Test or the discovery job says <host> answered HTTP <status>, redirecting to <target> or ... with a page titled "<title>", then Something other than the WAPI answered | The address is up but isn't serving the WAPI. A Grid Master Candidate with Read Only API access off, or any other member that isn't the master, answers with its web UI or a redirect to the master; a title from something other than Infoblox means a proxy is in the path. Set Host Address to the Grid Master. In Grid Manager, Grid > Grid Manager > Members shows which member the address belongs to. |
Test passes but ends with The grid answered the bulk request handler with HTTP 405 (Allow: GET) | Host Address takes reads but not the bulk read discovery depends on, which is how a Grid Master Candidate with Read Only API access on answers when the API user can't read Grid Member objects, so the test couldn't identify it. A run through the Connector will stop at its first bulk read. Set Host Address to the Grid Master, or give the API user read access to Grid Member objects: the test then names the candidate, ends so discovery fetches networks one at a time., and discovery reads it that way. The other endings are listed under Error messages. |
| Job errors saying the grid refused the bulk request handler | Host Address points at a grid member rather than the Grid Master. A member with read-only API access refuses every POST. Point the account at the Grid Master, or grant the API user permission to use the WAPI request handler. Pressing Test reports this before a run does. |
| Job errors saying the grid is refusing requests from the API user | The account can sign in but can't read the objects discovery needs. On 403, check the API user's permissions on networks and IP addresses. Otherwise confirm the host is the Grid Master and that its WAPI serves this user. |
| The job pauses after 12 hours, or errors saying the grid fetched nothing more within 12 hours | One attempt is capped at 12 hours. A pause is normal on a large or slow grid: the job retries on its own and carries on from where it stopped, and the counts in the reason say how far it got. The error means a whole 12 hours passed without one more network; the counts say how much of the cycle was fetched before that, and the next scheduled run carries on from there. Press Test on the Provision page to see what the grid answers, and look at why it is not answering reads. |
| No inventory items appear | Discovery covers every network view the API user can read. Confirm a network exists in a view that user has read permission on; a view it can't read is left out with nothing in the job to say so. |
| A discovery hasn't started, and no job is queued for it | One discovery runs at a time per account, and a Connector reads each Grid Master for one account at a time; a daily run that lands while one is in progress is skipped rather than queued. Check the Jobs page for a run still in progress against that grid. A just-provisioned account's first job normally starts within about a minute. |
The discovery job sits at In Progress and keeps re-running | Connect couldn't finish reading the grid, so it retries rather than failing. Repeated retries usually mean the grid is intermittently unreachable or refusing some reads, so check its reachability from the Connector. A retrying job shows no error or summary yet; if the retries run out, the job changes to Error with the reason. |
| A network that still exists on the grid lost its addresses and shows only a CIDR | The grid wouldn't return its addresses during a run that otherwise finished, so it was kept as a CIDR rather than dropped. The job Summary counts these as with errors. A later clean run restores the address list. See Infoblox: Details and edge cases. |
The job Summary says cleanup skipped | Discovery found nothing, or under half the networks of a last complete run that found at least 100, so networks that are gone from the grid were left in Inventory rather than swept. Confirm Host Address points at the Grid Master and that the API user can read every network view you expect. A genuine shrink clears on the next run. |
| A network appears in Inventory with no individual IPs, just a CIDR | Expected for a network with more than about 12,000 used IPv4 addresses, or 5,000 IPv6 addresses. It's represented by its CIDR plus utilization counts instead of an address list. See Infoblox: Dense networks are summarized by CIDR. |
| A Group exports more addresses than the grid actually has in use | A summarized network contributes its whole CIDR to the Group, including currently-unused addresses. Same cause as the row above. |
| A network that used to arrive with its addresses is now a CIDR | The grid didn't return that network's addresses in time on that run, so it was kept as its CIDR. On a busy grid, once several large networks in a row time out, the rest of that size are kept as CIDRs for the rest of the run. The job's summary counts them. A quieter run brings the addresses back. |
| Discovery takes hours on a large grid | Expected. The Connector paces its requests to what the Grid Master is keeping up with, so the grid stays responsive to everything else using it. The Summary column counts networks as they're listed and uploaded. |
Where the Connector logs are
On the machine or appliance running the Connector; the per-OS paths are in Installation: where logs live. Entries at INFO level and above are also forwarded to Connect (see Security & Data Protection: log forwarding), so FireMon Support can usually see them without you collecting files.