Skip to main content

User Guide - Whitelisting access to SaaS for a distributed workforce

Overview

Abstract

Follow the steps in this guide to learn how to set up your VPN to ensure secure, whitelisted access to your SaaS applications.

In this document, we examine a WPC set up to meet the needs of a fictitious company. A startup has headquarters located in California, USA. They have virtual Sales offices in some of the major cities in America. Their sales force is often at customer sites or traveling to customer sites. They access the Internet from hotels, cafes, airports, and other public Internet sites. The sales team relies on SaaS tools like Gsuite and Salesforce.

Owen is in charge of IT and Networking for this company. Owen is cognizant of the security risks that come with the use of public hotspots to access the Internet and is looking for a WPC solution that the sales team can use for secure access to the Internet. He does not want to manage, install and maintain WPC servers but wants to ensure that the company has control over the interconnect to the Internet so that additional protections (for example, use of CASB) can be added later. In addition, he wants to curtail access to the SaaS tools such that they can be accessed only via the WPC.

Owen is aware that a few of the many benefits of using CloudConnexa are DNS security and control over the Internet access route and signs up to use CloudConnexa.

Owen completes the signup process as shown here. During the signup process, Owen selects technop.openvpn.com as the web domain for the User portal. This domain uniquely identifies the WPC that will be set up by Owen and is used by Connect Client applications (WPC Client software) to identify the WPC that it needs to connect to.

Illustration of WPC

62ead8c7ba14e.png

Setup

Owen followed the steps shown below to set up his WPC to accept traffic to the Internet and route it to the Internet via a Network configured as Internet Gateway. He then restricted access to SaaS-based on the public IP address of the egress:

  1. Configured a Network named ‘Internet Gateway’ to act as Internet Gateway. As this Network’s sole purpose is to act as an internet gateway, Subnets for the Network were not added, and Internet Gateway was turned ON. See, How to add a Network and Adding Internet Gateway.

  2. Next, Owen decided to run a server to install the Connector and act as the Internet Gateway with a public IP address of 157.245.138.113. See, Connecting Networks to CloudConnexa Using Connectors on how to install Connectors and the corresponding settings to enable routing. We recommend using Linux operating system.

  3. After the Network came online, Owen changed the Internet Access setting for User Groups to Split-Tunnel OFF. See, Changing User Group’s Internet Access.

  4. Owen connected to CloudConnexa (see, Connecting to CloudConnexa). On connection, Owen checked that the public IP address of his Device running the Connect Client and connected to CloudConnexa showed up to be the same as the public IP address of the Connector instance proving that the setup is working as configured.

    62ead8c9e63de.png
  5. Now that Owen was assured that while accessing the Internet via WPC it will always appear that access is being made from the public IP address of 157.245.138.113, he whitelisted that IP address in SaaS application and restricted logins only to those that originated from that IP address. This provides another layer of protection in case the SaaS application credentials get compromised. For example, see Salesforce instructions here https://help.salesforce.com/articleView?id=admin_loginrestrict.htm&type=5.

  6. Owen proceeded to add employees as Users using their email addresses. See, Adding a User.