Connecting Networks to CloudConnexa Using Connectors
Introduction
Additional steps need to be taken after downloading and installing Connector software to ensure that proper routing of traffic occurs between your Networks and CloudConnexa. In this document, we take an in-depth look at traffic flows to help you understand why certain actions need to be taken and to also provide instructions and references for configuring the required functionality on the instance running the Connector.
We hope that this document helps in explaining the following:
The reason routing needs to be enabled on the instance running the Connector for a Network
The reasoning behind adding static routes to your Network’s router
When using NAT on the instance running the Connector might help
Remote access to private services
In this section, the traffic flow between a remote User that is connected to the CloudConnexa to access the HR application on the HQ Network is examined.
As shown in the figure, HQ Network is made up of the 10.0.0.0/18 subnet and a computer running Ubuntu is acting as the Connector on IP address 10.0.0.10
. The HR application server is at 10.0.0.20
. The HQ Network is connected to the Internet by a router that performs Network Address Translation (NAT) to provide the computers on the internal private Network with access to the Internet.
To make the routing work the following needs to be done:
Connector software needs to be installed on a computer in HQ Network (see, the section on Connector installation).
Routing needs to be enabled on the computer running the Connector software (see, the section on Enable Routing ).
Either NAT must be enabled on the computer running the Connector software (see, the section on enabling NAT) OR a static route needs to be added to the router on HQ Network (see, section on Static Routing).

The Admin adds a Network using the CloudConnexa Administration portal. The name of ‘HQ Network’ is given to the Network and
10.0.0.0/18
is added as its subnet.CloudConnexa in the background assigns
100.96.0.100
as the WPC IP address for the Connector created for HQ Network and configures its routing table to route all traffic destined to the HQ Network’s subnets (10.0.0.0/18
) to be forwarded to its Connector (100.96.0.100
).Admin downloads and installs the Connector software and connects with the CloudConnexa Profile to establish WPC connection to the preconfigured CloudConnexa Region.
During WPC connection establishment CloudConnexa pushes down a route to the WPC Subnet range (
100.96.0.0/11
).Once the connection is established, the WPC is represented by a virtual interface that receives packets from the WPC and will be used to send packets destined to
100.96.0.0/11
.Admin configures a User named Bob in a User Group that has its Internet Access set to (Split-Tunnel ON).
Bob receives the invitation email, downloads the Connect client, and imports the Profile after selecting the closest Region.
On connection, because Split-Tunnel is ON the virtual interface receives routes for both the CloudConnexa WPC IP subnet range as well as the subnet range of HQ Network.
Bob tries to access the HR application. As the HR application is in the HQ Network the packet is routed via the WPC interface.
When CloudConnexa receives the packet it checks its routing table and directs the packet to the Connector in HQ Network because of the destination IP address is in the subnet configured for HQ Network.
When the Connector instance receives the packet destined to
10.0.0.20
it drops it because the computer only expects to receive packets destined to it at either10.0.0.10
or100.96.0.100
.In order for the Connector instance to accept the packet destined at
10.0.0.20
received from its WPC interface and send it to the HQ Network LAN, the Connector needs to be configured to act as a router and forward IP packets using the right interface. Please see the section on Enable Routing.Now that routing is enabled, the Connector instance forwards the received packet on the LAN interface in order to reach the HR Application server.
The Application server responds to the packet and because of not knowing where to send the packet destined to an IP address in
100.96.0.0/11
it sends it to its default route which is the router.When the router receives the packet, it drops it because there are no entries on how to route this packet, and the destination IP address is not routable on the internet.
To resolve this issue, a static route can be added to the router informing it to forward all traffic destined to
100.96.0.0/11
to the Connector instance. See section for Add Static Routes for references.With the static route in place, the packet is forwarded to the Connector instance which, being already configured as a router, can route it via the WPC to its final destination (steps 21-22).
As an alternative to configuring the router with a static route, NAT can be enabled on the Connector instance. When NAT is turned ON, the Connector instance will substitute its IP address for the original source IP address, and on receiving the response, switch the destination to the original source IP. Please see the section on Enable NAT.
The packet now gets forwarded by the Connector instance as well as undergoes NAT so that when the packet is received by the Application Server it need not forward the response to the router but send the response right back to the Connector Instance.
On receiving the response, the Connector instance translates the destination and can forward the response on the WPC interface.
The response reaches the Connector instance either by use of Option 1 (static route) or Option 2 (NAT) and is sent to CloudConnexa.
CloudConnexa forwards the packet to Bob.
Option 1 or Option 2 — which is better? The static route Option 1 is better if you anticipate sending unsolicited traffic to remote clients from the Network. For example, if you want to ping Bob’s WPC IP address from the Application Server. NAT Option 2 is fine as long as all traffic sessions are always initiated by the remote client.
HQ Network being used as Internet Gateway route
In this traffic flow, we see how internet traffic exiting CloudConnexa and egressing from HQ Network is handled.
As shown in the figure, HQ Network is made up of the 10.0.0.0/18
subnet and a computer running Ubuntu is acting as the Connector on IP address 10.0.0.10
. The HQ Network is connected to the Internet by a router that performs Network Address Translation (NAT) to provide the computers on the internal private Network with access to the Internet. The service on the internet that is being accessed by Bob is at the IP address of 107.3.152.27
.
To make the routing work the following needs to be done:
Connector software needs to be installed on a computer in HQ Network (see, the section on Connector installation).
Routing needs to be enabled on the computer running the Connector software (see, the section on enabling routing).
Either NAT must be enabled on the computer running the Connector software (see, the section on enabling NAT) OR a static route needs to be added to the router on HQ Network (see, section on static routing).

