Skip to main content

Tutorial: Use CloudConnexa for Remote Access to Applications on Networks Having Overlapping IP Address Subnets

Rohit
Updated
Abstract

This tutorial shows how CloudConnexa can network together private networks that use the same IP address subnets. Instead of using IP address-based routes to those networks, CloudConnexa uses the domain names of the applications in those networks as routes to select the correct network.

Overview

When Devices on one private Network can have all or some of their IP addresses in common with Devices in another private Network, the IP address ranges—subnets—for those two Networks are said to overlap. When you want to Network together multiple overlapping subnets it’s impossible to identify and route traffic to a specific Device by its IP address since the same IP address is being used in another Network.

Applications

The Network Application feature in CloudConnexa enables you to solve this by creating unique domain names (Applications) for public or private domains that are used as routes to the different Networks instead of the IP address subnets. Note that If private domains are used, you will need to add them to your DNS records or add them to CloudConnexa’s DNS records. When Application domains and their applicable protocols and/or ports are configured to uniquely identify each Network, CloudConnexa can route traffic within each Network. CloudConnexa can route traffic to the correct device even if its IP address overlaps with another Network because the FQDN signifies the destination.

About this content

This content is based on a scenario where a fictitious security company, Acme Security, needs Remote Access to various Devices at multiple customer sites. The person managing this effort is Owen, an IT and Network specialist for Acme Security.

Scenario

Acme Security provides video monitoring services mainly to small, independently owned stores. Their solution consists of installing one to four cameras in the store along with other monitoring Devices and video storage servers. The cameras store videos locally but Acme Security needs to remotely connect to the cameras, servers, and other equipment in order to update firmware, carry out diagnostics, change settings, etc. Technicians at Acme Security need to remotely access the embedded web servers running on the various connected Devices to administer them.

Owen has been tasked to do the following:

  • Provide Remote Access to the cameras and other monitoring equipment at customer sites, Store 1 and Store 2.

  • Manage access to Devices on the customer’s LAN in spite of the use of overlapping IP address ranges among customer LANs. The monitoring equipment uses the customer’s Network for access to the internet and static IP addresses are configured for the cameras and other equipment from the customer’s LAN IP address range. Therefore, it will not be possible to prevent IP address range overlap among customer sites. For example, two cameras installed in different customer stores might have the same IP address of 192.168.0.101

  • Restrict communication between different customer’s Networks.

  • Ensure the Remote Access solution does not require any additional WPC servers.

Owen decides to use CloudConnexa to build a WPC that provides secure Remote Access to the camera Networks at the different stores. During the signup process, he selects a Cloud ID for his WPC. This [company-name].openvpn.com domain uniquely identifies the WPC that has been set up by Owen.

From the WPC illustration below, note that the IP address of the video server in Store 1 is the same as the camera in Store 2. Connector software running on a Linux computer at all the customer sites connect the sites to CloudConnexa.

remote_access.png

Configure domain names for Networks instead of IP subnets and using Access Groups

  1. Owen logged into the Admin Portal and configured a Network (Networks > Add Network) to represent the Network in Store 1. He installed the Connector on a Linux computer on the Network in Store 1. While configuring the Network, Owen added domain store1.control.com

    Important

    Do not define a subnet under the Subnets section.

  2. Owen configured another Network to represent the Network in Store 2 and installed the Connector on a Linux computer on the Network in Store 2. While configuring the Network, Owen added domain store2.control.com

  3. Owen checked the Status screen and saw that both the Networks had come online.

  4. Next, to prevent communications among the private Networks at each customer’s store via the WPC, Owen changed the WPC topology to Custom (see, Change WPC Topology) and set up an Access Group to only allow the Networks to communicate with the applicable User Groups and not with each other. See, Add Access Group

store1.png

    Accessing Devices with configured domain names

    1. Because Owen does not have a DNS server, he opted to create DNS records for the Devices on the Network for store 1. From the DNS settings page (Settings > DNS > DNS Records) of the Admin Portal, he added DNS records for the equipment in Store 1. He then mapped vs.store1.control.com to 192.168.0.100 and camera.store1.control.com to 192.168.0.55. For the equipment in Store 2, he mapped vs.store2.control.com to 192.168.0.55 and camera.store2.control.com to 192.168.0.100

    2. Owen connected to CloudConnexa (see, Connecting to CloudConnexa). On connection, Owen opened his web browser and used the domain names of the Devices to access the embedded web servers. For example, http://camera.store2.control.com let him access the Administration portal of the camera in Store 2 even though it had the same LAN IP address as the video server in Store 1.

      62eac562546d1.png

    Accessing Devices without configured domain names

    CloudConnexa allows a shortcut to route to specific IP addresses in a Network that is configured with a domain name without needing to configure DNS Records. Owen can directly route to the video server in Store 2 present at 192.168.0.55 by constructing a name on the fly using the destination IP address 192.168.0.55 and the domain name of the Store 2 Network store2.control.com. The constructed hostname would replace the . in the IP address with - and prepend it to the domain name of the Network to create a unique hostname 192-168-0-55.store2.control.com

    1. Owen wanted to use this ability to create hostnames on the fly without configuring DNS Records. He set the Allow Embedded IP switch for the domain names assigned to the two Networks to ON

    2. Owen connected to CloudConnexa (see, Connecting to CloudConnexa). On connection, Owen opened his web browser and constructed the name of the Device he needed to access on the fly. For example, http://192-168-0-100.store2.control.com let him access the Administration portal of the camera in Store 2 even though it had the same LAN IP address as the video server in Store 1.

    3. Owen can also log in as root and ssh into the device from terminal by typing ssh@<private ip address>Network Application Domain Name.

      store_1_domain.png

    List of All Remote Access and ZTNA Tutorials

    Abstract

    Contains a list of links to all the tutorials showing the use of CloudConnexa for remote access and ZTNA.

    List of All Remote Access and ZTNA Videos

    Abstract

    List of videos related to remote access and ZTNa

    Comments

    0 comments

    Article is closed for comments.

    Powered by Zendesk