Your company blocks remote access tools. What is actually happening

A remote access tool that works everywhere else fails at the office, and the error tells you nothing useful. Three different systems could be responsible, and which one it is changes what a reasonable request to IT looks like.

What is blocking you

Category-based web filtering. A proxy matches the domain against a commercial category list — "Remote Access" and "Proxy Avoidance" are standard categories — and refuses the connection. You usually get a branded block page naming the category. This layer is honest about itself.

Port and protocol restriction. Many corporate networks allow only TCP on 443 and 80 outbound. Remote access tools prefer UDP for the media path because it is lower latency, so the signalling succeeds, the session looks like it is starting, and then it never connects. This produces the specific symptom of a connection that gets almost all the way and stalls.

TLS inspection. The proxy terminates HTTPS, inspects the plaintext, and re-encrypts with an internal certificate the managed device trusts. Tools that pin certificates — as many security-conscious ones do — refuse the substituted certificate and fail closed. The tool is behaving correctly; it is detecting exactly the interception it was designed to detect.

Endpoint controls. The block is not on the network at all — application allowlisting or the EDR agent prevents the executable from running or from opening a socket. Symptom: the installer completes and the application either does not launch or launches and cannot reach anything, on any network, including your phone hotspot.

Why it exists

Worth understanding rather than resenting, because it changes what a reasonable request looks like.

• Unmanaged inbound access. A remote access tool creates a path into the corporate network from outside it, bypassing the VPN, the gateway and every control attached to them. From a security team's point of view that is the definition of the thing they exist to prevent.
• Data exfiltration. A remote session with clipboard and file redirection is a channel out of the building that no DLP system inspects.
• Support scam exposure. Blocking consumer remote access tools by category is one of the few controls that actually works against staff being talked into installing one — see how the support scam works.
• Compliance. In regulated environments the organisation must be able to say who accessed what. An unlogged session is a hole in that record regardless of intent.

What not to do

Personal hotspot, a consumer VPN, a portable build that does not need installing, a tool that is not on the list yet. These work often enough to be tempting and are close to always the wrong move.

The attempt is logged. Proxy and EDR systems record blocked and circumvented attempts, and deliberate circumvention reads very differently in a review than an honest failure. In many organisations it is a disciplinary matter in its own right, independent of what you were trying to do.

And the control is usually right. If you need a path into a corporate machine from outside, that is exactly the capability the security team is responsible for governing. Routing around it does not make you wrong about the need; it makes you the person who opened an unlogged path into the network.

What to ask for instead

1. The sanctioned remote access. Almost every organisation with a block has a paid alternative — a VPN plus RDP, a VDI environment, a managed remote support tool for the helpdesk. It is usually already licensed and usually nobody told you.
2. An allowlist entry, with specifics. "This domain, for this machine, for this business reason, for this period" is a normal ticket. "Remote access is blocked" is not.
3. Reverse the direction. Ask IT to connect to you rather than you to them. Inbound support sessions are frequently permitted where outbound ones are not, because the risk profile is different.
4. Use it for personal machines only, from personal devices. The cleanest resolution to most of these: your home PC is not the company's concern, and a personal laptop on the guest network is a different conversation from a managed device on the corporate LAN.

If you run the network

Blocking the category outright is the blunt instrument and it pushes people toward worse tools. The more effective pattern is to sanction one tool, deploy it centrally, log it, and block the rest — staff get a supported path, you get an audit trail, and the shadow-IT pressure that produces the risky installations goes away. See what your logs should show for what to require from whatever you pick.

More guides