SonicWall | Troubleshoot "timed out while waiting for handshake" error

Overview 💥

When a SonicWall inspection fails with the error message similar to:

timed out while waiting for handshake

This indicates the SSH handshake between the Liongard Agent and the SonicWall device did not complete within the allotted time. The handshake timeout is commonly caused by network latency, device slowness, wrong port/protocol, or insufficient readyTimeout (the SSH client’s wait time for the server to complete the SSH handshake).

This article walks you through diagnosis, remediation, and best practices.

Why this happens? 🤔

The SSH handshake timeout occurs when the client (Liongard Agent) initiates a connection but does not receive the server’s SSH banner/response in time. Typical root causes:

Network latency or packet loss between agent and appliance (WAN links, congested hops).
Firewall / routing delays or transient drops that slow the connection.
SonicWall overloaded or busy (CPU, memory, or internal process delays).
SSH service not enabled or listening on a non-standard port.
Rate-limiting or connection throttling on the SonicWall or upstream device.
Agent readyTimeout value too low for the environment (handshake exceeded timeout).
Certificate/TLS negotiation issues (if using API/HTTPS instead of SSH).
Incorrect credentials or authentication method (less common for handshake timeouts but possible).

Quick checklist 📝

Is the Liongard Agent host on the same network path to the SonicWall as before?
Can you ssh (or connect via the configured port) from the agent host to the SonicWall?
Is the SonicOS SSH service enabled and listening on the expected port?
Are there any device-side logs showing slow responses or high CPU?
Try increasing readyTimeout and re-run the inspector.

Steps To Resolve 👨‍💻

‼️ Important: Execute tests from the same host that runs the Liongard Agent (this replicates the agent’s network view).

1️⃣ — Verify basic network reachability

Linux / macOS

# ping 
ping -c 5 <sonicwall-ip>  

# traceroute for path and latency 
traceroute <sonicwall-ip>

Windows (PowerShell)

Test-Connection -ComputerName <sonicwall-ip> -Count 4 tracert <sonicwall-ip>

What to look for:

High packet loss or very high latency → investigate network/WAN.
Long or asymmetric routes → talk to network team to reduce latency.

2️⃣ — Confirm SSH service & port

Default SSH port is 22 (SonicOS v6 typically uses SSH). Some environments change it.
For SonicOS v7 the Inspector often uses HTTPS/API; ensure you’re testing the correct protocol.

Check port reachability (Linux):

# check TCP connect on port 22 (or your configured port) 
nc -vz <sonicwall-ip> 22       

# or 
timeout 5 bash -c ">/dev/tcp/<sonicwall-ip>/22" && echo "open" || echo "closed"

Windows PowerShell

Test-NetConnection -ComputerName <sonicwall-ip> -Port 22

If the port is closed/refused — fix firewall/NAT or use the correct port in Inspector config.

3️⃣ — Try an interactive SSH from the agent host (verbose)

This shows the handshake progress and where it stalls.

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

What to watch:

DNS resolution delays (use IP to rule this out).
Long pauses before the server banner or key exchange.
Connection timed out or Connection reset messages.

If the verbose SSH shows the server banner but then stalls on key exchange, that’s a server-side performance/CPU or rate-limit issue.

4️⃣ — Check SonicWall device health & logs

On the SonicWall appliance:

Check CPU/memory usage and active processes. High CPU can slow the SSH service.
Review system logs for SSH connection attempts, rate limiting, dropped connections, or error messages.
If the device was recently updated or is experiencing high load, rebooting during a maintenance window can help.

5️⃣ — Look for firewall / intermediate device rate limits

Verify intermediate firewalls, routers, or IDS/IPS appliances are not throttling or scanning SSH connections.
If there is a load balancer or NAT device in front of the appliance, confirm it forwards and does not terminate/inspect the SSH handshake in a way that slows it.

6️⃣ — If using a non-standard SSH port, ensure Inspector matches it

