Network Management

NCM Error: Connection Refused by A.B.C.D

This article describes the issue when the connection is refused when establishing a Telnet/SSH session between NCM and the end device.

First published date

11/27/2018 5:51 PM

Last published date

7/23/2025 6:21 PM

Overview

The error is seen when one has NCM set to connect to a device s: 

Test failed. Connection Refused by A.B.C.D

or when initiating a vty connection with a device via SSH or Telnet

Transfer Status: Connection Refused by A.B.C.D

where A.B.C.D represents the IP of the end node.

Product section

Network Configuration Manager

Cause

Scenario 1: Environmental issue

Common causes:

  • Telnet/SSH services are not configured correctly or services not enabled
  • Wrong credentials
  • Lack of privileges
  • Security in place, not allowing traffic to or from the NCM server
  • Can also happen if a connection is dropped on the device side
  • Encryption/Ciphers are not supported on the NCM side

 

Resolution


In order to rule out any of the mentioned causes, try to connect to the device by using a Telnet/SSH client (like Putty) from the Orion server; or more precisely from the Polling Engine to which the node is assigned.

One should make sure to use the same credentials and Protocols as configured in NCM.
Make sure the tests are performed from the Orion Poller the device is assigned to
 

Case 1: You cannot establish a connection and get the same Connection refused error:

  • Engage your networking team to check the firewalls (both hardware in the network, or software running on the server) and other networking devices that might be blocking the traffic with an access list (routers, switches, etc.).
  • Check if the required Telnet or SSH service and version are properly configured and enabled on the device.
  • Make sure the user account used by NCM has sufficient privileges to not only connect to the device but at a level to execute the commands to perform the task.

Case 2: Connection successful.

If you managed to connect successfully proceed with troubleshooting by following the steps in Scenario 2.

Scenario 2 

Since it has been confirmed that the traffic flow is allowed and all the settings are in place on the device, make sure everything is properly configured on the NCM side:

  1. Edit the Node, and check the NCM-related settings.
  2. Select the node > click Edit Node > scroll down to NCM Properties, check the following:
    1. Switch to "No Profile" under Global Connection Profile.
    2. Use the same Username and Password as you used during Scenario 1. If applicable fill in the Enable Level and Enable Password details.
    3. Hard-code the "Execute Scripts Using", "Request Configs Using" and "Transfer Configs Using" to the protocol you used in Scenario 1.
    4. Set the telnet and SSH ports to 23 and 22 respectively.
    5. Hard-code the appropriate template under Device Template.
    6. Verify the command in the device template is the correct command, if not you will probably be better off creating a duplicate of the template used and modifying the command and then using it.
    7. Click Test.
      Note: The test can give you a false positive or false-negative result. We recommend trying to initiate a backup regardless of the outcome of the test.
    8. Click submit and initiate the configuration backup once again.

    Note: If you followed all the steps from both scenarios and the issue still persists collect a log file (see Generate session trace logs) with the issue reproduced and submit a ticket to the SolarWinds Technical Support to get further assistance.