For customers looking to leverage the relatively new NetScaler Cloud Bridge feature, I would like to share some implementation specific details for extending an on-site data center network to the cloud provider network. For some basic feature background, please refer to our sites here and here. Ok, if you are like me you probably didn’t read all the way through the links. So here in summary, NetScaler Cloud Bridge provides a secure and seamless extension of your on-site resources to an off-site cloud provider network allowing you to leverage a “hybrid cloud”. This is achieved by bridging the two networks at networking Layer 2 with an IPsec over GRE implementation on NetScalers implemented at both sites.
First things first, please stay tuned for a step-by-step NetScaler Cloud Bridge implementation guide that Citrix Consulting will publish soon and till then refer this thread by Pete Downing for a complete command line reference.
Let’s understand some of the pre-requisites to implement a Cloud Bridge:
- You will need either NetScaler VPX or MPX (nCore) implemented at both sites.
- You will also need a NetScaler Platinum license for all platforms and for VPX-10, VPX-200 and MPX 7500 platforms either a Platinum or a Cloud Bridge stand-alone license.
- Both NetScaler devices should be publicly accessible to each other in order to establish a peer connection. (NATing is supported).
- A pre-defined shared key or a public-private key exported on both the NetScaler devices to establish an ‘IPsec Peer’ connection.
- The following Firewall ports will need to be open for both sites:
- In case of NAT-T open UDP Port 4500
- IP Protocol ID 50 for IPsec Encapsulating Security Protocol (ESP) traffic
- IP Protocol ID 51 for IPsec Authentication Header (AH) traffic
- UDP port 500 for Internet Key Exchange (IKE/ISAKMP) negotiation traffic
In addition to the above mentioned list, the most important requirement to keep in mind is the presence of the same internal network to be bridged on both sites. Let’s consider an example. As illustrated in the figure below, we have the network 172.16.0.0/24 bridged between two sites using the NetScaler Cloud Bridge feature. The requirement is that both sites must have a 172.16.0.0/24 network present. Once the bridge is established and this common network is extended to both sites, other internal private networks local to each site can route through the bridge if required. So if 10.0.0.0/24 is a network in your internal corporate data center, it can now route to the 192.168.0.0/22 network that might exist on the cloud service provider network through the bridged 172.16.0.0/24 network.
The key here is that 172.16.0.0/24 (or any common network) exists on both sites. This is the fundamental purpose of implementing a Cloud Bridge – to bridge (L2) the same internal network over public networks on to the cloud network. (Sorry if you don’t like my color choices below)
[My example consists of a static route for the purposes of simplicity. To avoid any potential local network routing conflicts, you can leverage policy based routing instead of static routes]
What this also means is that while designing your Cloud Bridge implementation; you need to ask your cloud service provider for a list of internal networks that you wish to extend from your data center. Typically, this shouldn’t be an issue because the cloud provider, in most cases, should be able to assign internal networks as per your request. After all it’s supposed to be our own cloud, right? Yes. But just in case you require some modification to this requirement, you can also leverage NetScaler VPX to your advantage. As a work around to requesting the same private network on the cloud provider network, you can create a “Single-Server Private Network” on one of the hypervisor hosting VPX to use it as your common bridge network between the two sites. Once you have the bridge established for network, you can make your other internal networks accessible based on the routing scenario explained earlier.
I am sure there are many other interesting Cloud Bridge deployment use cases that we will discuss as we come across them. And you are also more than welcome to share those with us.
I find your feedback to be valuable so please feel free to reach out with questions and/or comments.