Skip to main content

User Guide - Routing traffic to specific public internet domains through a WPC



You can route traffic to specific public internet domains through a VPN, which enables you to restrict sign ins to only those that originate from the public IP address of the VPN.

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 these SaaS applications. He has the following objectives:

  1. He only wants the traffic to internal applications and to business SaaS apps to use the WPC without tunneling all the traffic to the internet via the WPC. He wants a solution that does not force him to turn Split-Tunneling for the WPC OFF.

  2. He wants to curtail access to the SaaS tools such that they can be accessed only via the WPC.

  3. He does not want to manage, install and maintain WPC servers.

Owen decides to use CloudConnexa to build a WPC 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 a Cloud ID for his WPC. This [company-name] domain uniquely identifies the WPC that has been set up by Owen.


  1. 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 Internet Gateway because there is no need for the Network to announce the default route to the WPC but only routes for the domain names of the SaaS apps.

  2. In addition to adding the IP address range, Owen adds the domain names of the SaaS applications (for example, 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.

  3. 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.

  4. 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], and connects to the WPC 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 WPC.

    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