From a remote-desktop relay to one secure gateway
A Brisbane professional services firm needed staff in China and India to reach its Australian cloud server securely. Getting a static IP locally was hard and expensive in China, and patchy in parts of India — so the workaround was routing through an office PC over a remote-desktop tool. It worked, but it was slow. TYO Reach Team replaced the relay with one direct, secure connection.
A trusted IP was hard to get where the staff actually were
The client is a Brisbane-based professional services firm with staff working in China and India who needed regular, secure access to a cloud server hosted in Australia. For security, that server only trusts connections from a known IP — a sensible policy, but one that assumes everyone connecting can get hold of a stable IP address locally.
Static IP is difficult and costly in China
Fixed, routable IP addresses aren't something most residential or small-business connections in China come with by default — they're a separate business-tier line with their own registration and paperwork, not a box you tick on a normal connection. Arranging one for a handful of remote staff adds cost and admin most companies would rather avoid.
Patchy in parts of India too
Some regions had the same static-IP problem as China, though it wasn't universal. Speed itself generally wasn't the issue for Indian staff — the missing static IP was.
The workaround: an office PC as a relay
To give staff a consistent, trusted IP, the client kept a computer running in a local office that already had one. Staff in China connected to that PC using a remote-desktop tool (DualMon), then used that session to reach the cloud server.
Remote desktop into remote desktop is slow
That workaround solved the IP problem but stacked two remote sessions on top of each other — a laggy DualMon session to the office PC, then whatever latency the cloud server connection added on top. Day-to-day work through that chain was noticeably slow.
One gateway, no relay PC required
A consistent gateway IP, wherever staff are
With a Reach Team group, every member's traffic exits through the same Reach gateway — the cloud server sees one trusted address, regardless of whether the person connecting is in Brisbane, China, or India. No local static IP to arrange.
Staff connect directly
Because the gateway IP is already consistent, the office PC that existed only to relay connections is no longer needed for this purpose. Staff route straight from their own device to the cloud server through Reach.
One hop instead of two
Removing the DualMon-into-office-PC step means the connection is a single hop to the cloud server through the Reach gateway, rather than two remote-desktop sessions stacked on top of each other. The client reports access to the Brisbane cloud server is significantly faster as a result.
Managed centrally, same as the rest of the team
Staff in China and India join the same Reach group as everyone else. MFA, routing policy, and access all come from the one admin dashboard — no separate setup per country or per relay machine to maintain.
Not just this one client
IP-restricted resources, staff without a static IP
Any company whose internal tools, cloud servers, or SaaS platforms are locked to known IPs — but whose staff sit somewhere a static IP isn't easily available.
Teams currently chaining remote-desktop sessions
If your team reaches a trusted resource by first remoting into another machine that already has access, that extra hop is very likely adding the lag you're feeling.
Distributed teams across APAC
Reach's gateway network already covers Australia, Hong Kong, and Singapore, with more regions added as demand grows — useful for teams spread across the region, not just one country.
Case study FAQ
Did this replace the client's remote-desktop tool entirely?
It replaced the office PC as a relay for reaching the cloud server. Staff connect directly through Reach instead of remoting into an intermediate machine first.
Why not just buy a static IP in China directly?
That's often difficult or expensive for a small number of remote staff, and doesn't scale cleanly if the team grows or people change location. A shared gateway IP through Reach solves this once, for the whole team, regardless of where individual members are.
Is this specific to DualMon, or any remote-desktop relay?
Any setup using a relay machine for the same reason — to inherit a trusted IP — has the same double-hop latency problem. Reach removes the need for the relay itself, so the fix applies regardless of which remote-desktop tool was being used.
Does this work for staff in other regions with the same static-IP problem?
Yes — the underlying issue (no easy static IP where the person is) isn't unique to China or India. Any Reach Team group gives every member the same gateway IP no matter where they connect from.