Understanding the “Proxy” Connection
The vCloud Director Cell is in fact proxying the connection between the client and ESXi. It is sitting in the middle as any proxy does. This is to allow the client to open the console without directly connecting to an ESXi host in the provider. For this to work, the Cell needs to have not only proper communication to and from the guest on the Console Proxy port, but also to the ESXi hosts. It also needs proper DNS setup to find the ESXi hosts by their name listed in vCenter. If that fails you will be chasing your tail. Below is just a simple graphic showing that the cell is in fact in the middle of the process.
First and Foremost – Routing
You are building a Linux operating system with multiple interfaces. What does this mean to you? Well if you are savvy with networking you know that the fundamental requirements of TCP/IP will always remain true. Most important that systems will have a single Default Gateway for routing. Where we see the most trouble is that people use different networks for their various ports. This is okay, it is not a bad thing…..as long as you configure all your routing properly. For example, below are four common IP configurations for a vCloud Director Cell:
- Linux Management – 192.168.1.10
- vCloud HTTP – 192.168.2.10
- vCloud Console Proxy- 192.168.3.10
- vCloud NAS Connection – 192.168.4.10
Any one of the networks above could use the default gateway, but which ones even make the most sense? Which interface is going to be used the MOST often and need the easiest path back to clients? In my opinion, that is usually the vCloud HTTP port. Although some may argue the console proxy, or management port, I say the purpose of the cell’s existence is to provide portal or API access. That all happens through the HTTP port.
Now then, what happens when you need to reach the other ports? What do you need on top of the default gateway? Anyone? STATIC ROUTES!! The other networks may OR may not need them. I will say the ones that would require them for sure is the vCloud Console Proxy. The diagram below illustrates a basic layout with the above network examples (although not as pretty as Hany’s). Once you decide which interfaces will be routed and which ones will not be, you will need to set up the correct static routes.
The NAS connection for the transfer space MIGHT need it, but of the NAS share is on the same network you can leave that as layer 2 connections only. Linux OS management and Console Proxy will always need to find the way out of their network.
I hate to say it bluntly, but this has nothing to do with vCloud Director, this is system admin 101 stuff for having multiple interfaces and networks on a single system and understanding who needs to talk to what. Let’s not forget the basics here.
Firewalls
I am not going to go over all the ports you need, you can get that from the documentation and Hany’s diagrams. However if you are using a complex setup like above, there could very well be firewalls involved as well. EIther hardware ones or software ones preventing the connection. If you have validated all the above, then start looking into firewall settings. Is IPTABLES or SELinux enabled on the Cell? If I am not mistaken, one or both should remain off for the cell to function.
Load Balancer and External Address
I have covered this pretty clearly in past articles on configured a load balancer for vCloud Director, so if you have not checked that out there is an important thing to take away. You simply cannot do SSL offload on the VMRC connection. Read more about the setup here, but if you are trying to offload SSL for the console connection, it simply will not work.