Hi
I was originally going to do a blog post on using vCNS Edge as a VXLAN gateway as a follow-on from my previous blog posts. I have put that on hold due to the release of vCloud Connector 2.0 which has a feature of great interest to me, the "Datacenter Extension".
Everything below is my own personal interpretation of vCloud Connector 2.0 from my own testing.
My lab is a Hybrid Cloud comprising of a vSphere 5.1 Datacenter as the source cloud and a Public Cloud based on vCloud Director 5.1.1, destination cloud. Both environments are using vCNS 5.1.2 as this is required for the Datacenter Extension feature and I decided to use VXLAN's in both clouds.
I won't go into details of how to install vCloud Connector 2.0 as there are plenty of blogs out there and from what I can see there isn't a great deal of difference in installation and initial configuration other than enabling the two clouds for stretched deployments.
In my vSphere 5.1 Datacenter I have a 2 VM's on a single VXLAN behind a vCNS Edge with a single external network. The VXLAN is in the subnet 10.1.0.0/24 with a default gateway of 10.1.0.1 which is assigned to the vCNS Edge's internal interface. I also have a vCloud Connector Server and Node deployed in this vSphere 5.1 Datacenter.
In the vCloud 5.1.1 environment I have a single vCloud Connector Node, and single routed OrgVDC Network with an external IP sub allocation on the vCNS Edge for this network. This OrgVDC network is a VXLAN.
Both the node in the vSphere Datacenter and the node in the vCloud environment are registered to the vCloud Connector Server and nodes registered to the respective vCenter or vCloud.
What I want to achieve is to copy the powered off VM "UniVM01" on the vSphere 5.1 Datacenter to a new vAPP on my org on the vCloud environment. As this is a stretched deployment the network UniVM01 is attached to will be extended into the vCloud environment.
Below is the process I went through to copy the VM over and stretch/bridge the connected network.
On the vCenter server for the source cloud "vSphere 5.1 datacenter" click on the vCloud Connector Plug-in then select UniVM01 and from the Actions button select "Stretch Deploy".
At this point you are given the option to select the target cloud, in this case the vCloud lab environment. Give it a name, and select an existing catalog to use.
Click next, then you are prompted to select the target resources(Org VDC, OrgVDC Network and the external IP address that will be used to DNAT the SSL VPN traffic to the vCNS Edge that will be created to terminate the SSL VPN to).
Click next, then if required select any proxy settings required, in this case none are required.
click next again and select "power on deployed entity" to power on the copied VM UniVM01.
Then click next again where you are presented with a summary of the deployment, then click finish for the deployment process to start.
If successful a new vAPP will be created in the vCloud Org as below, this will be a routed vAPP connected to the OrgVDC Network using a vCNS Edge. The external IP address of this new vAPP Edge will be NAT'ed on the OrgVDC Edge to the external network. The internal IP address of this new vCNS edge will have the same IP address as the existing vCNS Edge on the vSphere 5.1 Datacenter "10.1.0.1". This new vAPP vCNS Edge from what I can see then runs a SSL VPN Server in bridged mode with a local and remote network of both 10.1.0.0/24.
vCloud connecter it seems then configures the existing vCNS Edge on the vSphere 5.1 Datacenter to to start a SSL VPN client in bridged mode and connect to the new vCNS Edge in vCloud.
## Screen shot of new vAPP created in vCloud ##
At this point I ran a constant ping from UniVM02 (10.1.0.111) which is running on the vSphere 5.1 Datacenter to UniVM01 (10.1.0.222) running in vCloud. Both VM's on the same L3/L2 domains but on different VXLAN's in different Datacenters. As expected the pings succeeded 
North/South traffic i.e. traffic from external to UniVM01 will go via the vCNS Edge on the vSphere 5.1 datacenter which I tested successfully using a DNAT and firewall on the vCNS Edge on the vSphere 5.1 Datacenter.
At this point I thought it would be interesting to have a poke around the config of both the vCNS Edges using both the vShield Manager and Edge CLI, the results I found didn't fully add up as explained below.
On the vShield Managers for both environments vSphere 5.1 and vCloud it shows that IPSec VPN is enabled with an active tunnel with a local and remote network of 10.1.0.0/24 with a tunnel status of UP, mmm strange as this is documented as an SSL VPN. Debugging traffic flows between both vCNS Edges also as far as I can see shows no IPSec traffic.
## vCloud vCNS Edge IPSec status ##
## vSphere 5.1 Datacenter vCNS Edge IPSec status ##
The Edge CLI of both Edges also shows an IPSec VPN config but shows no active VPN sessions??
Checking the status of the vCNS Edge in the vCloud environment using the vShield Manager GUI shows that SSL VPN is disabled but with a single active SSL VPN session "acting as the server" which again doesn't add up?
The vCloud Edge CLI shows that the SSL VPN tunnel is up and passing traffic.
Neither vCNS Edges have any visible SSL VPN config that I can see from either the vShield Manager GUI or CLI.
The vCNS Edge on the vSphere 5.1 Datacenter doesn't show SSL VPN as enabled either as expected as this is acting as client. This vCNS Edge has started an SSL VPN to the vCNS Edge in vCloud using the process "naclientd" which I assume is the NeoAccel SSL VPN client but I could be wrong as this is just an assumption"
Just to be sure the ping traffic was traversing the SSL VPN Bridge I ran a constant ping from UniVM01 in vCloud to UniVM02 on the vSphere 5.1 Datacenter and then debugged the traffic flow on the vCloud vCNS Edge internal and external interfaces which shows that the ICMP traffic enters the internal interface and SSL VPN traffic exits the external interface.
## Internal Interface debug ##
## External Interface Debug ##
One interesting thing to note is how even though each vCNS edge vSphere 5.1 Datacenter and vCloud environment both have the same internal IP address 10.1.0.1 the VM's attached to their respective Edges has an ARP entry for 10.1.0.1 matching the MAC address of the local vCNS Edge.
Doing this blog post has raised more questions for myself on how this Layer 2/Bridge SSL VPN feature works and how you can debug/fault find any issues. But all-in-all this is a great feature and very easy to use.
I'm still doing some testing on the vCloud Connector 2.0 so hope to update this blog post as I learn more. I would appreciate any comments on any aspects I may have incorrect or miss interpreted.
Thank you for reading.
Regards
Kev Barrass