Troubleshooting · 7 min read
Why you cannot connect to a remote computer, and how to fix it
Written for: Support staff and IT administrators diagnosing a remote session that will not establish at all.
In short
A failed remote connection is almost always one of four things: the device is off or asleep, the agent is not running, something on the network is blocking the outbound connection, or your credentials are being rejected. Work through them in that order. Each check rules out a whole class of cause, so you narrow the problem in four steps instead of guessing at settings.
Key takeaways
- Diagnose in layers: power, agent, network, credentials. Guessing at settings wastes the most time.
- A device showing offline in the console has not necessarily failed — it may be asleep, on a different network, or waiting on a captive portal.
- Modern remote support tools connect outbound over 443, so an inbound firewall rule is rarely the cause; an outbound proxy or TLS inspection often is.
- An error that mentions credentials, permission or authorisation is a different problem from one that times out. Do not treat them the same.
- Record what fixed it. The same device usually fails the same way twice.
Step one: prove the device is actually on
It sounds trivial, and it is the single most common answer. A desktop that has gone into sleep or hibernation, a laptop closed on a desk, a machine someone switched off at the wall over the weekend — none of these are reachable, and no amount of configuration will change that.
Check the last-seen timestamp in your console before anything else. A device that was online an hour ago and is now unreachable tells a very different story from one that has not checked in for three weeks.
- Last-seen time in the management console
- Whether the machine is on a power plan that sleeps the network adapter
- Whether wake-on-LAN is configured and the machine is on a wired connection
- Whether anyone on site can confirm the power light
Step two: is the agent running?
If the machine is on but shows offline, the agent service is the next suspect. Agents get stopped by well-meaning cleanup scripts, disabled by endpoint protection after an update, or left in a failed state after a patch cycle that did not complete cleanly.
Where you have another route in — a domain admin share, an RMM agent, a colleague at the desk — check that the service exists, is set to start automatically, and is actually running. A service set to Manual will survive a reboot in name only.
Step three: rule out the network path
Remote support tools of this generation connect outbound over TCP 443, the same port a browser uses, precisely so they work without inbound firewall changes. That makes the classic 'open a port' advice largely obsolete — and means when the network is at fault, it is usually something more subtle.
The usual culprits are an outbound proxy the agent has not been told about, TLS inspection breaking certificate pinning, a guest or captive-portal network that has not been authenticated, or a DNS failure that stops the agent resolving its broker address at all.
- Can the machine reach a normal HTTPS site? If not, the problem is the network, not the tool.
- Is there an explicit proxy configured for browsers but not for services?
- Is TLS inspection or a next-gen firewall rewriting certificates?
- Does the device sit on a guest SSID with a portal that expires daily?
Step four: separate reachability from authorisation
Read the error text carefully. A timeout, 'host unreachable' or a spinner that never resolves means you never got there. 'Access denied', 'not authorised' or an immediate rejection means you got there and were turned away — the device is fine, and the problem is your account, your group membership, or a policy that does not grant you that device.
That distinction saves hours. Teams routinely dig through firewall logs for what turns out to be an operator who was removed from a device group.
Diagnosing a failed connection, in order
1. Check last-seen and power state
Look at when the device last checked in. If it is hours or days ago, treat it as a powered-off or sleeping machine until proven otherwise.
2. Confirm the agent service
Verify the agent service exists, is set to automatic start, and is running. Restart it and see whether the device reappears in the console.
3. Test general internet reachability
From the device, or from a machine on the same subnet, confirm ordinary HTTPS traffic works. This separates a tool problem from a network problem in one test.
4. Check proxy, TLS inspection and DNS
Confirm the agent has the proxy details it needs, that inspection is not breaking the TLS handshake, and that the broker hostname resolves.
5. Read the error text
Timeout means unreachable. Denied means unauthorised. Check your account's group membership and device permissions before touching the network again.
6. Write down the fix
Note the device, the symptom and the resolution. Recurring failures cluster on the same handful of machines and sites.
Common mistakes
- Reinstalling the agent as a first step. It sometimes works, which is why it is dangerous — you learn nothing and the cause returns.
- Opening inbound firewall ports for a tool that only connects outbound, leaving a permanent hole for no benefit.
- Assuming a device is broken when it is simply asleep on a power plan nobody reviewed.
- Testing from your own machine only. If you are on a different network from the user, you are not testing the same path.
Frequently asked questions
- Why does the device show offline when the user says it is on?
- The machine can be powered on while the agent is stopped, the network adapter is asleep, or the device is on a network with an unauthenticated captive portal. Check the agent service and general internet reachability from the device itself.
- Do I need to open firewall ports for remote support?
- Usually not. Modern remote support tools connect outbound over TCP 443. If it is failing, look at outbound proxies, TLS inspection and DNS rather than inbound rules.
- What is the difference between a timeout and access denied?
- A timeout means the connection never reached the device — a power, agent or network problem. Access denied means it reached the device and rejected you — an account, group or policy problem.
- Why does it work on the office network but not from home?
- Different network path. Home connections introduce ISP-level filtering, different DNS and sometimes a router blocking uncommon traffic. Test general HTTPS from the same connection to establish a baseline.
How this works in 247connect
247connect agents connect outbound over standard HTTPS and report their last-seen state in the console, so the first two diagnostic steps above are visible without touching the device.
More troubleshooting guides
Session keeps disconnecting
How to diagnose remote sessions that drop repeatedly: distinguishing network instability from idle timeouts, power management and Wi-Fi roaming, and what to change to keep long sessions alive.
Black screen in a remote session
Why a remote session connects but shows only a black screen, covering the secure desktop, graphics drivers, headless machines, multi-monitor states and display capture permissions.
Slow or laggy remote session
Diagnosing a sluggish remote session: separating latency from bandwidth, the effect of resolution and colour depth, wireless links, and the settings that make the largest practical difference.