Skip to main content

Introduction to CloudConnexa

Abstract

CloudConnexa is a cloud-delivered service that provides a secure networking and remote access solution with the essential features needed to implement a zero-trust solution. It enables a smooth transition from perimeter security to zero-trust network access.

Introduction

CloudConnexa is a cloud-delivered service that provides a secure networking and remote access solution with the essential features needed to implement a zero-trust solution. It enables a smooth transition from perimeter security to zero-trust network access.

The service can be accessed by connecting to one of CloudConnexa's Points of Presence (PoP) worldwide. CloudConnexa is a multi-tenant service that creates a virtual private overlay network that spans all the PoPs. This overlay network provides connectivity and access to various entities, users, private network applications, or IoT devices.

CloudConnexa also has vertically integrated security features like content filtering and IDS/IPS into the service.  Refer to Cyber Shield.

How does CloudConnexa work?

cloudconnexa_remote_access.png

The worldwide CloudConnexa PoPs are called Regions. CloudConnexa has data centers in these geographical areas, where the service's multi-tenant, kernel-optimized, high-performance servers are hosted.

These Regions interconnect using a full-mesh topology. Full-mesh connectivity ensures that there is always direct connectivity between Regions to reduce latency and redundant routes present.

CloudConnexa service is multi-tenant. That means that the Regions, the core network that connects all these Regions, and all other elements of this platform are shared with all customers and are virtually isolated. As there are no dedicated servers for each customer, the service is efficient, available from all Regions, and can be instantly configured.

A virtual overlay network, called Wide-area Private Cloud (WPC),  is created immediately when you sign up for CloudConnexa. You will be asked to provide a Cloud ID, a unique identifier to identify your WPC. Your Cloud ID will be whatever you provide as long as it is unique. It's of the format [company_name].openvpn.com. By forming a URL with this Cloud ID https://[company_name].openvpn.com, you can access the Administration portal and import connection configuration files into clients. The connection configuration files are called connection Profiles. Connection profiles (.ovpn text files) contain the directives, parameters, and certificates required to establish the OpenVPN connection to Regions. These commonly include addresses and ports to contact the server, information for verifying peer identity, securing the TLS control channel, and other settings.

In simple terms, you can think about your CloudConnexa WPC (identified with the Cloud ID) as a virtual distributed router and a powerful next-generation firewall out there in the cloud and the 30+ worldwide Regions as the virtual ports of this router. How do you connect users, servers, and networks to the ports (that is, Regions) of this virtual distributed router (your WPC)? CloudConnexa uses the OpenVPN protocol to create secure encrypted tunnels over the internet to those Regions. Think of the OpenVPN tunnels as a virtual super-long ethernet cable that connects your devices to the ports of your cloud router (that is, your WPC). So, what is needed to create those tunnels? You need to use a client app on the device that needs to set up the tunnel. The official client is OpenVPN Connect. It is available for Windows, macOS, iOS, and Android. For Linux, we recommend using our open-source openvpn3 client, which also supports DCO, a technology that further improves data throughput performance. OpenVPN protocol-compatible routers like Ubiquiti and firmware like OpenWrt and others can be used, too. 

Why is the same OpenVPN client application sometimes called a client and sometimes a Connector? The term Connector distinguishes the connection from a typical on-demand client connection like that of remote users. Even though it is the same client app, the context in which it is set up in the Administration Portal and the corresponding connection profile allows the Connector to create an always-on unattended connection. A Connector provides access to applications hosted on servers it runs on or networks it connects to the WPC. So, to summarize, Connectors make networks and applications part of the WPC, and Devices with the client app installed are used to connect to the WPC to consume service made available via Connectors.

Hosts, Networks, and Applications are representations of an application server, a private Network, and any TCP/IP service with a domain name in CloudConnexa. So an application server on which the connector is installed to provide access to the application that is being served is represented as a Host in CloudConnexa, whereas a private network that provides access to the WPC for the devices on the network and can also provide access to others for applications hosted on that private network or site is represented as a Network entity in CloudConnexa. Applications are services that are identified by a domain name that are made accessible to the WPC. Services that need to be accessed using IP addresses are represented by IP Services.

Access Groups can be configured to control access to Networks, Hosts, and the Applications and IP Services they make available.

Once Connectors set up outbound tunnels to CloudConnexa Regions, your users can connect to any of the CloudConnexa Regions with their devices and access the Applications and IP Services your connected Networks and Hosts make available.