Site-to-Site VPN: Secure Channel Enables Service Desk Support

An illustration of a diagram shows the process of site-to-site VPN

From an end user perspective, connecting via a remote access VPN has that one-step only convenience. It recreates that in office experience on the desktop that logging in through multiple terminal servers does not. For telecommuting employees, ever mobile staff, and a globally dispersed workforce operating out of overseas, server-free satellite offices, the VPN advantages are obvious. But when such remote connectivity extends beyond the corporate network to IT support vendors, client management teams understandably pose the next logical question related to data security and vulnerability. Not to worry. In a site-to-site VPN scenario, secure data is sent over a TCP/IP internet connection through a VPN router or gateway. The gateway, in turn, encapsulates and encrypts/encodes the outbound data packet, relays it via the internet through a VPN tunnel, to a peer VPN gateway at the recipient’s location. Once the data packet is received, the peer VPN gateway strips the headers, decrypts the information, and relays the packet to the intended client’s private network.

Essentially, it’s an encrypted tunnel so it allows you to connect the network infrastructure from one site or building to another anywhere across the world with that encrypted network traffic crossing that VPN bridge. The greatest advantage is that the remote site replicates your local network. Also, you can RDP (Remote Desktop Protocol) into another site, ping servers or devices, and access various network resources. So anything you can accomplish on your local network can be managed via remote network once connected through the site-to-site VPN. And once that VPN connection is in place, service desk agents log in and can grant or restore access to all client applications that authorized end users currently cannot. Only after the end-user is authenticated and access approved, can the agents can perform functions such as remote installs of any application on the client’s network.

By contrast, if agents are using a RDS tool like Citrix XenApp, their support capabilities can be limited as they are only allowed to troubleshoot what’s currently on that particular individual’s desktop or what the client had published to a virtual desktop. So Citrix functions more like a portal, hosted by a server that can have applications made available on it, but doesn’t share any of the network resources locally from the client’s site. So service desk agents are accessing a remote portal through which they can launch applications, but they don’t have that local access.

For those instances when VPN or Citrix are not options for establishing connectivity, there are indeed alternatives. To troubleshoot incidents via remote control of end user PCs and laptops, service desk agents can also utilize third party software like TeamViewer. Even if TeamViewer access is blocked by an egress filter or firewall, it may be installed via the remote access server in order to enable the agent’s desktop troubleshooting capabilities.

So how do most service desk outsourcing vendors set up the site-to-site VPN with new clients? The process typically only requires access to one or more hosts on the client network to deliver the support services. As a result, it is important to ensure the VPN encryption domain is as specific as possible including the host level if appropriate. At implementation, hardware configuration parameters such as device, IP address, and pre-shared key, again to reinforce the secure channel encryption between both connected parties.

ABS Director of Operations Hector Gonzalez sums up the benefits. “The VPN gives us direct access to the client’s IT environment so whatever access or rights are available match what we can deliver their end users thereby enabling service desk outsourcing vendors to resolve incidents and service requests through a single channel as securely and efficiently as its internal personnel.”