The Admin marks HQ Network as an egress route for the WPC using the CloudConnexa Administration portal.
In the background, CloudConnexa adds the IP address of the HQ Network Connector as the default route for the WPC.
The Admin sets the internet access of the User Group to which Bob belongs to Split-Tunnel OFF.
Bob’s WPC connection is reset and CloudConnexa is made the default route destination.
Bob tries to access an Internet application (server IP address of
107.3.152.27
). As CloudConnexa is the default route, the packet is routed via the WPC interface.When CloudConnexa receives the packet it checks its routing table and directs the packet to the Connector in HQ Network because it has been set as the egress route for the WPC.
When the Connector instance receives the packet destined to
107.3.152.27
it drops it because the computer only expects to receive packets destined to it at either10.0.0.10
or100.96.0.100
.In order for the Connector instance to accept the packet destined at
107.3.152.27
received from its WPC interface and send it to the HQ Network LAN, the Connector needs to be configured to act as a router and forward IP packets using the right interface. Please see the section on Enable Routing.Now that routing is enabled, the Connector instance forwards the received packet on the LAN interface in order to reach the Network’s router.
The router performs NAT and forwards the packet to the server on the Internet.
When the router receives the response, it performs the NAT translation to get the destination address as an IP address in
100.96.0.0/11
.The router drops the response because there are no entries on how to route this packet, and the destination IP address is not routable on the internet.
To resolve this issue, a static route can be added to the router informing it to forward all traffic destined to
100.96.0.0/11
to the Connector instance. See section for Add Static Routes for references.With the static route in place, the packet is forwarded to the Connector instance which, being already configured as a router, can route it via the WPC to its final destination (steps 20-21).
As an alternative to configuring the router with a static route, NAT can be enabled on the Connector instance. When NAT is turned ON, the Connector instance will substitute its IP address for the original source IP address, and on receiving the response, switch the destination to the original source IP. Please see the section on Enable NAT.
The packet now gets forwarded by the Connector instance as well as undergoes NAT so that when the packet is received by the router the source IP address is
10.0.0.10
and not the IP address in100.96.0.0/11
.The router performs NAT and forwards the packet to the server on the Internet.
When the router receives the response, it performs the NAT translation to get the destination address as
10.0.0.10
(because the Connector instance had performed NAT on step 16) and forwards the response to the Connector instance.On receiving the response, the Connector instance translates the destination back to the IP address in
100.96.0.0/11
and can forward the response on the WPC interface.The response reaches the Connector instance either by use of Option 1 (static route) or Option 2 (NAT) and is sent to CloudConnexa.
CloudConnexa forwards the packet to Bob.
Option 1 or Option 2 which option is better? The static route Option 1 is better if you anticipate sending unsolicited traffic to remote clients from the Network and if the router will perform NAT for source IP addresses that do not belong to the HQ Network. NAT Option 2 is fine as long as all traffic sessions are always initiated by the remote client.
Site-to-Site
The flow below shows the traffic flows between two sites connected to CloudConnexa: HQ Network and Branch Network.
To make the routing work the following needs to be done:
Connector software needs to be installed on a computer in HQ Network and Branch Network (see, the section on Connector installation).
Routing needs to be enabled on the computer running the Connector software (see, the section on Enable Routing).
For proper routing here it is mandatory to add static routes to the Network routers on both sites. As new sites are added to CloudConnexa, it is mandatory to add to the existing static routes on each site with a route to the new Network’s subnets. See, the section on Static Routing.
Additionally, NAT can be enabled on the Connector instance too if there are internal firewalls or security groups around your Application servers that accept packets only from subnets belonging to the local Network (see, the section on enabling NAT).

