Skip to main content

Connecting Networks to CloudConnexa Using Connectors

In this section:

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:

  1. Connector software needs to be installed on a computer in HQ Network (see, the section on Connector installation).

  2. Routing needs to be enabled on the computer running the Connector software (see, the section on Enable Routing ).

  3. 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).

62e9bafe58266.png

  1. 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.

  2. 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).

  3. Admin downloads and installs the Connector software and connects with the CloudConnexa Profile to establish WPC connection to the preconfigured CloudConnexa Region.

  4. During WPC connection establishment CloudConnexa pushes down a route to the WPC Subnet range (100.96.0.0/11).

  5. 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.

  6. Admin configures a User named Bob in a User Group that has its Internet Access set to (Split-Tunnel ON).

  7. Bob receives the invitation email, downloads the Connect client, and imports the Profile after selecting the closest Region.

  8. 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.

  9. Bob tries to access the HR application. As the HR application is in the HQ Network the packet is routed via the WPC interface.

  10. 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.

  11. 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 either 10.0.0.10 or 100.96.0.100.

  12. 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.

  13. Now that routing is enabled, the Connector instance forwards the received packet on the LAN interface in order to reach the HR Application server.

  14. 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.

  15. 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.

  16. 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.

  17. 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).

  18. 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.

  19. 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.

  20. On receiving the response, the Connector instance translates the destination and can forward the response on the WPC interface.

  21. The response reaches the Connector instance either by use of Option 1 (static route) or Option 2 (NAT) and is sent to CloudConnexa.

  22. 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:

  1. Connector software needs to be installed on a computer in HQ Network (see, the section on Connector installation).

  2. Routing needs to be enabled on the computer running the Connector software (see, the section on enabling routing).

  3. 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).

62e9bb00b1ac4.png

  1. The Admin marks HQ Network as an egress route for the WPC using the CloudConnexa Administration portal.

  2. In the background, CloudConnexa adds the IP address of the HQ Network Connector as the default route for the WPC.

  3. The Admin sets the internet access of the User Group to which Bob belongs to Split-Tunnel OFF.

  4. Bob’s WPC connection is reset and CloudConnexa is made the default route destination.

  5. 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.

  6. 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.

  7. 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 either 10.0.0.10 or 100.96.0.100.

  8. 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.

  9. Now that routing is enabled, the Connector instance forwards the received packet on the LAN interface in order to reach the Network’s router.

  10. The router performs NAT and forwards the packet to the server on the Internet.

  11. 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.

  12. 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.

  13. 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.

  14. 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).

  15. 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.

  16. 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 in 100.96.0.0/11.

  17. The router performs NAT and forwards the packet to the server on the Internet.

  18. 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.

  19. 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.

  20. The response reaches the Connector instance either by use of Option 1 (static route) or Option 2 (NAT) and is sent to CloudConnexa.

  21. 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:

  1. Connector software needs to be installed on a computer in HQ Network and Branch Network (see, the section on Connector installation).

  2. Routing needs to be enabled on the computer running the Connector software (see, the section on Enable Routing).

  3. 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.

  4. 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).

62e9bb02af7d9.png

  1. 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.

  2. 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).

  3. Admin downloads and installs the Connector software and connects with the CloudConnexa Profile to establish WPC connection to the preconfigured CloudConnexa Region.

  4. During WPC connection establishment CloudConnexa pushes down a route to the WPC Subnet range (100.96.0.0/11).

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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).

  10. WPC Connection to HQ Network’s Connector is quickly reset to push the new route of 192.168.0.0/22.

  11. Now the WPC virtual interface will be used to reach both CloudConnexa and Branch Network.

  12. Admin downloads and installs the Connector software and connects with the CloudConnexa Profile to establish WPC connection to the preconfigured CloudConnexa Region.

  13. During WPC connection establishment CloudConnexa pushes down a route to the WPC Subnet range (100.96.0.0/11) and the HQ Network subnet range 10.0.0.0/18.

  14. 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 and 10.0.0.0/18.

  15. 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.

  16. 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.

  17. 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.

  18. The router drops the packet because it has no route to reach the 192.168.0.0/22 Network.

  19. A static route is added with the Connector instance as the destination for the Branch Network subnet.

  20. Now, the packet is forward to the Connector instance from the router.

  21. With routing already enabled, the Connector instance sends the packet to CloudConnexa using the WPC interface.

  22. CloudConnexa forwards the packet on to the Connector instance in Branch Network.

  23. 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.

  24. 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.

  25. The router forwards the packet to the Connector because of the static route configured for 100.96.0.0/11.

  26. With routing already enabled, the Connector instance sends the packet to CloudConnexa using the WPC interface.

  27. CloudConnexa forwards the packet on to the Connector instance in HQ Network.

  28. 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.

  29. 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.

  30. 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.

Connector on Linux

Connector on Windows

Connector on macOS

Connector on AWS

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-documentation

After 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.

See, Connecting to a Windows Server 2016 Network

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

  1. Create a file called pf-nat.conf with the following content: nat on en0 from utun0 to any -> (en0)

  2. Save the file and now start pfctl using the rule from the file we have created earlier:

    sudo pfctl -d #disables pfctl

    sudo pfctl -F all #flushes all pfctl rules

    sudo pfctl -f /Path/to/file/pf-nat.conf -e #starts pfctl and loads the rules from the pf-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

https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html

Launch Connector on 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.

Launch Connector on AWS

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.

62e9bb0838b2d.png

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