User Guide - Whitelisting access to SaaS for a distributed workforce
In this document, we examine a VPN setup 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 VPN solution that the sales team can use for secure access to the Internet. He does not want to manage, install and maintain VPN 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 VPN.
Owen is aware that a few of the many benefits of using OpenVPN Cloud are DNS security and control over the Internet access route and signs up to use OpenVPN Cloud.
Owen completes the signup process as shown here. During the signup process, Owen selects technop.openvpn.cloud as the web domain for the user portal. This domain uniquely identifies the VPN that will be set up by Owen and is used by Connect Client applications (VPN Client software) to identify the VPN that it needs to connect to.
Illustration of VPN
Owen followed the steps shown below to setup his VPN to accept traffic to the Internet and route it to the Internet via a Network configured as VPN Egress. He then restricted access to SaaS-based on the public IP address of the egress:
- Configured a Network named ‘Internet Gateway’ to act as VPN Egress. As this network’s sole purpose is to act as an internet gateway, Subnets for the Network was not added and VPN Egress was turned ON. See, How to add a Network and Adding VPN Egress
- Next, Owen decided to run a server to install the Connector and act as the Internet Gateway with a public IP address of 220.127.116.11. See, Connecting Networks to OpenVPN Cloud Using Connectors on how to install Connectors and the corresponding settings to enable routing. We recommend using Linux operating system.
- 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
- Owen connected to OpenVPN Cloud (see, Connecting to OpenVPN Cloud). On connection, Owen checked that the public IP address of his device running the Connect Client and connected to OpenVPN Cloud showed up to be the same as the public IP address of the Connector instance proving that the setup is working as configured.
- Now that Owen was assured that while accessing the Internet via VPN it will always appear that access is being made from the public IP address of 18.104.22.168, 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
- Owen proceeded to add employees as Users using their email addresses. See, Adding a User