Enterprise Networking Guide
No Fixed Office in China Yet: How Can Distributed Teams Connect to an Overseas Cloud Intranet?
By deploying a virtual gateway in your existing overseas public cloud private network and connecting it to our cross-border transmission channel alongside your current remote access portal or third-party zero-trust connector, distributed team members across China can reliably access designated cloud intranet systems without waiting for a physical office or traditional carrier leased line construction; once a domestic office provisions standard broadband, a preconfigured physical appliance can join the same cloud connection directly.
When an enterprise runs admin consoles, code repositories, test environments, or internal databases inside a private network on an overseas public cloud such as AWS or Azure, while its team in China is still being formed with members working across different cities before a fixed office is ready, we can deploy a virtual gateway inside your existing overseas cloud internal network, connect it to our cross-border transmission channel, and integrate with your approved remote access entry point or third-party zero-trust connector so distributed team members can reliably access designated overseas cloud internal workloads.
With this approach, enterprises do not have to wait until domestic office fit-out and traditional carrier physical dedicated line construction are finished before starting collaboration, nor do they need to expose internal cloud systems directly to the public internet. Your existing cloud internal network structure, application addresses, and employee account login methods remain unchanged; once your domestic office is ready and standard broadband is provisioned, placing a preconfigured physical access appliance brings the new office directly into the same overseas cloud connection.
Deploy a virtual gateway in the overseas cloud private network to connect the cloud side first
Before you have a fixed server room or office broadband in China to host hardware appliances, deployment starts directly on the overseas cloud side. As long as your enterprise holds administrative permissions for the target public cloud environment or self-managed virtualisation platform, we can deploy a virtual gateway inside the cloud private network where your workloads run (or connect via an IPSec encrypted tunnel if a gateway already exists in the cloud). One side of the virtual gateway connects to your internal workload subnets in the cloud, while the other connects to our cross-border transmission channel—provisioning much faster than applying for a traditional cross-border physical dedicated line.
Once the cloud virtual gateway is online, internal code repositories, test servers, and admin consoles remain inside private subnets. So that access requests delivered over the cross-border channel can reach target servers and return responses properly, your cloud platform administrator adds return routes and allow rules for the agreed source private subnets in the cloud route tables, security groups, or internal firewalls. After reviewing your current network overview, we work with your cloud administrator to confirm the exact subnet ranges and integration details.
Pair with your existing remote access entry point and third-party connector so distributed members can access designated applications
With the cloud side connected, team members distributed across cities in China need a controlled entry point to reach the cross-border channel. We support integrating with your enterprise's existing remote access entry point, as well as deploying your chosen third-party zero-trust application connector in the access environment to link the employee-facing entry point with the virtual gateway in the overseas cloud.
Employees working from home or on business travel continue logging in with their approved corporate client software and employee accounts, with no need to switch to a new identity system; we do not replace your existing endpoint software or identity platform. Which employee is authorised to open which internal system remains governed by your administrator by role in your existing identity platform or connector console. When a team member initiates access to an internal system in the overseas cloud, traffic matching designated internal subnets or application domains passes through the connector into our cross-border transmission channel and straight to the virtual gateway in the overseas cloud—reducing page lag, interrupted code pulls, and connection timeouts caused by congestion and packet loss on the cross-border public internet.
During daily operation, we provide DNS query records and 5-tuple connection logs (including source address, destination address, port, protocol, and data volume transferred) on the network side to help administrators check cross-border channel connectivity, while detailed audit logs of employee actions after logging in to business applications remain stored in your own application backend or security platform.
Once the domestic office opens, join the same cloud connection directly with a preconfigured appliance
After your new office in China completes site selection, fit-out, and local broadband installation, you can continue using the virtual gateway already deployed in the overseas cloud, the same internal application addresses, and your existing employee account system without rebuilding from scratch. Simply adding the corresponding routing and security allow rules for the new office subnet based on your live environment brings the physical office network into the existing cloud connection.
Once the new office LAN subnet, target cloud workload scope, and on-site broadband conditions are confirmed, we ship a physical access appliance preloaded with configuration and policies to the new office. An on-site office administrator or part-time coordinator simply connects power, local broadband, and the office internal network switch as instructed; once online, the appliance automatically pulls its preconfigured settings and establishes a cross-border link with the virtual gateway in the overseas cloud. After routing and security allow rules for the new office private subnet are completed on the cloud and gateway sides, traffic from the office to the overseas cloud internal network flows directly over the cross-border channel, while employees continue authenticating to specific systems under your existing corporate account and login rules.
After the office joins the network, on-site staff access the cloud through the office physical access appliance while colleagues working remotely or travelling continue using the existing remote access entry point, with both paths converging at the overseas cloud virtual gateway. If your domestic team grows or needs higher bandwidth for bulk R&D file pulls or phased integration testing, cross-border channel bandwidth can be scaled on demand within the capacity of your office broadband and regional resources—without waiting for traditional physical dedicated line construction. For offices with multiple broadband links, multi-link access and automatic failover can also be configured to match on-site conditions.
Basic information to share in an initial consultation
- The public cloud platform and region hosting your overseas internal workloads (such as a private network in AWS Frankfurt, Tokyo, or Singapore) and the main systems your team accesses daily.
- The cities where domestic team members are currently distributed, approximate headcount, and the remote access entry point or third-party zero-trust connector your enterprise already uses.
- Whether you plan to set up a fixed office in China later, the expected city and local broadband readiness, and any explicit headquarters restrictions on access scope.
- Sharing the overview above is enough to determine an access plan together during our initial consultation—no need to compile cloud route tables, security group details, or network topology diagrams upfront, and please do not send account passwords, cloud platform keys, or internal business data via forms or email.