TeamViewer or AnyDesk Blocked by Your Client's Corporate Firewall

Why Corporate Firewalls Block Remote-Access Tools in the First Place

Remote-access software is one of the most common attack vectors security teams train for, because it does exactly what a hacker wants: it gives an outside device control of a machine inside the network. TeamViewer, AnyDesk, and similar tools have also been the specific method used in real, publicized breaches — attackers cold-call employees, talk them into installing a remote tool, and take over the machine. IT departments know this, and after any security review, penetration test, or industry incident, one of the first things a network admin does is check what remote-access traffic is leaving the building and lock it down.

Technically, this happens at a few layers. Firewalls maintain blocklists of the IP ranges TeamViewer's and AnyDesk's relay servers use, since both tools publish (or leak) predictable server ranges. Deep packet inspection appliances can fingerprint the tools' connection handshake even if you change the port, because the protocol signature doesn't look like normal web traffic. And some firewalls simply block outbound traffic on the non-standard ports these tools prefer, allowing only 80 and 443 out. None of this is personal — it's usually a blanket corporate policy applied to every desktop, and your contractor session got caught in it along with everything else.

Remote Tools That Are More Likely to Get Through

The tools with the best odds of surviving a locked-down firewall are the ones that tunnel entirely over HTTPS on port 443 and don't rely on a separate relay protocol. Chrome Remote Desktop is the most reliable of these in practice: it runs as a browser extension, authenticates through a Google account, and the entire session rides over standard TLS web traffic that's indistinguishable from someone loading a webpage. Because almost every corporate network has to allow port 443 outbound for the business to function at all, blocking Chrome Remote Desktop specifically means blocking Google's own infrastructure, which most IT teams won't do.

Microsoft Quick Assist behaves similarly on Windows machines already inside a Microsoft 365 environment, since it's a signed Microsoft binary talking to Microsoft's own servers — it's far less likely to trip a blocklist built around known third-party remote-access vendors. RustDesk and other self-hosted relay options can also be configured to run over 443, though that requires someone to set up the relay server in advance, which isn't realistic mid-contract. If none of these are viable and the client is using a corporate VPN for other work anyway, connecting the contractor's machine to that same VPN and using file-share-based tools for the actual work (rather than a live remote session) is sometimes the only path left.

Browser-Based Remote Access: No Install, No New Executable to Flag

A separate reason installed remote-access clients get blocked is that they show up as a new, unrecognized executable running on a managed device, which triggers endpoint protection software (CrowdStrike, SentinelOne, Defender for Endpoint) independently of the firewall. Browser-based options sidestep this because nothing new gets installed — the client's antivirus sees a browser tab, not a new process. Chrome Remote Desktop again fits here, along with Chrome's own "Remote Desktop" web app at remotedesktop.google.com, which needs only a one-time extension install rather than a standalone application.

Some newer tools go further and run entirely inside the browser with WebRTC, meaning there's no extension and no executable at all on the host side — the trade-off is these tend to have weaker feature sets (no file transfer, no multi-monitor support, sometimes capped session length) and are less battle-tested for reliability over a flaky connection. For a virtual assistant who just needs to screen-share and click around in a client's CRM or accounting software for twenty minutes, that trade-off is usually fine. For anything requiring sustained control, large file transfers, or admin-level access, it's worth confirming the browser tool supports what the job actually needs before relying on it as the fix.

What to Realistically Ask the Client's IT Department to Whitelist

The request that gets approved is narrow and specific, not general. "Can you unblock TeamViewer" reads to an IT admin as "can you undo our security policy company-wide," and the honest answer is almost always no — they didn't build that rule for fun, and reversing it for one contractor creates a policy exception they now have to track and justify at the next audit. What works better is naming the exact tool, the exact destination, and the exact person: "Can you whitelist outbound access to [specific domain, e.g., remotedesktop.google.com] for [your name/device] so I can continue the contracted work on [system]." That's a scoped, auditable exception an admin can approve in minutes because it doesn't touch the broader policy.

It also helps to have the client (not you) make the request internally, since IT is far more likely to act on a ticket from an employee or manager than from an external contractor they don't have a direct relationship with. If the client has any weight in the organization, a two-line message from them — "our VA needs this specific tool whitelisted to keep working on X" — moves faster than any explanation you could give directly. Framing it around business continuity ("this contractor supports payroll/customer support/whatever the actual function is") also tends to get faster sign-off than framing it around the tool itself.

What's a Dead End (And When to Stop Pushing)

Some requests simply won't get approved, and pushing on them wastes goodwill you'll need later. Asking a regulated company (healthcare, finance, legal, government-adjacent) to whitelist a consumer remote-access tool company-wide is close to a guaranteed no — these industries often have compliance frameworks (HIPAA, SOC 2, PCI-DSS) that explicitly restrict or prohibit third-party remote-access software, and no single IT admin has the authority to override that even if they wanted to. Similarly, if the block is coming from a next-gen firewall doing deep packet inspection rather than a simple port block, no amount of port-hopping or renaming the executable will help, because the appliance is reading the traffic pattern itself, not just the destination.

If you hit that wall, the realistic path forward is renegotiating how the work gets done rather than how you connect. That can mean the client screen-shares to you instead of the reverse, work gets restructured around scheduled calls where the client drives while you direct, or deliverables move to an async handoff model using approved file-sharing tools. It's a worse workflow than remote control, but it's one that survives an audit, and continuing to negotiate directly with IT after two clear refusals usually damages the relationship with the client more than the connectivity problem itself did.

When It's Worth Getting a Second Set of Eyes on the Connection

Most of the time this is solvable in under half an hour once someone who does this daily looks at exactly which port, protocol, or destination is being blocked — the difference between a dead end and a five-minute fix is often just knowing which of the five things above actually applies to your situation. If you've already tried the obvious swap and it's still not connecting, or you're not sure whether what you're hitting is a simple port block or full packet inspection, that diagnosis is worth outsourcing rather than burning another day of billable client time guessing.