SonicWall | Connection refused with: connect ECONNREFUSED

Overview 💥

If your SonicWall Inspector shows an error like:

Unable to reach https://IP:Port/api/sonicos/auth because of ECONNREFUSED: connect ECONNREFUSED IP:Port. This probably means the hostname/port is wrong, the target is down, there is a problem with its certificate, or the network is not working. This is not a problem in the Liongard inspector.

that indicates the Liongard agent could not establish a TCP connection to the SonicWall device at the address and port shown. This is a network / connectivity rejection — the device explicitly refused the connection — not an Inspector authentication error.

This article explains the common causes, step-by-step checks (including commands you can run from the agent host), how to remediate the problem, and what to collect before contacting Liongard Support.

Why this happens? 🤔

ECONNREFUSED is returned when a TCP connection attempt reaches the host but the host refuses the connection on that port. Typical causes:

The SonicWall management service is not listening on the requested port (service disabled or wrong port).
The SonicWall is offline or unreachable from the agent host.
Firewall, ACLs, or security groups block the agent’s source IP or the destination port.
NAT or reverse-proxy misconfiguration (traffic not forwarded to the appliance management port).
Management interface is bound to a different network (agent on wrong subnet).
For SonicOS v7: HTTPS/TLS issues (agent blocks due to certificate verification) may appear similar if TLS handshake fails early.
For SonicOS v6: SSH not enabled / port closed if the inspector is trying to use SSH for that version.
Intermediate device (proxy/WAF) is actively rejecting the connection.

Quick checklist (run first)

Note the exact IP:PORT reported in the error.
From the Liongard agent host, test connectivity to that IP:PORT from your browser :
Further checks are provided below in this docs.
Confirm the SonicWall is powered on and listening on the management port.
Confirm firewall/NAT/ACLs allow traffic from the agent host to the appliance.
Re-run the Inspector in Clear Cache + Debug Mode after making fixes.

Step-by-step resolution 👨‍💻

Run these steps from a host on the same network as the agent (ideally on the agent host itself).

1️⃣ — Validate the Target IP and Port

Double-check the Inspector configuration: is the IP/FQDN and port correct?
Many errors come from a small typo in the hostname or port.

2️⃣ — Basic network reachability

✅ Ping (ICMP) — quick reachability test

ping -c 4 <sonicwall-ip>

If ping fails, the device may be offline or ICMP blocked (still proceed to port checks).

✅ TCP port test

PowerShell (Windows agent host):

Test-NetConnection -ComputerName <ip> -Port <port> -InformationLevel Detailed

Linux/macOS:

# using nc (netcat) 
nc -vz <ip> <port> 
# or using telnet 
telnet <ip> <port>

Interpretation:

succeeded / open → port reachable
connection refused → host reachable but not listening
timed out → traffic blocked / filtered

3️⃣ — Confirm SonicWall is listening on that port

Log into the SonicWall management console (or use the console access) and check management settings:
- For SonicOS v7: management via HTTPS (default port 443) — ensure HTTPS is enabled and the correct interface is bound.
- For SonicOS v6: management may be via SSH (default port 22) — ensure SSH is enabled if your inspector expects SSH.
If the SonicWall web UI is accessible from your workstation, confirm the management IP/port displayed in System settings.

4️⃣ — Check firewall / allowlist rules

On SonicWall: verify the Management Access or Trusted Hosts settings are not restricting the agent IP.
If your network uses an upstream firewall or router, confirm it allows traffic from the agent’s source IP to the SonicWall management IP and port.
If NAT is in use, confirm NAT rules forward the external IP/port to the correct internal management IP/port.

5️⃣ — Test direct HTTPS/SSH connection (protocol verification)

HTTPS (SonicOS v7 and later):

# from agent host 
curl -v https://<ip>:<port>/ -I 
# or to ignore certs (test only) 
curl -k -v https://<ip>:<port>/

curl errors such as Connection refused confirm port not listening; TLS errors (handshake failure) indicate certificate/cipher issues.

SSH (SonicOS v6):

ssh -vvv <user>@<ip> -p <port>

Connection refused = port closed
Authentication failures are different — they indicate SSH is reachable but credentials wrong.

6️⃣ — SSL / certificate trust (v7)

