Skip to main content

User Guide - Limiting Network access to only authorized private and trusted internet services

Overview

A military contracting services company carries out software development of highly sensitive applications of national security importance. They provide their employees with company-owned laptops that are managed and locked-down by the IT department.

Owen is in charge of IT and Networking for this company. Remote access needs to be provided to a handful of management employees. He has been tasked to find a Network-as-a-Service solution that, based on the User’s identity, restricts Network and internet access to:

  1. Authorized applications hosted in specific private Networks IP address subnets ranges.

  2. Access to specific private domains.

  3. Only HTTPS access to all private services.

  4. No access to the internet except a select set of domains

Owen decides to use CloudConnexa to build a WPC that provides secure Remote Access to its private Network and the internet. He completes the signup process as shown here. During the signup process, Owen selects a Cloud ID for his WPC. This [company-name].openvpn.com domain uniquely identifies the WPC that has been set up by Owen.

Set up

  1. On the WPC section of the Settings page, Owen sets WPC Topology to Custom so that access rules can be enforced.

  2. 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 a specific set of internet domains.

  3. Owen adds the following as services for the app_network:

    1. Adds a service of type set to domain for each of the allowed set of public domains: cnn.com, .mil, .gov, and linkedin.com

    2. Adds a service with type set to IPv4 and service set to HTTPS for the IP address subnet range of app_network

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

  5. The DNS systems reside in the same subnet as app_network. To allow the Users to resolve private domain names while connected to the WPC, Owen configures the private DNS servers as the DNS Servers on the WPC section of the Settings page.

  6. On the Groups tab of the Users page, he adds a new group called Mngmt withthe Internet Access setting set to Block This means that all the internet traffic from the User’s Device will be tunneled to CloudConnexa and all that traffic will be dropped, except the ones destined to configured pubic domains as services for app_network. He sets Connect Auth to the value of every time so that the WPC Users need to always enter their credentials when they connect to the WPC.

  7. To enforce access control, Owen creates an Access Group with the User Group Mngmt as the source and all the services belonging to app_network as the destinations.

  8. On the User section of the Settings page, Owen sets Profile Distribution to Manual. The use of this setting disables the Users from using their logins to automatically activate Devices and import profiles.

  9. Owen adds the management employees as Users and assigns them to the Mngmt group. He then adds a Device for each one of them. He then downloads the Device Profile for each User’s Device.

  10. For each of the laptops, Owen installs the OpenVPN Connect client and uses file import to add the respective Profile for the User’s Device. He uses a third-party endpoint management software to add a policy to always connect to CloudConnexa when a Network connection is active.

After this setup, anytime the laptops connect to a Network (whether internal or public) the laptop will establish a WPC connection, after authentication, to CloudConnexa in order to gain HTTPS access to apps hosted on the private Network and a select set of internet sites.

 

In this section: