User Guide – Remote access to private networks with overlapping IP address space
A security services company provides video monitoring services to mainly 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 the security service company needs to remotely connect to the cameras, servers, and other equipment in order to update firmware, carry out diagnostics, change settings, etc. The company’s technicians need to remotely access the embedded web servers running on the various connected devices to administer them.
Owen is in charge of IT and Networking for this company. He has been tasked to find a solution that:
- Provides remote access to the cameras and other monitoring equipment at customer sites
- Manages to access 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 the IP addresses configured for the cameras and other equipment are assigned statistically 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
- Restricts communication between different customer’s networks
- Will not require any additional VPN servers to install or maintain for this secure remote access solution
Owen decides to use OpenVPN Cloud to build a VPN that provides secure remote access to the camera networks at different stores. 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.
A high-level illustration of the VPN is shown below. Notice 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 OpenVPN Cloud.
- Owen logged into the Admin Portal and configured a 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.
- He then went to the DNS settings page of the Admin Portal and added DNS records for the equipment in Store 1. He mapped vs.store1.control.com to 192.168.0.100 and camera.store1.control.com to 192.168.0.55.
- 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.
- He then went to the DNS settings page and added DNS static records 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.
- On the Linux computers on both the store networks running the Connectors, he setup IP forwarding and NAT so that no static routes will be needed on the customer’s router. See, Connecting Networks to OpenVPN Cloud Using Connectors for more details.
- Owen checked the Status screen and saw that both the Networks had come online.
- Next, to prevent communications among the private networks at each customer’s store via the VPN, Owen changed the VPN topology to Custom (see, Change VPN Topology) setup an Access Group to only allow the networks to communicate with the applicable User Groups and not with each other. See, Add Access Group.
- Owen connected to OpenVPN Cloud (see, Connecting to OpenVPN Cloud). 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.