User Guide – Routing traffic to specific public internet domains through a VPN
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 these SaaS applications. He has the following objectives:
- He only wants the traffic to internal applications and to business SaaS apps to use the VPN without tunneling all the traffic to the internet via the VPN. He wants a solution that does not force him to turn split-tunneling for the VPN OFF.
- He wants to curtail access to the SaaS tools such that they can be accessed only via the VPN.
- He does not want to manage, install and maintain VPN servers.
Owen decides to use OpenVPN Cloud to build a VPN that provides secure remote access to its private network and the SaaS apps. He completes the signup process as shown here. During the signup process, Owen selects an OpenVPN-ID for his VPN. This [OpenVPN-ID].openvpn.com domain uniquely identifies the VPN that has been set up by Owen.
- Owen adds the IP address range of the subnet that hosts internal applications as a Network named app_network. In spite of the private network having access to the Internet, he does not enable VPN Egress because there is no need for the Network to announce the default route to the VPN but only routes for the domain names of the SaaS apps.
- In addition to adding the IP address range, Owen adds the domain names of the SaaS applications (for example, salesforce.com) as routes to the Network. Note that subdomains do not need to be specified. Now any traffic destined to those SaaS app domains will be routed to the app_network with the destination IP address being the public IP address of the SaaS app.
- Owen then installs the Connector on a computer running Linux on the private subnet. He sets that instance to enable IPv4 forwarding and NAT on the private IP address.
- Owen proceeded to add employees as Users using their email addresses. See, Adding a User
Owen downloads the Connect Client, imports the profile from [OpenVPN-ID].openvpn.com, and connects to the VPN from his home Wi-Fi network. He checks that his public IP address, by searching what is my IP on Google Search, still shows his home network’s public IP address indicating that split-tunnel is ON. Now, he logs into one of the SaaS websites whose domain name has been configured as a route to app_network. When he checks that SaaS app’s audit log, he sees that the IP address logged is the public IP address of his company. This proves that the traffic did indeed get tunneled through the VPN.
Now that Owen is assured that while accessing the SaaS app it will always appear that access is being made from the public IP address of the company’s network, he whitelists that IP address in the 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