Skip to main content

About Networks

Abstract

A CloudConnexa Network is a representation of your actual physical private network. It represents the Routes to your physical network and the reachable Applications and IP Services.

Users can connect to the private overlay network created by CloudConnexa and get protection from cyber threats if Cyber Shield Domain Filtering Basic Protection has been set. However, you need to connect a network to allow users to access the private applications on it or to use it as a means to access the Internet.

Connectors that connect your private network to your WPC make an outbound, unattended, always-on tunnel to a CloudConnexa Region of your choosing. A Connector installed on a computer or virtual machine acts as a software router. OpenVPN-compatible and IPsec routers can act as Connectors. For more information on Connectors, refer to About Connectors and About Network Connectors.

Once a Connector is online, any private or public application or service reachable by that network is accessible. It is recommended to configure reachable services as an Application. A DNS record must be added, or a private DNS server must be used to resolve domain names to IP addresses for configured Applications representing private applications. If IP routing is desired, IP Services need to be configured.

Note

Configure a Host to access all applications and services hosted on an application server rather than connecting the entire private network to CloudConnexa. Refer to About Hosts.

A network can be connected to CloudConnexa using multiple Connectors that can setup tunnels to different CloudConnexa Regions for geographic redundancy or the same Region for increased throughput and fault tolerance. For example, connect your corporate network using two Connectors to the Chicago Region, and remote access traffic from your employees will be equally distributed among them. If one of the Connectors goes down, all remote access traffic will use the Connector that is up and connected.

CloudConnexa uses smart routing if multiple Connectors are used. CloudConnexa will optimize the route to your network based on the Region the remote user uses. For example, one of your Network’s Connectors uses the San Jose Region while the other uses Chicago. Traffic from a remote worker connected to Los Angeles will be routed via San Jose, and traffic from a remote worker connected to Ashburn, VA, will be routed via Chicago. The routing logic is based on geographic proximity and also considers network characteristics.

Common scenarios explained with examples

You have an AWS VPC with a subnet of 10.0.0.0/24. A web application named 'webapp' is running on IP address 10.0.0.14, and an FTP server named 'ftpapp' is running on 10.0.0.15.

To provide remote access to this VPC:

You log in to the CloudConnexa Administration Portal and add a Network. Let us name it 'AWS_VPC_London'.

Add a Connector to 'AWS_VPC_London,' which will be used to connect it to the closest CloudConnexa Region using IPsec or deploy an OpenVPN Connector on it. With connectivity done, let us discuss routing options:

  • [Recommended] Application Domain-based Routing

    It allows you to easily route traffic to applications distributed among your various connected private networks, using the application’s domain name as a route to the network where that application resides. In addition, the defined applications can be used in configuring access control.

    You add two Applications to the 'AWS_VPC_London' Network and give them domain names: webapp.aws.local and ftpapp.aws.local. Add DNS record for each Application mapping webapp.aws.local to 10.0.0.14 and ftpapp.aws.local to 10.0.0.15.

  • IP routing

    Identifies which traffic needs to be routed to the connected network based on the subnet IP addresses configured for that network as IP Services.

    If you need to use IP routing for 'AWS_VPC_London', you would configure two IP Services: webapp with subnet 10.0.0.14/32 and ftpapp with 10.0.0.15/32.

    Note

    You cannot add another Network with IP Services that conflict with 10.0.0.14/32 and 10.0.0.15/32 because they act as implicit routes for the 'AWS_VPC_London' Network. Therefore, we recommend using Application Domain-based Routing whenever possible.

Note

A Network can be configured with both Applications and IP Services (i.e., both kinds of routing can be used in conjunction).

Note

To use the AWS VPC to reach specific SaaS apps or other internet destinations:

You want to add another layer of security to SaaS to protect against compromised credentials, man-in-the-middle attacks, and other cyber threats. You decide that all access to SaaS must be via CloudConnexa because you want to use all its security features.

