Connect servers securely across clouds.

Start with the application, not a router project.

Your existing LAN addresses and subnets remain in place. Enrolled endpoints gain a separate private overlay address, so a server in one cloud can connect to an approved server in another without manually configuring a site-to-site VPN for each pair of locations.

Zero trust comes from the controls you configure. Enroll and verify devices and users, define least-privilege access, and keep application authentication. Sharing a network or group does not create ambient trust. Installing the client alone does not establish a zero-trust policy.

This is a separate, intentional service-to-service policy scenario. It is not the isolated-services example below, where servers have no intra-group or inter-group allowances. These are illustrative directional rules, not deployed defaults. Use the actual required ports, turn off bidirectional initiation where unnecessary, and remove broad allow-all paths. Allowances combine; a narrow rule does not cancel a broader one.

You can often avoid public inbound application openings and manual router changes. Outbound connectivity and the required host-firewall, cloud security-group and company-policy permissions still matter. Some environments need firewall changes; this does not bypass existing controls.

Server Engineers reach every managed server. Services stay isolated.

VPNnet security groups are collections of enrolled peers, such as Server Engineers, Web Services and Other Services. They are distinct from an AWS or other cloud-provider security group, which remains a separate firewall control. A peer can belong to several VPNnet groups. Engineering laptops can stay in Server Engineers, with policies to each managed server group; they do not need to join every destination group. Groups alone grant no access.

On small screens, swipe across the diagram to inspect both groups.

The twelve drawn paths cover every server in these two managed groups. For each approved destination group, use a directional TCP rule: Server Engineers as source, the server group as destination, and SSH port 22 or RDP port 3389 only where needed. “Access everything” here means reaching all approved managed servers on their permitted management ports, not every port or service. Enrollment and device identity establish which peers the policy refers to; they do not replace OS accounts, SSH keys, Windows privileges or application authorization. Turn bidirectional initiation off. Replies to an allowed connection can return; that does not authorize servers to initiate a new management connection to the laptops.

Remove allow-all and review every other policy. Matching allowances combine. A broader rule can reopen server-to-server access even when these two rules are narrow. Do not add intra-group or inter-group rules unless the applications explicitly require them.

This isolates the VPN paths only. Existing LAN connections, public addresses, cloud security groups and host firewalls require their own controls. Network access also does not bypass SSH, Windows or application authentication.