If the port is reachable but TLS fails, run:

# openssl check 
openssl s_client -connect <ip>:<port> -servername <fqdn>

Look for certificate chain errors or mismatched hostnames. If the agent host does not trust the appliance certificate, either:

import the appliance certificate into the agent host trust store, or
configure the inspector/agent to trust the cert (if your policy allows). Review SonicWall documentation for more details.

7️⃣ — NAT / Reverse proxy considerations

If the inspector attempts to reach public.domain.tld:443 and you have a reverse proxy:

Validate that the proxy forwards the request directly to the SonicWall management backend and preserves required headers.
Verify that the proxy is not intercepting or blocking the agent’s requests (some proxies block non-browser agents by default).

8️⃣ — Check SonicWall logs and management settings

Inspect System Logs for dropped packets, blocked management attempts, or any messages referencing the agent’s IP.
Check Device | Administration | Management and Firewall settings for access restrictions.

9️⃣ — Confirm agent network path

Ensure the Liongard agent uses the expected outbound IP (NAT may change it). If SonicWall only allows specific IPs, update allowlist entries accordingly.
If the agent is behind a proxy, verify proxy settings are correct and the agent is allowed to exit to the destination.

1️⃣0️⃣ — After fixes: re-run the Inspector (Clear Cache + Debug)

In Liongard: go to the Inspector and choose Run → Clear Cache + Debug Mode to force a fresh collection and capture verbose logs.

Commands quick reference 🌟

Windows agent host

Test-NetConnection -ComputerName <ip> -Port <port> -InformationLevel Detailed

Linux/macOS agent host

# check TCP port 
nc -vz <ip> <port> 
# or 
telnet <ip> <port> 
# curl HTTPS 
curl -v https://<ip>:<port>/ -I 
# openssl TLS debug 
openssl s_client -connect <ip>:<port> -servername <fqdn>

Common scenarios & fixes 🤩

Symptom	Likely cause	Recommended fix
`ECONNREFUSED` immediately	Service not listening on port	Verify correct port & enable management interface on SonicWall
`Connection timed out`	Network/filtering between agent and device	Check firewall/NACLs, routing & NAT
Works from browser, not agent	Agent host trust/certs or agent network	Validate agent trust store, proxy settings, source IP allowlist
Works internally but not externally	NAT/reverse-proxy misconfigured	Fix NAT/proxy forwarding or use standard HTTPS port (443)
TLS handshake errors	Invalid/mismatched cert or unsupported cipher	Import cert into agent trust store or update ciphers

Best practices / recommendations 🧑‍🏫

Use static management IPs for SonicWall appliances where possible.
Prefer standard management ports (HTTPS 443) for external access — avoids custom NAT complexity.
Document allowlisted agent IP addresses and update after network/NAT changes.
After firmware upgrades, verify management & API settings; reboots may be required.
For TLS-managed devices, keep CA chains in sync with agent hosts (or use publicly-signed certs).

When to contact Liongard Support 🦁

Open a Support ticket if you’ve completed the steps above and:

The agent host shows connection refused but SonicWall is confirmed online and listening.
SonicWall logs show no incoming connection attempts from the agent (suggests routing/NAT issue).
You cannot determine the correct management port or the environment uses complex proxies/NAT.
Include all artifacts listed in the “What to collect” section.

What to collect before contacting Support :

Gather these items to accelerate diagnosis:

Full Inspector debug log (run Clear Cache + Debug Mode and download logs).
Output of connectivity tests from the agent host:
- Test-NetConnection or nc/telnet results.
- curl -v / openssl s_client output (if HTTPS).
- Screenshot of test connectivity to that IP:PORT from your browser.
SonicWall System Logs screenshots around the failure times.
SonicOS version and build number.
Exact IP:PORT shown in the error.
Network diagram or NAT rules if a reverse proxy/NAT is involved.
Any recent changes (firmware, network, firewall rules) with timestamps.

Attach these to your Liongard Support ticket.

References & further reading 📚

Third-Party Link Disclaimer ‼️

We may reference external third-party resources solely as additional guidance.

Liongard does not own, control, or guarantee the accuracy, security, or reliability of third-party sites. Please use them at your own discretion and risk.