Error Messages
The error messages Connect can show you, what each one means, and how to fix it. Search the page for the text in front of you. Angle brackets mark values that change, so <host> is your hostname and <status> an HTTP status code.
If you have a symptom rather than a message, start with Connector troubleshooting or Integration troubleshooting.
Where errors appear
| If this failed | Look here |
|---|---|
| A Connector job | Settings > Connectors > Jobs. Hover the job's Status |
| A connection test | The alert under the form on Integrations > (your account) > Provision, with a line per step. An on-prem test also lands on the Jobs page as a Test Connection job |
| Discovery or export for an account | Integrations > (your account) > Provision, under Resource Errors |
| A save | On the form, or in a red message at the top of the page |
| A REST or GraphQL call | The response body, with an HTTP status code. See API authentication |
| Connector startup or pairing | The appliance console, and the Connector log. See Where logs live |
How to read a job error
Causes are chained with <-. The text on the left is Connect's description of what failed. Each <- takes you one step closer to the underlying reason.
Cannot reach Infoblox host 172.16.48.156 <- connect ECONNREFUSED 172.16.48.156:443
Connect couldn't reach the grid, and the reason was a refused connection.
Long messages are cut short. A long vendor error can lose its ending. The Connector log has the full text.
A job at In Progress is not stuck. Connect retries failures it expects to clear on their own, such as a host that was briefly unreachable, and marks the job Error only once the retries run out.
Connection tests
The Test button on an account's Provision page reports up to four steps, in order: DNS lookup, TCP connection, TLS certificate, and Sign-in and read. The first one to fail stops the test, and the rest are marked as not run. The step's own text names the host and the reason; a certificate failure is worded as in Certificate errors below.
These appear instead of a step list, for a test that stopped before reaching the host or lost track of its result.
| Message | What it means | What to do |
|---|---|---|
This account has no saved credentials yet. Save the form, then Test. | The account exists and is awaiting its first provisioning | Fill in the Provision page and save, then test |
Could not read the saved credentials for this account. Save the form again, then Test. | The stored credentials couldn't be decrypted | Re-enter them on the Provision page and save |
Connection testing is not available for <Product>. | Connection testing isn't offered for this provider | AWS, Azure, and Security Manager are verified from their own pages instead |
Select a connector and save this account before testing it. | Panorama and NSX reach your network only through a Connector | Pick one in the Connector field and save |
Connector <id> is not registered. Register it under Settings, then test again. | The account names a Connector that no longer exists | Pair a Connector under Settings > Connectors and select it on the Provision page |
The connector did not report a result in time. | The Connector didn't pick the test up within two minutes | Confirm it shows green under Settings > Connectors. A test that did run appears on the Jobs page as a Test Connection job |
Could not queue the test for the connector. Try again in a moment. | Connect couldn't queue the test | Transient. Test again |
What a passing test says
The Sign-in and read step reports what the test managed to read, which is worth checking even on a pass.
| Product | Message |
|---|---|
| Guardicore | Connected to Guardicore and authenticated. |
| Panorama | Connected to Panorama at <host> and authenticated. <n> managed device(s) visible. |
| NSX | Reached VMware NSX <Local or Global> Manager at <host> and authenticated. |
| ServiceNow | Connected to ServiceNow and read table "<table>" and the table registry., or the same with Table "<table>" is readable but has no rows. |
| Infoblox | Connected to Infoblox (WAPI v<version>) at <host>. Answered by <member>. The grid accepts bulk requests. The version shown is the one the test negotiated. The middle sentence names the grid member that owns the address, adding a Grid Master Candidate with read-only API access on (or off) when it is one, and through a node address rather than its VIP <address> when an HA member was reached on a node's own address. The last sentence reports what the grid said to a bulk read; the other endings, which still pass the test but stop the first discovery run, are under Infoblox below |
Failures from the read itself
These come from the Sign-in and read step, where the host answered and the response wasn't what the integration expects.
| Message | What it means | What to do |
|---|---|---|
<host> answered HTTP <status>, redirecting to <target>. Something other than the WAPI answered: a Grid Master Candidate with read-only API access off, a non-master member, or a proxy in front of the grid. | The host is up, but the address is not serving the Infoblox WAPI. A redirect to another Infoblox hostname is a member sending the request to the Grid Master's GUI | Set Host Address to the Grid Master. In Grid Manager, Grid > Grid Manager > Members shows which member the address belongs to and whether it is the master |
<host> answered HTTP <status> with a page titled "<title>". Something other than the WAPI answered: ... | The same, where the host served a web page instead of redirecting. The title says whose page: Grid Manager's own, or a proxy or sign-in portal in front of it | As above. A title from something other than Infoblox means a proxy is in the path between the Connector and the grid |
No access token was returned. Check that the hostname is the management API. | Guardicore answered the sign-in without a token | Hostname should be the management center's hostname only, with no https:// or path |
The response was not a workload list. Check the API endpoint. | Illumio answered with something other than workloads | API URL must end in /api/v2/ |
The response was not an asset list. Check the API base URL. | SentinelOne answered with something other than assets | API Base URL should be the console URL with no path |
ServiceNow did not answer as the Table API. Check the instance name. | Something other than the Table API answered | Instance Name is the subdomain only, such as acme |
ServiceNow answered, but the table registry (sys_db_object) could not be read. Check the instance name and that this user can read tables. | The instance answered, and the service account can't read sys_db_object | Grant it read access to sys_db_object, which both exports need to create their staging tables |
A test proves the host is reachable and the credentials are accepted. The first real job proves the rest: that the Panorama Device Group you named exists, and that an NSX user can create Groups.
Certificate errors
Connection tests, Infoblox discovery, and Panorama exports word an untrusted certificate the same way. <Product> is the system's name: Panorama, NSX Manager, Infoblox, Illumio, and so on. An NSX export has wording of its own, in the last row.
| Message | What it means | What to do |
|---|---|---|
<Product>'s TLS certificate at <host> is not trusted. Enable "Allow Self-Signed Certificate" on the account, or install a certificate from a publicly trusted CA on <Product>. (<reason>) | The certificate is self-signed, expired, issued by a private CA, or names a different hostname. <reason> gives the specific fault | For a self-signed certificate, turn on Allow Self-Signed Certificate under Advanced on the account's Provision page. For an expired certificate or a hostname mismatch, replace the certificate on the system itself. The job fails straight away rather than retrying, so it stays until you replace the certificate or change the setting |
<Product>'s TLS certificate at <host> is not trusted. Install a certificate from a publicly trusted CA on <Product>. (<reason>) | The same fault, on an integration with no self-signed option: the cloud integrations other than Infoblox | Replace the certificate on the system itself. Connect reaches these systems over the internet and always requires a publicly trusted certificate |
<operation>: certificate not trusted (<reason>) - set allowSelfSignedCert for a self-signed NSX Manager cert | An NSX Group export hit the same fault. Only NSX exports word it this way; an NSX connection test uses the wording above | Turn on Allow Self-Signed Certificate under Advanced on the account's Provision page, or install a publicly trusted certificate on the Manager |
Any Connector job
| Message | What it means | What to do |
|---|---|---|
This connector build (v<version>) does not handle job type "<type>" for provider "<provider>". Upgrade the connector to claim this job. | The account uses an integration this Connector build doesn't support | Update the Connector. See Updates |
Account <id> is not assigned to this connector | The job belongs to an account a different Connector now owns, usually because the account's Connector was changed after the job was queued | Check the account's Connector on its Provision page. The next job goes to the right Connector |
Exceeded maximum claim attempts (5) | The job was retried until Connect gave up, with no more specific reason recorded | Check that the target system is reachable from the Connector, and that the Connector wasn't restarted while the job was running |
Failed to fetch credentials for account <id>: <status> | The Connector couldn't retrieve the account's credentials | Re-enter the credentials on the account's Provision page and save |
Failed to fetch connector accounts: <status> | The Connector couldn't retrieve its list of accounts | Run firemon-connector --check-connectivity. See Network Requirements |
Infoblox credentials are missing required fields (hostAddress, username, password) | The account was saved without a value the integration needs. Palo Alto and NSX report this the same way, without naming the fields | Complete the account's Provision page and save |
Failed to parse Infoblox credentials JSON | The stored credentials can't be read. Palo Alto and NSX report this the same way | Re-enter the credentials on the Provision page and save. Contact FireMon Support if it happens again |
Network error: <reason> | A call from the Connector to Connect failed | Retried automatically. If it persists, see Network Requirements |
Palo Alto Panorama
| Message | What it means | What to do |
|---|---|---|
Cannot reach Panorama at <host>. Verify the hostname is correct and that the connector has network access to the device. (<cause>) | The Connector couldn't open a connection to Panorama | Check Panorama Hostname on the Provision page, and that the Connector can reach it on TCP 443. Retried automatically |
Panorama request timed out after 30000ms | Panorama accepted the connection but didn't answer in time | Retried automatically. Repeated timeouts usually mean Panorama is under heavy load |
Panorama network error: <reason> | The connection dropped part-way through a request | Retried automatically. <reason> gives the network fault |
Panorama API returned HTTP <status>: <reason> | Panorama rejected the request | A 403 reading Invalid Credential means the Username or Password is wrong. Other statuses usually mean the administrator account is missing a permission. See Before you start |
Panorama keygen failed: <reason> | Panorama refused to issue an API key | Almost always the wrong credentials, or an administrator account without XML API access. Re-enter them under Provision |
API key not found in keygen response | Panorama answered the key request without a key | Confirm the administrator account has XML API access |
Panorama request failed: <reason> | Panorama accepted the request and reported a failure. <reason> is Panorama's own message | Conditions that clear on their own, such as a commit already running or a locked device group, are retried. Anything else needs fixing in Panorama |
Device group '<name>' not found on Panorama. Available: <names> | The name has to match a device group that already exists in Panorama, exactly and case-sensitively | Correct Device Group under Provision, using a name from the Available list |
Job <id> finished with result '<result>': <details> | A commit or push finished unsuccessfully. <details> is Panorama's explanation | Open the job in Panorama under Tasks for the full text |
Job <id> did not complete within <ms>ms (status: <status>, progress: <n>%) | A commit or push was still running when Connect stopped waiting | Retried automatically. A large device group under load can need more than one attempt |
commit failed: <reason> | Panorama refused the commit | A commit lock held by another administrator is the usual cause, and clears on its own |
commit job failed: <reason> | The commit started and then failed or timed out | The Group's addresses are registered but not yet active on the firewalls. Retried on the next job |
push failed: <reason> | Panorama refused to push the device group to its firewalls | Check the device group still has connected firewalls under Panorama > Managed Devices |
push job failed: <reason> | The push started and then failed or timed out | Retried on the next job |
Register failed on firewall <serial>: <reason> | Registering the Group's addresses failed on one firewall | Confirm the firewall is connected and the administrator role allows User-ID. Other firewalls are unaffected |
Panorama User-ID request failed for <n> of <m> reported entries: <detail> | Panorama accepted the request and rejected some of the IP-to-tag entries in it | <detail> names the entries it rejected. The rest of the Group registered normally |
Unregister failed on firewall <serial>: <reason> | Removing addresses that left the Group failed on one firewall | As above. Until a later run succeeds, the DAG keeps addresses that should have gone |
DAG: <reason> | Creating or updating the Dynamic Address Group failed | <reason> gives the cause, usually a missing permission on the device group |
VMware NSX
Messages from NSX begin with the operation that failed, followed by the status NSX returned.
| Message | What it means | What to do |
|---|---|---|
NSX Manager not reachable as local or global - local: <reason>; global: <reason> | Connect tried the account as both a Local Manager and a Global Manager, and neither answered | If both reasons are connection errors, check NSX Manager Host and that the Connector can reach it on TCP 443. If both are 404s, the host isn't an NSX Manager |
NSX authentication failed for <host>: <reason> | NSX rejected the login | Re-enter Username and Password under Provision, and confirm the account may create and update groups |
<operation>: HTTP 401 (check NSX username/password) - <body> | NSX rejected the credentials during a job | Re-enter the credentials under Provision |
<operation>: HTTP 403 (check NSX username/password) - <body> | The account signed in but isn't allowed to perform the operation | Give the account permission to create and update groups in the domain |
<operation>: HTTP <status> - <body> | NSX rejected the request. <body> is NSX's own error | Read <body>. Timeouts and server errors are retried automatically |
<operation>: HTTP <status> (redirects to <url>) - <body> | The host redirected the request instead of answering it | The account usually points at a load balancer or reverse proxy. Point it at NSX Manager |
<operation>: HTTP 404 (check the account's Manager Type: Local vs Global use different API roots) - <body> | The path is absent on this Manager, which is what the wrong Manager Type looks like | Correct Manager Type under Provision, then press Test. See NSX |
<operation>: HTTP <status> - session expired, re-authenticating | The reused NSX session had expired | Retried automatically with a fresh login. Worth a look only if it repeats |
<operation>: timed out after 30000ms | The Manager accepted the connection and didn't answer in time | Retried automatically. A Manager that is consistently slow is worth checking |
<operation>: response missing JSESSIONID cookie or X-XSRF-TOKEN header | The sign-in succeeded but returned no usable session | Something between the Connector and NSX is stripping cookies or headers. Point the account at NSX Manager directly |
<operation>: invalid JSON response: <reason> | The host returned something other than JSON | Usually a proxy or captive portal answering in NSX's place |
NSX realization failed for <path> | NSX accepted the group but couldn't apply it | Open the group in NSX Manager under Inventory > Groups and check its status. Your environment's limit on group members is the usual cause |
NSX realization timed out for <path> after 60000ms (last status <status>) | NSX was still applying the group when Connect stopped waiting | Retried automatically. Check the group in NSX after a minute |
NSX group would have <n> <IPv4 or IPv6> members; the API allows at most 25000 per expression - split the Connect Group across multiple NSX groups | The Group holds more addresses of one family than a single NSX group accepts; the two families are counted separately | Narrow the Group's filters, or split it into several Groups and export each. See Group size limits |
No CIDRs fetched for list <id> | Connect couldn't read the Group's addresses before the sync | Retried automatically |
Infoblox
| Message | What it means | What to do |
|---|---|---|
Cannot reach Infoblox host <host> | The grid didn't answer at all | Check Host Address on the Provision page, and that the Connector can reach the grid on TCP 443. Retried automatically |
Failed to auto-negotiate Infoblox WAPI version: <reason> | The host answered, but not as a WAPI version Connect can use. The host is reachable, so this isn't a network problem. <reason> is the host's own answer: a <host> answered HTTP <status> ... sentence is the address not serving the WAPI at all, worded as in Failures from the read itself | For a <host> answered HTTP <status> ... reason, set Host Address to the Grid Master; a Grid Master Candidate or other member answers this way. Otherwise re-enter the credentials, then check the grid's WAPI version. Pressing Test on the Provision page reports the same reason without waiting for a run |
Infoblox discovery incomplete: <n> items uploaded, <m> networks could not be fetched. | The run couldn't read every network, so its results are partial | Retried rather than failed, so Inventory is left as it is after a partial read. If it repeats, the grid is refusing some reads |
Infoblox at <host> is refusing requests from the API user with HTTP <status>; <n> items were uploaded before the run stopped. | The grid is up and rejecting this user's reads | On 403, check the API user's permissions. Otherwise confirm the host is the Grid Master and that its WAPI serves this user |
Infoblox at <host> refused the bulk request handler with HTTP <status>, and fetching networks one at a time is off; <n> items were uploaded before the run stopped. | The grid rejected the request handler discovery reads through | Point the account at the Grid Master: a member with read-only API access refuses every POST. Otherwise check the API user's permission to use the WAPI request handler |
Infoblox at <host> answered for no network: <n> networks were uploaded as their CIDR only. | Every network came back as a CIDR alone, the shape an API user without address permissions sees | Check the API user's permissions. Retried rather than failed |
Infoblox at <host> could not be walked within 8 hours: <n> items uploaded, <m> networks were not fetched in time. | One run has eight hours, and this grid needed longer | Narrow what the account covers, or raise the grid's WAPI throughput. Repeated failures are worth raising with FireMon Support |
A network whose addresses couldn't be read during a run that otherwise finished is kept as its CIDR and counted in the job Summary as with errors, not reported as a job error. A Summary ending in cleanup skipped means stale networks were deliberately left in Inventory. Both are covered in Infoblox: Details and edge cases.
What the Infoblox test says about bulk reads
After signing in, the test asks the grid which member owns the address, then sends one bulk read, the kind discovery depends on, and ends its Sign-in and read message with the answer. The member sentence reads Could not tell which member answered. (<reason>) when the API user can't read Grid Member objects, which is informational and never fails the test. A refused bulk read doesn't fail the test either, since the sign-in worked, but the first discovery run stops at its first bulk read, with the refused the bulk request handler error above. Fixing it before that run saves the wait.
| Ending | What it means | What to do |
|---|---|---|
The grid accepts bulk requests. | The host is serving the full WAPI | Nothing. Discovery will run as described |
The grid answered the bulk request handler with HTTP 405 (Allow: GET): POST is not accepted, as on a member with read-only API access, so discovery cannot use bulk requests on this host. | The host takes reads but not the bulk read, which is how a Grid Master Candidate with Read Only API access answers. Allow: GET is the host's own statement of what it accepts | Set Host Address to the Grid Master |
The grid refused the bulk request handler with HTTP 403: the API user may not use it, or the host is a member with read-only API access, so discovery cannot use bulk requests on this host. | Either the API user lacks permission to use the WAPI request handler, or the host is a read-only member | Check the API user's permissions in Grid Manager, and that Host Address is the Grid Master |
The grid answered the bulk request handler with HTTP 404: no /request handler is served at this address, so discovery cannot use bulk requests on this host. | The host has no bulk handler at the negotiated version | Confirm Host Address is the Grid Master and that nothing in front of it rewrites paths |
WAPI v<version> has no bulk request handler, so networks are fetched one at a time. | The grid's WAPI predates 2.5. Discovery still works, one network at a time | Nothing, unless the grid is large; then expect a long run |
Could not tell whether the grid accepts bulk requests. (<reason>) | The bulk read didn't get a clear answer, for the reason quoted, usually a timeout | Test again. If it repeats, the first run will report what the grid does |
Cloud integrations
These integrations run from the cloud rather than through the Connector. Discovery errors appear under Resource Errors on the account's Provision page, one per resource type and region. Most of the text comes from the vendor's own API. The messages below are Connect's own.
Exports behave differently. A decommission export records its error, and hovering the tag in History shows it. A change request export is recorded in the target system alone, so check there: the request evaluates normally either way.
Azure
| Message | What it means | What to do |
|---|---|---|
Failed to get Azure token. | Connect couldn't authenticate to Azure | Tenant ID or Client ID doesn't match the identity the provisioning command created, or the federated credential has been removed. See Azure |
Failed to get encrypted account credentials | The account's stored credentials couldn't be read | Re-enter them on the Provision page and save |
A Group that has grown past the 5,000-entry IP Group limit is skipped rather than failed, and its IP Group in Azure keeps its previous contents. See Integration troubleshooting.
Guardicore
These come from checking a change request before export. Any one of them cancels the export, so none of the request's rules reach Guardicore.
| Message | What it means | What to do |
|---|---|---|
Rule <id>: negated sources/destinations are not supported by Guardicore policy rules. Guardicore only supports negation on label-based exclusions, not CIDRs. | A rule uses NOT on a source or destination | Rewrite the rule without negation, then evaluate it again |
Rule <id>: custom protocol (<protocol>) is not supported by Guardicore. Guardicore only supports TCP, UDP, and ICMP. | A rule names an IP protocol by number | Express the rule in TCP, UDP or ICMP terms, then evaluate it again |
Rule <id>: PortRangeSize is a Connect-side boundary concept and has no Guardicore equivalent. | A rule uses a port-range-size service, which belongs in a Boundary rather than a request | Replace it with specific ports |
Rule <id>: no services defined. At least one protocol/port is required. | A rule has no services | Add at least one service to the rule |
CR <id> has no rules to export | The change request has no rules | Add rules to the request |
ServiceNow
These come from saving the Provision page or from an export; both create the staging tables when they're missing. A failure while saving still lets the save succeed, so the first sign is usually a missing staging table, or rows that fail to arrive.
| Message | What it means | What to do |
|---|---|---|
Could not resolve sys_import_set_row sys_id. | Connect couldn't read the table that staging tables are built from | The service account can't read sys_db_object. Grant it access, then save the Provision page again |
Staging table creation did not return a sys_id. | ServiceNow didn't confirm the new staging table | Check for u_connect_change_requests_staging and u_connect_decommissioned_assets_staging under System Definition > Tables. See ServiceNow |
ServiceNow Batch API failed adding dictionary field to <table> (status <status>): <body> | The staging table exists, but its columns couldn't be added | Usually the service account lacking rights on sys_dictionary. Correct its roles, then save the Provision page again |
ServiceNow Batch API left <n> dictionary field request(s) unserviced for <table> | ServiceNow accepted the request but didn't add every column | As above. Check the staging table's columns, then save again |
Could not resolve table name for sys_id=<id> | A table Connect referred to couldn't be found | Confirm Table Name on the Provision page is the table's internal name, such as cmdb_ci_server, rather than its label |
Illumio
| Message | What it means | What to do |
|---|---|---|
GET <path> returned <value> (<type>) for X-Total-Count header, GET <path> returned invalid total <value> for X-Total-Count header | The PCE's response was missing the item count Connect needs to page through results | Confirm API URL ends in /api/v2/. Without the path, something other than the PCE answers |
response-async response is missing the Location header | A large read (more than 500 workloads) didn't start properly | Let the next discovery run. Contact FireMon Support if it persists |
Security Manager
| Message | What it means | What to do |
|---|---|---|
SIP registration not found for client <id>, Insights registration not found for client <id> | Security Manager isn't registered with FireMon Insights, so Connect has no route to it | Complete Connect Your SIP Instance. Discovery resumes on its own |
Pairing and starting the Connector
| Message | What it means | What to do |
|---|---|---|
Missing registration code | Pairing was attempted with no code | Enter the code from Settings > Connectors |
Invalid or expired registration code | The code doesn't exist, has been used already, or is more than 24 hours old | Generate a new code under Settings > Connectors and pair again |
Too many attempts. Try again later. | Too many pairing attempts came from one IP address | Wait, then try again with a code you have confirmed |
Failed to register: <message> | Connect rejected the pairing request. <message> is the reason | A bad or already-used code needs a new one. During first boot, a server error is retried on its own while the appliance finishes getting an address |
Registration failed. Check the code and try again, or press Ctrl+C to restart the wizard. | The console wizard's version of the same failure | Re-enter the code, or generate a new one |
Registration response missing apiKey or connectorId | Pairing was accepted but the response was incomplete | Pair again. Contact FireMon Support if it happens twice |
Credentials file <path> is missing; pair the connector via the console wizard. | The Connector started as a service without being paired | Pair it. On the appliance, use the console menu |
Credentials file <path> is invalid (<reason>); quarantined — re-pair via the console wizard. | The credentials file can't be read as credentials, and has been set aside | Pair again with a new registration code |
Credentials file <path> is unreadable (<reason>); fix its ownership/permissions so the firemon-connector user can read it, or re-pair via the console wizard. | The file is there, but the account running the Connector can't open it | Correct the file's owner and permissions, or pair again |
Cannot create credentials directory <dir>: <reason> | The Connector couldn't create the directory it stores credentials in | Give the account running the Connector write access to the parent directory |
Another connector instance is running (<path>). Stop it, then start the connector again. | A second Connector is already running from this installation | Stop the other one. Two Connectors sharing an identity make jobs stall and restart. See Run one Connector per identity |
Another connector instance is running (<path>). Waiting for it to exit. | The same, but this Connector is waiting rather than exiting | As above. It starts as soon as the other one stops |
Another connector instance is running. Waiting up to <n>s for it to exit... | Expected while the Connector updates itself and the new version waits for the old one | Nothing, unless the message keeps repeating |
Connectivity check
firemon-connector --check-connectivity tests DNS and TCP 443 against every endpoint the Connector uses.
| Message | What it means | What to do |
|---|---|---|
DNS resolution failed | The hostname didn't resolve | Your resolver is unreachable, or *.firemon.cloud isn't permitted. See Network Requirements |
timeout after 5000ms | The name resolved, but the connection never completed | An egress firewall is dropping the traffic rather than refusing it |
One or more checks failed. | The summary line, shown whenever any endpoint failed | Read the per-endpoint lines above it. If the API passes and the WebSocket fails, WSS is blocked on its own |
Connector updates
These appear in the Connector log. A failed update is discarded, and the Connector carries on running its current version.
| Message | What it means | What to do |
|---|---|---|
Release signature verification failed — update rejected | The download isn't a genuine FireMon release | Contact FireMon Support. Repeated failures suggest the download is being intercepted |
Checksum mismatch: expected <a>, got <b> | The download doesn't match its published checksum, usually because a proxy altered or truncated it | Retried at the next update check |
Download failed: <status> <text> | The release couldn't be downloaded | Confirm the Connector can reach the updater endpoint. See Network Requirements |
Download stalled: no data for 60000ms | The download started and then stopped sending data, usually a proxy holding the connection open | Retried at the next update check |
Saving a Boundary or change request
Validation failures arrive together, in one message:
This request is invalid and contains the following errors:
* Name is required
* Invalid Source CIDR or IP: 10.0.0.300
| Message | What it means | What to do |
|---|---|---|
Name is required | The Boundary or change request has no name | Enter one |
A score (0-100) is required | The Boundary's action is Score, but the score is missing or outside 0-100 | Enter a score in range |
Invalid Source CIDR or IP: <value> | A source is neither a valid IP address nor a valid CIDR. Destinations report the same way | Correct the value |
Source cannot be The Internet. Use specific CIDRs, groups or inventory items in a change request. | The Internet belongs in a Boundary, which judges addresses, not in a request, which states them. Destinations report the same way | Replace it with specific CIDRs, Groups or inventory items |
Invalid custom protocol: <value> | The IP protocol number is outside 0-254 | Correct it |
Invalid TCP port start: <value> | The port is outside 0-65535. UDP, and the end of a range, report the same way | Correct it |
Invalid TCP port range: <start> to <end> | The first port is higher than the last | Swap them |
Invalid ICMPv4 type: <value> | The ICMP type is outside 0-254. ICMPv6, and ICMP codes, report the same way | Correct it |
sourcesMaxHosts should be undefined or greater than zero. | One of the statement's host or port limits is zero or negative. The other five limits report the same way, each naming its own field | Clear the field, or enter 1 or more |
Invalid internal CIDR or IP: <values> | An entry in your internal address space under Settings > Boundaries is not a valid IP or CIDR | Correct the entries listed and save again |
The API rejects an incomplete source, destination or service with a message naming the field it needs, such as CIDR value is required or TCP portStart and portEnd are required. The Connect app can't produce these. See Change request schema.
Permissions and availability
| Message | What it means | What to do |
|---|---|---|
Connect is not enabled for client <id> | Your organization doesn't have Connect enabled | Contact FireMon Support |
Resource lists are not enabled for client <id> | Your organization doesn't have Groups enabled. Some messages call a Group a resource list | Contact FireMon Support |
Decommission workflows are not enabled for client <id> | Your organization doesn't have Decommission enabled | Contact FireMon Support |
Change requests can only be updated by an admin, the original creator, or the last updater. | You didn't create or last change this request, and you aren't an administrator | Ask its creator, or an administrator, to make the change |
Change requests can only be deleted by an admin, the original creator, or the last updater. | The same rule, applied to deleting | As above |
The update type and project of a decommission workflow cannot be changed. | Update and Project are fixed when a workflow is created | Create a replacement workflow with the values you want, then delete the original |
Unauthorized, Permission denied | Your roles don't cover this action in this project | See Users and roles |
Credentials are only accessible by administrators. | Group Credentials can be viewed only by an administrator | Ask an administrator |
Credentials can only be modified by administrators. | The same, applied to changing them | As above |
Error getting permissions: <message> | The app couldn't load your permissions | Reload the page. If it persists, sign out and back in |
Missing ID token | Your session has expired | Sign in again |
Not found
These mean the item is gone, or was never there. A browser tab left open while someone else deleted the item is the usual cause. Reload the page, then check whether the item still exists.
| Message | Shown when |
|---|---|
Boundary not found | Opening or deleting a Boundary |
Change Request not found | Opening, evaluating or deleting a change request |
Resource list not found, List not found | Opening, saving or deleting a Group |
Nested resource list not found | Removing a nested Group that has already gone |
Resource list member change candidate not found | Applying a pending membership change that has already been applied |
Resource list member change candidate action of <a> does not match the specified action of <b> | Applying a pending change that has changed since the page loaded |
Workflow not found, Decommission Workflow <id> not found | Opening, saving or deleting a decommission workflow |
Match not found | Acting on a decommission candidate that has already gone |
Client settings not found | Reading settings your organization has never saved |
Dynamic list URL
Errors returned by the URL that serves a Group's addresses to a firewall. See Dynamic lists.
| Message | What it means | What to do |
|---|---|---|
Not Found | The URL isn't in the expected form | Copy it again from the Group's page |
List not found | The URL is well-formed, but names a Group that no longer exists | Copy the current URL from the Group's page |
Missing Authorization header | The request carried no credentials | Send HTTP basic authentication |
Missing password or API Key in Authorization header | A username was sent with no password | Send both |
Missing username in Authorization header | A password was sent with no username, and it isn't a valid API key | Send both |
Invalid API Key | The API key belongs to a different organization | Use a key from the organization that owns the Group |
Invalid credentials | Neither the API key nor the username and password matched | Check the credentials under Settings > Group Credentials, or use an API key as the password with the username shown on the Group's page |
In the Connect app
Form validation names the field it applies to.
| Message | What it means |
|---|---|
<Field> is required | A required field is empty, named by its own label: Password is required, Connector is required, Tenant ID is required, and so on |
Name must be less than 128 characters | The account name is too long |
Provider is required, Project is required | Both are set when the account is created, under Integrations |
Password, secret and token fields are never shown back to you, so they're empty each time the Provision page opens and have to be re-typed on every save, including a save that changes only another field. Password is required on a page where you didn't touch the password is expected: your other edits are still in the form, so re-enter the password and save again.
Messages shown at the top of the page:
| Message | What it means | What to do |
|---|---|---|
Error saving | The account couldn't be saved, and no reason was returned | Check the form for a validation message, then try again |
There was an error deleting the account | The account couldn't be deleted | Reload the page and try again |
Error deleting <name>: <detail> | A delete failed. <detail> is the reason | Act on the reason given |
Error updating decommission candidate. | A decision on a candidate wasn't saved | Reload the page and try again |
Decommission candidate updated, but some details failed to refresh. Reload the page to see the latest status. | The decision was saved. Only the display failed to update | Reload the page. Nothing was lost |
Failed to save <n> nested group changes | Some nested Group changes weren't saved. The rest of the Group was | Reopen the Group and check its nested Groups |
Error(s) encountered while applying changes: <n> | Some pending membership changes couldn't be applied | Reload the page and apply the ones still listed |
Error loading more members., Error loading more matches., Error loading more changes. | The next page of a table didn't load. What's already shown is still accurate | Scroll again, or reload the page |
Could not read the selected file as a boundaries JSON export. | The file isn't a Boundaries export | Use a file produced by Export on the Boundaries page |
Please select one or more pre-defined filters or enter your own search term before saving. | A saved search can't be empty | Add a filter or a search term |
Choose a project for each role before saving. | A role was assigned without a project | Choose a project for each role |
Failed to save search. Please try again. | A saved search couldn't be stored. Deleting one, and setting a default, report the same way | Try again |
There was an error loading settings: <detail> | The Boundaries settings page couldn't load | Reload the page |
When importing a CSV on the Integrations page, each row that can't be used lists its reasons:
| Message | What it means | What to do |
|---|---|---|
No ID | The row has no identifier | Choose the right Unique ID Column, or fill the value in on the row |
No IPs | The row has no addresses | Choose the right IP Column. Several addresses in one cell can be separated by spaces, semicolons or pipes |
No Region | The row has no region | Set a fixed Location / Region, or choose a column that has a value on every row |
<n> of the rows below could not be uploaded. | Rows passed the checks above but were rejected on upload. Each one shows its reason under Details | Correct those rows and import the file again. Rows that uploaded aren't affected |
Still stuck
Note the exact message, the job or account it came from, and roughly when it happened, then contact FireMon Support. Connector logs are forwarded to FireMon, so Support can usually see the full error without you collecting files. See Security & Data Protection.