Most enterprise businesses are undergoing digital transformation of some form. For many, this means adopting a ‘cloud first’ strategy built around modern applications and services such as SaaS. Voice services are a prime example: platforms like Microsoft Teams and Zoom have fundamentally transformed business communications.
Not all businesses are at that stage, however. Legacy applications remain a necessity in many organisations, and some of these don’t sit well with a Secure Service Edge (SSE) deployment. In particular, server-to-client applications that rely on the client’s real IP address, rather than a NATed address, present a specific challenge.
The Zscaler Network Connector is a specialised virtual machine designed to enable secure, end-to-end remote access for legacy applications that rely on server-initiated communication. As a key component of the Zscaler Private Access (ZPA) framework, it serves as a modern alternative to traditional VPNs by supporting older software protocols, such as VoIP and Active FTP, that require real IP address binding.
Like other Zscaler components such as App Connectors, the Network Connector establishes an “inside-out” tunnel to the Zscaler cloud. This means internal servers can communicate with remote clients without requiring any open inbound ports on the corporate firewall, keeping the network dark and unexposed to the public internet.
From a deployment perspective, the connector is typically installed in pairs (for resiliency) within an on-premises data centre or a public cloud environment such as Microsoft Azure or Amazon Web Services.
Installation follows broadly the same process as deploying an App Connector. The steps are:
• In the ZPA portal, navigate to VPN (for Legacy Apps) → Network Connectors → Network Connector Provisioning Keys and create your provisioning keys.
• Deploy the Network Connector images as required, then apply the provisioning keys.
• The connectors will appear in your ZPA portal once connected. The only configuration difference from an App Connector is in the service names.
Once the connector is connected and updated, users can be allocated to the service. Unlike some other Zscaler services, VPN (for Legacy Apps) can be allocated to a specific subset of users or groups, so it does not need to be licensed for the entire organisation.
For example, if a call centre has specific users relying on an on-premises voice service while all other users are on Teams, only the call centre users need to be licensed. As usual, licensing should account for all users who may use the service, not just concurrent connections.
Users are permitted or blocked from the service via a series of rules that can identify individuals by a variety of criteria — group membership being the most common approach.
To manage this, navigate to: VPN (for Legacy Apps) → VPN Users → User Enablement.
Unlike other Zscaler services, VPN (for Legacy Apps) requires a VPN Service Edge to be defined. Navigate to: VPN (for Legacy Apps) → VPN Service Edges.
This configuration defines the Zscaler region where the VPN Service Edge will be hosted, as well as a client IP pool. The client IP pool is essential because, unlike other Zscaler services, NAT is not used here. Legacy applications require knowledge of the client’s actual IP address to establish connections.
Copy the IP address from the VPN Service Edges page and paste it into the Hostname or IP Address Bypass for VPN Gateway field within the ZCC Client Connector Application Profile bypass settings.
The final step of the Zscaler configuration is defining the network segments required. These are the IP address ranges within your data centre that clients need access to. Navigate to: VPN (for Legacy Apps) → Network Segments.
Within your data centre, relevant traffic must be directed to the Network Connectors. If a single Network Connector is deployed (not recommended), a static route for the client IP address range is sufficient. For redundant deployments, BGP is required, configured both on the Zscaler VPN Service Edge and on your cloud or data centre network.
Once this is in place and the service is showing as online, clients can begin accessing the service.
Navigate to VPN (for Legacy Apps) → VPN Users → VPN Connected Users to view real-time connection information. This displays authenticated usernames, the client IP address allocated from the defined pool, the VPN Service Edge each user is connected to, and the connection status.
In terms of security and routing, the Network Connector acts as the next hop for specific client IP pools, effectively bridging the gap between the remote user and the internal network segment. It maintains a “dark” network presence, meaning the infrastructure remains invisible to the public internet, while securely routing traffic via authenticated tunnels.
The Zscaler Network Connector offers several strategic advantages for organisations securing legacy environments within a Zero Trust framework:
• Native Legacy Application Support: Provides a critical bridge for older applications requiring server-to-client traffic and real IP address binding, such as VoIP and Active FTP.
• Secure Transition from Legacy VPNs: Enables organisations to fully eliminate traditional client VPNs by migrating legacy services to the ZPA platform.
• Reduced Attack Surface: Using inside-out connectivity ensures internal application servers are never exposed to the public internet and require no open inbound firewall ports.
• High Availability and Redundancy: 2025 updates have enhanced support for node and link failover using BGP (Border Gateway Protocol), ensuring constant connectivity for mission-critical legacy services.
• Simplified Hybrid Infrastructure Management: Provides a unified management experience via the ZPA Admin Portal, allowing IT teams to manage both modern ZTNA and legacy app access from a single console.
--------------------------------------------------------------------------------------------
The Zscaler Network Connector fills a genuine gap for enterprises that cannot yet migrate every application to cloud-native architectures. By extending Zero Trust principles to legacy systems, without re-opening firewall ports or reverting to traditional VPNs, it allows IT teams to modernise securely, on their own timeline.
