[Back to blog](https://zcp.zsoftly.ca/blog) [Engineering](https://zcp.zsoftly.ca/blog/category/engineering) # How Zenphry Built a Reusable Office Connection for Its Remote Team How Zenphry built an approved remote-access foundation with a Headscale VPN control plane on ZCP, a Dallas exit node, Tailscale clients, and managed routers. ZSoftly Team November 4, 2026 4 min read Share ![ZCP engineering cover about approved office egress for remote teams](https://zcp.zsoftly.ca/images/blog/2026/remote-teams-office-network.webp) Zenphry built a shared remote-access foundation for approved employees who need to use the company’s Dallas internet egress from home or Wi-Fi. Egress means the outbound internet connection a device uses. One managed company network provides the foundation, with approval and policy deciding who can use it. The first validated connection was a managed router in Ottawa. It proved the path for one location. The design is reusable for additional approved employees and devices. ## The outcome: a reusable, approved path The goal was a consistent way for remote employees to reach the internet through Dallas, while keeping office-network access separate. An approved internet exit is not permission to use the Dallas office LAN or every private application. For an additional approved employee, the operating model is straightforward: 1. Zenphry approves the person or device and assigns the required access policy. 2. The employee joins Zenphry’s private Tailscale network, known as a tailnet, through a Tailscale client. 3. The policy authorizes Dallas internet egress and the employee selects the Dallas exit node. 4. Equipment behind a preconfigured managed router uses the same path without a VPN client on every device. This means the organization reuses one enrollment, identity, and routing foundation. Approval is still required for each employee or device. It does not grant automatic access to unapproved users or full office-network access. ## The components Zenphry uses ZSoftly Professional Services designed and configured the deployment. ZSoftly Cloud Platform (ZCP) in Montréal hosts Zenphry’s self-hosted Headscale VPN control plane. Headscale coordinates membership and policy for the company tailnet. The Dallas exit node carries outbound internet traffic. A dedicated Dallas Linux exit node provides approved outbound internet egress. Approved employee laptops join the tailnet through Tailscale clients. A managed GL.iNet Beryl AX router creates the same route for connected home and Wi-Fi devices that do not need a client of their own. Staff access is separate. Personal Tailscale clients authenticate through single sign-on (SSO) and least-privilege identity groups. The employee-router tag permits internet egress only. Zenphry advertises and approves no Dallas office LAN subnet routes. Private applications use their own approval path and retain their native sign-in and authorization. ZSoftly Professional Services supports device onboarding, access policies, approved routing, DNS, network address translation (NAT), and management access. Those controls make the foundation repeatable without treating every remote employee as a new network project. Architecture for approved onboarding. The control plane coordinates membership and policy. The data path carries approved remote-device traffic to the Dallas internet exit. ZCP Montréal: Headscale VPN control plane Headscale coordinates membership and policy. Internet traffic exits through Dallas. Approved remote devices Personal Tailscale clients, or connected devices through a GL.iNet Beryl AX router Encrypted tailnet Dedicated Dallas Linux exit Approved outbound egress Dallas egress Public internet Private applications are separately approved. No Dallas office LAN routes are advertised. ZSoftly Professional Services designs, configures, onboards, and manages the foundation. ## The Ottawa validation The Ottawa router enrolled its built-in Tailscale client with the Headscale control plane. Router-level DNS and HTTPS checks completed through the configured path. The observed public IPv4 address matched the Dallas egress. The employee reported successful use from the router LAN. We did not take an independent LAN-client capture, so this is evidence for the router path and reported use, not independent proof of every connected device. Reboot, firmware-update, tunnel-down, and IPv6 behavior still need validation before broader rollout. Several implementation details mattered. The router vendor wrapper initially returned the client to a hosted control URL, so the startup command now sets the self-hosted login server explicitly. Router traffic reached Dallas, but its default ISP DNS timed out. We configured a reachable DNS resolver and preserved local router DNS. Forwarded LAN traffic also required persistent native NAT settings. Management access was restored and verified through a separate administrative SSH path before remaining DNS and forwarding changes. The related [Zenphry case study](https://zcp.zsoftly.ca/resources/case-studies/#case-zenphry-remote-team-office-network) records the shared foundation and router validation. ## Choose the policy before the route Start by deciding what each group needs: Dallas internet egress, a private application, or a specific office resource. Apply the narrowest policy that supports that work. Keep management and recovery paths independent before changing routes. Dallas egress also has a geographic consequence. Traffic from Ottawa exits in the United States. A Headscale control plane hosted in Montréal does not make the internet path Canadian-resident. Zenphry chooses exit regions according to its own policy and residency requirements. For route and client configuration details, see the [Headscale route documentation](https://headscale.net/stable/ref/routes/) and GL.iNet’s [Tailscale interface guide](https://docs.gl-inet.com/router/en/4/interface_guide/tailscale/). ## Build a foundation, then onboard with control ZSoftly Professional Services can design, deploy, and manage Headscale, device onboarding, access policies, approved routing, DNS, NAT, and recovery procedures. The organization sets the approval rules and exit-region choices. We build the shared foundation and validate the paths around them. For a remote-access design that separates approved egress from private-network access, see [Zero Trust VPN with Headscale](https://zcp.zsoftly.ca/professional-services/headscale/) or [contact us](https://zcp.zsoftly.ca/contact). ## Related articles Engineering November 4, 2026 ### [Why I Love Orca for ZSoftly’s Development Workstations](https://zcp.zsoftly.ca/blog/shared-development-workstation-orca-zcp) How ZSoftly is designing dedicated developer workstations on ZCP, with Orca across interactive work and a separate CI/CD path for execution. Engineering October 11, 2026 ### [The Restart That Hid a Libvirt Bug](https://zcp.zsoftly.ca/blog/the-restart-that-hid-a-libvirt-bug) A seven-minute VM create, two wrong turns, a self-healing timer I built and then deleted, and the package update that fixed it. Engineering October 5, 2026 ### [Private Desktops: Lessons from Testing](https://zcp.zsoftly.ca/blog/what-we-learned-testing-private-employee-desktops) What to test before a private desktop rollout: daily work, video calls, network paths, storage, and offboarding.