The Administrator adds a Network using the CloudConnexa Administration portal. The name of ‘HQ Network’ is given to the Network and
10.0.0.0/18
is added as its subnet.CloudConnexa in the background assigns
100.96.0.100
as the WPC IP address for the Connector created for HQ Network and configures its routing table to route all traffic destined to the HQ Network’s subnets (10.0.0.0/18
) to be forwarded to its Connector (100.96.0.100
).Admin downloads and installs the Connector software and connects with the CloudConnexa Profile to establish WPC connection to the preconfigured CloudConnexa Region.
During WPC connection establishment CloudConnexa pushes down a route to the WPC Subnet range (
100.96.0.0/11
).Once the connection is established, the WPC is represented by a virtual interface that receives packets from the WPC and will be used to send packets destined to
100.96.0.0/11
.In order for the Connector instance to accept the packets received from its WPC interface and send it to the HQ Network LAN, the Connector needs to be configured to act as a router and forward IP packets using the right interface. Please see the section on Enable Routing.
A static route is added to the router informing it to forward all traffic destined to CloudConnexa (
100.96.0.0/11
) to the Connector instance. See section for Add Static Routes for references.The Administrator adds a Network using the CloudConnexa Administration portal. The name of ‘Branch Network’ is given to the Network and
192.168.0.0/22
is added as its subnet.CloudConnexa in the background assigns
100.96.0.300
as the WPC IP address for the Connector created for Branch Network and configures its routing table to route all traffic destined to the Branch Network’s subnets (192.168.0.0/22
) to be forwarded to its Connector (100.96.0.300
).WPC Connection to HQ Network’s Connector is quickly reset to push the new route of
192.168.0.0/22
.Now the WPC virtual interface will be used to reach both CloudConnexa and Branch Network.
Admin downloads and installs the Connector software and connects with the CloudConnexa Profile to establish WPC connection to the preconfigured CloudConnexa Region.
During WPC connection establishment CloudConnexa pushes down a route to the WPC Subnet range (
100.96.0.0/11
) and the HQ Network subnet range10.0.0.0/18
.Once the connection is established, the WPC is represented by a virtual interface that receives packets from the WPC and will be used to send packets destined to
100.96.0.0/11
and10.0.0.0/18
.In order for the Connector instance to accept the packets received from its WPC interface and send it to the HQ Network LAN, the Connector needs to be configured to act as a router and forward IP packets using the right interface. Please see the section on Enable Routing.
A static route is added to the router informing it to forward all traffic destined to CloudConnexa (100.96.0.0/11) to the Connector instance. See section for Add Static Routes for references.
A computer on HQ Network now tries to reach the Finance Server on the Branch Network. It sends the packet to the Network’s router.
The router drops the packet because it has no route to reach the
192.168.0.0/22
Network.A static route is added with the Connector instance as the destination for the Branch Network subnet.
Now, the packet is forward to the Connector instance from the router.
With routing already enabled, the Connector instance sends the packet to CloudConnexa using the WPC interface.
CloudConnexa forwards the packet on to the Connector instance in Branch Network.
When the Connector instance receives the packet destined to the Finance Server it forwards it on the LAN interface because it had been already set up as a router.
The Finance Server responds to the request but sends it to the Network’s router because the destination IP address of
10.0.0.0.13
does not belong to its LAN.The router forwards the packet to the Connector because of the static route configured for
100.96.0.0/11
.With routing already enabled, the Connector instance sends the packet to CloudConnexa using the WPC interface.
CloudConnexa forwards the packet on to the Connector instance in HQ Network.
When the Connector instance receives the packet destined to the computer on its LAN it forwards it on the LAN interface because it had been already set up as a router.
Now, a computer on the Branch Network tries to access the HR server that is in the HQ Network by sending the request packet to the router.
As the router does not have a static route for the HQ Network IP address range, it needs to be added in order to send the traffic flow to the Connector.
Installation of Connector
The steps for installation of the Connector are the same regardless of its use a Host or a Network Connector.
Enable Routing
Routing on Linux
To enable IPv4 forwarding, use the following commands on the command line:
sudo sed -i 's/#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/g' /etc/sysctl.conf
sudo sysctl -p
To enable IPv6 forwarding
sudo sed -i 's/#net.ipv6.conf.all.forwarding=1/net.ipv6.conf.all.forwarding=1/g' /etc/sysctl.conf
sudo sysctl -p
This will enable forwarding in the Linux kernel.
Routing on Windows
Please look at the documentation for your specific Windows version. For your convenience references on how to deploy the Routing and Remote Access Service for Windows Server 2016 are given below.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/ras/remote-access-server-role-documentationAfter installation of the routing and Remote Access service, do the following:
From Server Manager, click Tools, and select Routing and Remote Access.
From the Routing and Remote Access window, right click the server, and select Configure and Enable Routing and Remote Access.
On the first page of the set up wizard, click on the Next button.
Select Custom configuration and click on the Next button.
Select LAN routing and click on the Next button.
On the summary page, click on the Finish button.
Finally, to start the service, click on the Start service button and wait for the service to start. The dot on the server will turn the color green from the color red.
Now, expand the server and expand IPv4 entry to click on the General node. The computer is now acting as a router between the interfaces shown.
Routing on macOS
Open the Terminal application and type
sysctl -w net.inet.ip.forwarding=1
Enable NAT
NAT on Linux
Use the following commands on the command line:
sudo apt install iptables-persistent
IF=`ip route | grep default | awk '{print $5}'`
sudo iptables -t nat -A POSTROUTING -o $IF -j MASQUERADE
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables -t nat -A POSTROUTING -o $IF -j MASQUERADE
sudo iptables-save | sudo tee /etc/iptables/rules.v6
The iptables rule uses the NAT packet matching table (-t nat)
and specifies the built-in POSTROUTING
chain for NAT (-A POSTROUTING)
on the external networking Device (-o $IF)
. The variable ‘IF’ stores the default interface. POSTROUTING
allows packets to be altered as they are leaving the Connector instance. The -j MASQUERADE
target is specified to mask the private IP address of a node with the IP address assigned to the default interface.
The above is sufficient if you are fine with all traffic being NATted. However, if you need Hosts on the Network to distinguish between different WPC clients or Connectors, you need to use “! -d xx.xx.xx.xx/xx
” in the NAT rule where xx.xx.xx.xx/xx
is the subnet of the target LAN subnet, otherwise traffic to that subnet will also be NATted. The example below shows how to use the iptables command so that NAT is not used if the destination is in the 10.10.0.0/16
subnet.
sudo iptables -t nat -A POSTROUTING -o $IF ! -d 10.10.0.0/16 -j MASQUERADE
NAT on Windows
A tutorial can be found here:
NAT on macOS
Create a file called
pf-nat.conf
with the following content:nat on en0
fromutun0
to any-> (en0)
Save the file and now start
pfctl
using the rule from the file we have created earlier:sudo pfctl -d
#disablespfctl
sudo pfctl -F all
#flushes allpfctl
rulessudo pfctl -f /Path/to/file/pf-nat.conf -e
#starts pfctl and loads the rules from thepf-nat.conf
file
Special Considerations for IaaS
Security Groups
If you are using Security Groups to protect any instances that need their traffic to be routed through the Connector instance, you need to add the Security Group of the Connector instance to their inbound rules.
AWS
Set Source/Dest Check
Virtual servers provided by IaaS providers use virtual Network interface cards (VNIC). By default, every VNIC performs the source/destination check on its Network traffic. The VNIC looks at the source and destination listed in the header of each Network packet. If the VNIC is not the source or destination, then the packet is dropped.
In order for the instance on which the Connector is installed to perform routing or NAT functionality the Source/Dest check on the VNIC needs to be turned OFF.
Please refer to the documentation provided by your IaaS provide to disable source/dest check. For your convenience documentation references are provided below:
AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck
Oracle: https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingVNICs.htm
Azure: IP forwarding must be enabled at the VNIC https://docs.microsoft.com/en-us/azure/virtual-Network/virtual-Network-network-interface#enable-or-disable-ip-forwarding
GCP: https://cloud.google.com/vpc/docs/using-routes#canipforward
Also, note that when running some Linux firewall packages, rpfilter
is sometimes turned On
https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html. In addition to source/dest check, rp_filter
in sysctl.conf
should be turned Off
AWS Route Updates
If you have followed the instructions for using CloudFormation to install Connector on AWS, any needed static routes will be added to the VPC route table by the Connector. There is no need to manually add static routes in the VPC route table.
Add Static Routes
All routers provide the ability to add a static route. Please refer to your router documentation. For Virtual Cloud Networks, we have provided references below for some IaaS providers.
A static route needs to be added to the WPC IP address range of CloudConnexa. The default WPC IP address range is 100.96.0.0/11
for CloudConnexa. The static route added should have 100.96.0.0/11
as the destination IP address range and the private IP address of the Connector instance as the Target.
A static route needs to be added for the destination subnet ranges of your other Networks that are connected to CloudConnexa too.
The figure below shows the static routes added to a VPC route table. You can see that there are three routes pointing to eni-06e725657ba3a8f63
(the instance that is running the Connector software). 172.31.0.0/16
is the subnet of another Network that can be accessed via CloudConnexa.

AWS: If you have followed the instructions for using CloudFormation to install Connector on AWS, any needed static routes will be added to the VPC route table by the Connector. There is no need to manually add static routes in the VPC route table. See, Launch Connector on AWS
Azure: Azure calls static routes as ‘User-defined’. See, https://docs.microsoft.com/en-us/azure/virtual-Network/virtual-Networks-udr-overview
GCP: https://cloud.google.com/vpc/docs/using-routes
Oracle Cloud: See, using Private IP as a route target https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/managingroutetables.htm#Route