Providing VPN access to vCD customers is a great idea, because usually customers are behind a vCloud created firewall and most likely you created a routed organization VDC network to connect them to external network. So, how they have to get access to their VDC? One approach could be to define different sets of firewall and NAT rules for required access ports (SSH, RDP, …) but when the number of VM’s grow, this would be less flexible but of course still doable. Even a customer can get access to only one VM and go through this single VM to access the others; however sometimes it’s not a simple remote access and remote user wants to do a more advanced task.
By the way, I don’t want to go into the details of benefits of having a VPN for remote clients but it seems like a very helpful facility for cloud customers. We can leave it to the user to install its own VPN server to tunnel through to get access to organization VDC network but VMware provides this excellent capability to setup VPN gateways in vCloud Director or vSphere Cluster. For a Site-to-Site IPsec VPN, VMware vCD is pretty much straight forward. So, if you have a VPN gateway in place, easily you can establish a tunnel between your local network and your organization network in the cloud. I found this guide about setting up an IPSec tunnel in vCloud Director with useful examples, one with a Cisco WAN router. Here is another guide for a Cisco PIX and vCD; although the vCD version is old (1.5) but it’s too similar in terms of VPN tunnelling.
However, if you don’t have a VPN endpoint in-place and still want to establish a secure VPN-connection with your vCD organization network as a remote user, VMware provides this brilliant SSL VPN utility. It’s not as straight forward as IPsec VPN and it’s not present in vCD web portal but it worths deploying (especially for customers). VMware SSL VPN should be configured in vCloud Networking and Security solution (which is a new name for vShield Manager).
I’m not writing a How-To for this here and a complete step by step guide can be found here, very well explained by Ranga Maddipudi. I just wanted to give some idea and as you can see, deploying a SSL VPN gateway is fairly easy and an installable file (.exe file for Windows) will be provided. To get this file, on the client side use should use the browser to download the file. The URL for downloading the package would be: https://external-ip-address-of-gateway:443
After getting the file, user can easily install the VPN client and that’s it.
Running the application and entering the right credentials, VPN connection will be established and given that the configurations are server side are well defined, remote user will get access to VDC organization network in the cloud. In fact, what excites me is that from engineering point of view, VMware did a great job to ease the whole procedure of setup a connection on both server and client side; in specific, generating a custom designed VPN client using SSL (as authentication and encryption protocol) VPN is a brilliant idea.
Sometimes you feel like implementing a powerful edge gateway in your VMware vCloud environment. Let’s say you have heavy load and you plan to use load balancer capability of edge gateway in VMware vCloud Director. Unfortunately hardware configuration of vShield edge gateways are not customizable through vCloud Director and changing hardware configuration through vCenter is not possible. Also, hardware templates for use as edge gateways are limited in terms of processing power and memory. There are 3 pre-defined hardware configurations in vCloud Director 5.5: Compact, Full and Full-4. Full-4 type is a new one in vCloud 5.5 and as I know Full gateways in vCloud 5 are upgraded to Full-4 automatically when you upgrade the infrastructure to version 5.5. In brief, hardware configurations for vShield edge gateways are as follows:
- Compact: 1 * vCPU and 256 MB of Memory – 64000 concurrent sessions
- Full: 2 * vCPU and 1024 MB of Memory – 1,000,000 concurrent sessions
- Full-4 (new in vCloud 5.5): 4 * vCPU and 1024 MB of Memory
I didn’t find updated detailed information for vCloud 5.5 but you can see more details about edge gateway specifications and performance parameters in vCloud Director 5.1 at this useful link.
As you see, hardware power is limited especially in regards to memory. So, in case you need a memory intensive edge gateway (Load balancer is a good example) you need to upgrade the hardware. Although there is no direct method to this through vCloud Director admin panel, the fact is that vShield Manager has this capability to implement x-large gateways. x-large edge gateway in VMware Networking and Security 5.5 has 4 * vCPU and 8GB of Memory that is quite considerable.
As VMware recommended, if you need to upgrade hardware configuration of an edge gateway in vCloud Director, you can use vShield portal to do so. As it’s shown in the following picture, login to vShield Manager admin panel, choose your Datacenter, on ‘Network Virtualization’ tab select ‘Edges’, click on the edge gateway you intend to upgrade and finally from Actions menu choose: ‘Convert to X-Large’. That’s all.
Just keep in mind that in the picture above login to vShield Manager is done via vCenter. So, the ‘Network Virtualization’ tab shown in the figure is within vCenter; however it’s a bit difficult to get into vShield Manager through vCenter and I faced some weird errors about Acrobot Adobe! As a result, I recommend to use vShield Manager directly to avoid such issues.
When you want to upgrade VMware vCloud Director 5.1 to version 5.5, VMware vCloud Networking and Security should be upgraded to 5.5 as well because vCloud Director 5.5 is not backward compatible with vShield 5.1. Unfortunately and surprisingly, the documentation on VMware website to do so is not accurate! and it took some time for me to realize what’s the correct procedure. So, I thought it would be useful to share it here for those who can’t find the things mentioned in VMware website to upgrade VMware vCloud till they modify the documentation.
Actually, the part which is not accurate is where it explains the steps to upgrade vShield Edge appliances and it is a crucial part because failing to do this will result in failure in managing Edge gateways through vCloud Director interface. Since there would be one vShield Edge system appliance for each Edge Gateway that is created in Virtual Data Centers, you will have considerable number of vShield Edges in your environment and you should take care of them one by one. By the way, after upgrading vShield Manager to 5.5 is done (it’s easy, just uploading the upgrade bundle in vShield web console and reboot), the most important one is Upgrading vShield Edge.
Let’s look at the document on VMware website: Best practices for upgrading to VMware vCloud Networking and Security 5.5 , it says:
If you have vShield Edge 5.1.0 or later instances, upgrade each Edge:
- Log in to the vSphere Client.
- Click the data center for which vShield Edge instances are to be upgraded.
- Click the Network Visualization tab. All existing vShield Edge instances are shown in the listings page. An arrow icon is shown for each vShield Edge that must be updated.
- Click an Edge and click Upgrade from Actions to start the upgrade. When the Edge is upgraded, the arrow icon no longer appears.
- Repeat for each vShield that must be upgraded
After logging in to vSphere client, you will notice that there is no “Network Visualization” tab, but instead “Network Virtualization” tab. It must be a typo but even after clicking on “Network Virtualization” you will face some errors complaining about not having Acrobot Adobe Reader and so on! While the proper way to do this is to Log in to vShield Manager Web console (not vSphere Client) and look for Network Virtualization (instead of Visualization) under your DataCenter and the rest of steps are the same. You need to choose each Edge, select “Actions” on the top and choose “Upgrade” which will result in an automatic upgrade of that special Edge Gateway to new version.
I hope they modify their document because it is considered as the most reliable one.