Service Tunnel Overview

Historically, workers had to be onsite to access resources within a corporate virtual private network (VPN). Workers could be authenticated (i.e., it could be verified that they were who they said they were), and, once authenticated, they could access any of the private resources contained within the corporate network; nothing left the bounds of the network.

Today, with distributed data centres and data in the cloud, anyone can access log-in portals that stand in front of protected resources. Anyone, then, can attempt to gain access to these protected resources; so long as the user is authenticated, they are granted access. But there's no way to verify that users who have gained access to a VPN are authorized to access (all or a subset of) the private resources within the network.

Service Tunnel accounts for this lost authorization aspect: it offers a built-in continuous authorization functionality. So, users who may be attempting to access protected resources from one IP, and then from another IP, are authorized on each access attempt. In these authorization events, Service Tunnel evaluates whether the user role and device Trust Level align with the Service Tunnel's pre-defined access policy.

This doc lays out the steps required to configure a Service Tunnel in your organization, so that your end users can securely access protected resources. These configuration steps are applicable to orgs on any deployment model (i.e., the Private Edge or the Global Edge).

Prerequisites

• Private Edge: An Access Tier installed in a network segment which can communicate with the internal subnet you need to connect to

Set Up

Steps to Publish a Service Tunnel

Set up a Service Tunnel to your private network segment in the following steps.