To selectively steer traffic to specific domain names via CloudConnexa while all other internet traffic uses the local internet, you need only add the domain names to a connected network with internet access. For example, just add salesforce.com as an Application to the 'AWS_VPC_London' Network. No DNS record is needed as it is a public domain name.

Traffic to salesforce.com will now exit the WPC to the Internet from the 'AWS_VPC_London' Network. You can set the login policy on your SaaS app to only allow logins from the public IP address of the AWS network, thus enforcing that all access is via CloudConnexa.

To use the AWS VPC as the default route to the internet

You have deployed various cybersecurity and data protection solutions on your AWS VPC and want all internet traffic from your workforce to be routed through the AWS VPC for analysis and protection. To achieve this, you need to do two things:

  1. Set the Internet Access for User Groups to' Split Tunnel OFF' to bring all the traffic from user devices to CloudConnexa.

  2. Turn ON the Internet Gateway setting for 'AWS_VPC_London' Network. Refer to Make a Network act as an Internet Gateway

To provide remote access to an Azure VNet with an IP address range that overlaps the AWS VPC:

You now need to provide remote access to Azure VNet due to an acquisition made by your company. It so happens that the Vnet uses the same subnet 10.0.0.0/24 as the already connected 'AWS_VPC_London' Network. Connecting the VNet to CloudConnexa would not have been possible using IP routing. But, if you had used Application Domain-based Routing with 'AWS_VPC_London' Network, you can add a new Network and just use a different domain to identify and route to applications on the VNet. For example, while webapp.aws.local is routed to 10.0.0.14 on the AWS VPC, timecard.vnet.local can be routed to the 10.0.0.14 on the VNet by adding a Network to represent the VNet, configuring an Application with the domain name of timecard.vnet.local, and adding a corresponding DNS record.

To add site-to-site connectivity between the AWS VPC and Azure VNet:

Assuming both the AWS VPS and Azure VNet use OpenVPN Connectors, and application domain-based routing, for site-to-site routing to work properly, you need to:

  1. Add a route to the VPC and VNet route tables to set the private IP address of the Connector as the next hop (target) for destination IP addresses in the range used for domain routing (default range of 100.80.0.0/12) and your WPC (default range of 100.96.0.0/11). Refer to, Set the IP Subnet range from which to assign Domain Routing IP addresses and Set the IP Subnet range from which to assign Tunnel IP addresses.

  2. All the instances on the cloud network should use the Connector as the DNS Server. The IP address of the DNS server is one before the tunnel IP address of the Connector. For example, if the tunnel IP address of the Connector is 100.96.1.18, then the DNS server IP address is 100.96.1.17.

Once the above setup is done, if a VM in AWS wants to communicate with timecard.vnet.local on Azure, a DNS request is made to CloudConnexa because of step 2. The DNS response is of an intermediary IP address in the 100.80.0.0/12 range which results in the traffic going to CloudConnexa via the Connector because of step 1. CloudConnexa then routes it to 10.0.0.14 on the VNet.

Note

Site-to-site routing using Application Domain-based Routing, as shown in the above example, may not work with IPsec Connectors used to connect to IaaS providers but may work with connections to on-prem routers.

If the Networks for the site-to-site networking have IP Services configured, then instead of relying on CloudConnexa DNS and the domain routing IP address range, the static routes can use the IP address subnet ranges of the actual networks. For example, if the AWS VPC uses a subnet range of 192.168.0.0/24 and the Azure VNet has a subnet range of 10.0.0.0/24, then the VNet routing table would need two entries with the Connector as the next hop: 192.168.0.0/24 (AWS VPC subnet) and 100.96.0.0/11 (WPC subnet). Similarly, the routing table of the AWS VPC would need two entries with the Connector as the next hop: 10.10.0.0/24 (Azure VNet subnet) and 100.96.0.0/11 (WPC subnet).

In this section:
See also: