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. The cameras store videos locally but need to communicate certain events such as after-hours motion detection, etc. over the store’s internet connection to the security company’s monitoring server.
Owen is in charge of IT and Networking for this company. He has been tasked to find a solution that:
- Provides the cameras secure remote access to the monitoring server
- The cameras use the customer’s network for access to the internet and therefore should not require any changes to the customer’s router or firewall
- Restrict communication between different customer’s network
- Should not require any additional servers to install or maintain for this secure communications solution
Owen is aware that unlike IPsec, OpenVPN protocol is firewall-friendly and will not require any changes to the customer’s internet equipment. He has decided to use a router supplied by Ubiquiti to create a small private network for the cameras at the store premises. The router connects to the store’s network for internet access. The Ubiquiti router also has native support for OpenVPN protocol. Now that the networking solution compatible with OpenVPN has been found for the monitoring site it comes down to having the camera network accessing the monitoring server on Azure securely.
Owen decides to use OpenVPN Cloud to build a VPN that provides secure communications from the camera networks at different stores to the monitoring server. He completes the signup process as shown here. During the signup process, Owen selects an OpenVPN-ID for his VPN. This [OpenVPN-ID].openvpn.cloud domain uniquely identifies the VPN that has been set up by Owen.
A high-level illustration of the VPN is shown below. The OpenVPN Client in the Ubiquiti router acts as an OpenVPN Cloud Network Connector for the camera network in the store and the Monitoring Server on Azure acts as an OpenVPN Cloud Host because the Connector is running on the same server as the monitoring application.
Owen logged into the Admin Portal and configured a Host, named MonitoringServer and Connector, to represent the Monitoring Server running on Azure. The IP address that will get assigned to the Connector was shown. In this case, the IP address of 100.64.1.3 got assigned. This IP address remains static and is not dependent on the VPN Region selected for the Connector. This VPN IP address can be used to reach the Monitoring Server. See, Adding a Host
Owen then downloaded the Connector app for Windows and installed it on the Windows Server instance running the monitoring application and acting as the Monitoring Server. See, Running Connect Client as a system service
Owen checked the Status screen and saw that the Host had come online.
Next, Owen created two Networks to represent the camera network in Store 1 (10.0.0.0/30) and the camera network in Store 2 (10.0.0.4/30). He chose the closest OpenVPN Cloud VPN Region for each Network’s Connector to use. See, How to add a Network
Owen chose to download the Connector’s profile in .ovpn format and used the downloaded profile to configure the OpenVPN client in the Ubiquiti router. He looked at the guides available for pfsense, DD-WRT, and OpenWrt to get an idea of the needed information for router configuration.
He then configured the cameras to use 100.64.1.3 as the IP address of the monitoring server.
To prevent communications between the private camera networks installed in each store via the VPN, Owen setup an Access Group to only allow the networks to communicate with the Host and not with each other. See, Add Access Group