If the SonicWall is configured to use a custom SSH port (e.g., 2222), set that port in the Inspector configuration.

7️⃣ — Increase the Agent's `readyTimeout` value

If network latency or device response time is expected to be slow (e.g., remote site over WAN), increasing the SSH `readyTimeout` lets the client wait longer for the handshake.

Typical guidance: increase to 30000 ms (30s) initially. If needed, try 60000 ms (60s).
How to change: edit the Inspector's advanced settings where readyTimeout is available (or the agent configuration / inspector template where SSH options are exposed).
- Some deployments expose an advanced SSH JSON or parameter area — update readyTimeout to 30000 or 60000.
- After adjustment, run the inspector in Clear Cache + Debug Mode.

Note: raising readyTimeout masks underlying latency rather than fixing it — use it as a pragmatic workaround while addressing root network/device causes.

8️⃣ — Re-run Inspector in Clear Cache + Debug Mode

Run the inspector with Clear Cache + Debug Mode.
Download the debug log and the agent host SSH output to cross-check timestamps and handshake behavior.

Troubleshooting summary 🤩

Symptom	Likely cause	How to confirm	Recommended action
Handshake stalls for many seconds then times out	High network latency or packet loss	`ping`, `traceroute` from agent host	Fix network path, optimize WAN, or move agent closer
Verbose SSH shows banner but stalls during key exchange	Device overloaded / CPU heavy	Check SonicWall CPU/memory, session counts	Reduce load, investigate processes, schedule maintenance reboot
Port unreachable / connection refused	Wrong port or firewall blocking	`Test-NetConnection` / `nc -vz`	Open port, correct NAT, update Inspector port
Repeated short stalls then timeout	Rate-limiting / IDS/IPS interfering	Inspect intermediate appliance logs	Add allow rules, bypass inspection for agent IP
Works interactively but Inspector still times out	`readyTimeout` too low	Increase `readyTimeout` and rerun	Set to 30s/60s and monitor; fix root latency later

Best practices & recommendations 🌟

Run network tests and authentication tests from the agent host, not from a random workstation. Agent view is authoritative.
Keep the management path low-latency: if possible, run the Liongard On-Premises Agent on a host in the same LAN/VLAN as SonicWall.
Document and standardize SSH/management ports across SonicWall fleet to avoid configuration drift.
Use readyTimeout conservatively — set to what the worst realistic network latency requires (30–60s) and still work to improve network health.
Monitor SonicWall CPU/memory and session utilization; schedule inspections away from known maintenance or peak periods.

When to contact Support 🦁

Open a ticket when:

You validated connectivity from the agent host and increased readyTimeout but the Inspector still times out.
SonicWall logs show the connection attempt but no obvious rejection reason.
You suspect a SonicWall firmware bug (provide version/build) or an intermittent infrastructure issue.

What to collect before contacting Liongard Support

Liongard Inspector debug log (Clear Cache + Debug Mode).
ssh -vvv output (from agent host) including timestamps.
ping and traceroute (or Test-NetConnection) outputs from agent host to SonicWall.
SonicWall logs showing SSH connection attempts and any errors (with timestamps matching the inspector run).
SonicOS version/build and configuration notes (SSH port, rate-limiting settings, Trusted Hosts).
Any recent network changes, firmware updates, or configuration changes.

Attach the items to your Support ticket.

Commands summary 🧑‍🏫

From Agent host (Linux / macOS):

ping -c 5 <sonicwall-ip>

traceroute <sonicwall-ip>

nc -vz <sonicwall-ip> <port>        # check TCP port open

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

From Agent host (Windows PowerShell):

Test-Connection -ComputerName <sonicwall-ip> -Count 4

tracert <sonicwall-ip>

Test-NetConnection -ComputerName <sonicwall-ip> -Port <port>
# To capture verbose SSH-like behavior on Windows, use PuTTY/plink with verbose flags

References & external links 📚

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.