Warning:
This configuration I’m doing between vCloud Director and View is largely unsupported. There’s a couple of things that kind of breaks the rules here. Firstly, I had to give my “CorpHQ – EUC Solution” vApp access to a vCenter – which just happens to be where my Organizations are.
That’s hardly the definition of multi-tennacy, where the Org’s have no ideas what the underlying vCenter/vSphere environment is like! I guess I could have setup a dedicated vCenter environment just for running desktops, and done some delegation to keep one tennant seperate from another. I’m just using a service I know well as example, and as something to practise with. The DNAT configuration works equally well for something like a web-server on port 80….
One aspect of vCloud Director and the vCNS Edge Gateway I’ve not really looked at is Destination NAT rules. What are they and what are they for? Well, whereas “Source NAT” rules (SNAT) allow for outbound NATing for VMs/vApps behind an Edge Gateway to get to a wider network (the corporate network or internet) for example. Destination NAT (DNAT) rules allow for “Inbound” NATing. An excellent example of doing that is allowing services provided by the vApp to be accessible from the internet………………………………..
I have specific example. For years now I’ve have a remote lab environment which is reside in some kind of colocation facility. My remote access system of choice was Citrix MetaFrame XP F3. Yes, I have a really old and geriatric Windows 2003 32-bit host that I connect to get a desktop to then manage my system remotely. It’s been around in some shape or form ever since I quite being a Citrix Certified Instructor (VCI) in 2003, and embarked on the path that would lead to becoming a freelance VMware Certified Instructor (VCI). Of course Citrix’s ICA was far superior to Microsoft RDP which you know your remote desktop protocol his – was actually co-developed for Microsoft by Citrix. Anyway, for some years I felt it was time to move over to VMware View. The trigger was in the View 4.6 released which allowed for the first time the View Security Server to pass PCoIP traffic without the need for a VPN. [Those who know me well, will know how much I despise and loath VPNs!!!). So my use case was building a VMware View environment – and then allowing that to be accessible across the Edge Gateway using a combo of DNAT rules to handle the IP translation from the public-to-private, together with some firewall rules. One word of warning. Technically, what I’m doing isn’t really supported as such. Allow VMware View is just another VM to me, it does need access to some kind of vCenter instance for the provisioning of desktops – and also the VMs that VMware View creates don’t appear in vApps in vCloud Director, they appear in vSphere. Of course with a little bit of rule bending you can make it work in an unsupported way… The other thing I would say is given I increasingly don’t live in the “real world” I’m keen to deploy technologies I know well into vCloud Director as way of forcing some kind of realism into what I’m doing – so there is some kind of real application that I’m using…
So I create a Windows 7 VM, and installed the View Agent to it, and then dumped into a manually create resource pool and folder on my Gold Cluster, calling it “CorpHQ – Desktop”
Then I created vApp which will contain my VMware View environment – I slight cheated into two ways – firstly by putting my Security Servers and Connection Servers on the same network as well as patching my virtual desktop manual to the Organization Network. That’s naughty because the whole point of the Security Server is that should reside on separate “DMZ” style network. To be honest I wanted to keep it simple. So I would complete vApp that would eventually contain our entire EUC solution (View, Horizon, ThinApp Factory, and so on) that I could power up and down when I ever wanted to do any EUC work that technically falls outside my new role as its in different business unit. I believe in a world without walls – so intend to keep my hand in with our EUC stuff. On a more holistic level I see our cloud vision as encompassing ALL aspect of IT delivery – infrastructure, apps, and users.
Of course my “corphqparentvm” is configured for the CorpHQ Organization Network (CorpOrgNetwork), and its a DHCP Client, so I had to make sure that when it booted it would get a IP address and join the domain correctly. That meant enabling the DHCP service on my Organization Network for virtual desktops that get cloned either via the standard “template” method or using “linked clones”.
After putting the bits in place – I installed a View Connector Server and View Security Server into the vApp, and configured them together. I appreciate you might know NOTHING about View. But basically when you install these services they get paired together and there’s a configuration on the View Connection Server that allows you to configure what the EXTERNAL IP and FQDN values they are. This makes sure that when an external View session is established the client when it gets info back from the View Server(s) knows to query an external/Internet facing DNS/IP range rather than an internal LAN based one. Without this configuration when the initial hand-shake process begins an a computer in an Internet cafe on 61.62.63.64 would be told to connect to a View Connection Server on 192.168.3.20, rather than the external Internet IP at the datacenter (such as 81.82.83.84). Typically, that configuration would look like this when configured in the View Manager under View Configuration, Servers, Connection Servers, right-click and edit. This really has nothing to do with DNAT rules or vCloud Director, and everything to do View. But it does kind of illustrate that more multi-tiered your application is. The more you might have to be concerned about the configuration of the application layer – and this would be true even if you did something barmy like installing View on a physical box…
Okay, that’s the preamble dealt with. Lets get down to the whole DNAT/Firewall configuration. Firstly, I have a couple of layers of firewall in my environment. At the colo I have Juniper Firewall, and then of course there’s firewall layer at the vCNS Edge level. I nothing about Juniper, and if I make a request for a change I have to pay my colo provider to open ports and so on. That can be quite pricey. So I asked my colo to take two of my spare IP address (for example 81.82.83.84 and 81.82.83.85) and open them for ANY:ANY to 192.168.3.10 and 192.168.3.11. These are actually interfaces on my vCNS Edge Gateway in the CorpHQ Organization. That configuration affectively makes my vCNS Edge Gateway the affect firewall/NAT for that Organization. It means my Organization Admin has the rights to expose stuff to the Internet. In the REAL world I would take time out to learn Juniper so I could have two layers of firewalling.
So the first question is where do these 192.168.3.10/11 address come from? Well, when you configure the vCNS Edge Gateway for the Organization you assign a “sub-allocation pool” of IP address from External Network to the vCNS. Remember with a NAT-Routed Organization Network the Edge Gateway has at least two interfaces – one connected to the External Network, and other “internal” interface for the Organization – so my Edge Gateway for the CorpHQ “Production” Virtual Datacenter is 192.168.3.10 for the external network, and 172.168.5.1 for the internal network. [A little bit of consistency in my IP allocations would have made this neater – 192.168.3.10 and 172.168.5.10 would have been a bit cleaner. But hey, IP is IP and this is just lab!]. You don’t REALLY need to know this “internal” interface IP BUT, you do need to know the external interface IP. Especially, if you doing what I did with my colo, and getting my external IP 81.82.83.84 redirected to 192.168.3.10. The sub-allocation pool is visible/configurable on the “Edge Gateway” tab (Select the Organization Virtual Datacenter, Edge Gateways tab, Right-click the Edge Gateway).
What’s not commonly understood is the IP address that’s used as the 1st connection to the external network (192.168.3.10) is valid for use, along side the other IPs in the range of 192.168.3.10-192.168.3.20. What’s is also needed (and this pretty critically) is the IP address of the system your trying to DNAT to. Now in my first attempt I’m doing something VERY simple. I’ve got one View Security Server (172.168.5.21) connected to another View Connection Server (172.168.5.20). I do plan to eventually setup two View Security Servers and two Connection Servers – and then attempt to enable the Edge Gateway’s load-balancing feature across them – something I did in the eucbook.com using F5’s BIG-IP. All VMs on vApp get an IP valid for the Organizational Network – and even (and this is the important bit) do VMs on vApp Network connected to an External Network…
This means the vCNS Edge Gateway on the Organization Network could do a DNAT (call it reverse or inbound NAT if that works better for you) from 192.168.3.11 to 172.168.15.18, and the vApp Network would handle the translation to 192.168.15.101. In my case my View services are just on the Organization Network, but I do intend to look at the same configuration for vApp Network too…
The first connection that happens with any connection server is on 443. At that point after authentication – after that the View Client is given a list of available desktops. So the first thing I need is a DNAT rule to allow redirection to the Security Server for 443.
1. Navigate to the Edge Gateway for the Organization (Organization, Cloud Resources, Virtual Datacenters, Select your datacenter, Org VDC Networks Tab, Configure Services
2. Next under the NAT tab, click the Add DNAT button
So here, the traffic is coming from the Corporate Network – one of my external networks – that just so happens to be connected to the Juniper Firewall. The rest I think is self-explanatory the traffic is TCP/443 and being redirected to 172.168.5.21 using 443. So the DNAT allows for both IP translation as well as Port Translation. I tested this configuration by just cranking up a web-browser – this brought up the standard web-page for View which allows the user to download the client:
At the very least this configuration would allow for an RDP style connection to a desktop. In View a connection to Security/Connection server happens on 443, and Microsoft RDP packets can be tunneled in the SSL session. PCoIP sessions are also encrypted but the connection is made on 4172 for both TCP/UDP. Knowing this can be quite useful. For example if you can connect to View with 443/RDP but not with PCoIP/4172 it tells you two things – either your configuration is wrong OR the location where the user is at is blocking PCoIP/4172. Most locations I’ve been at allow outbound ANY/ANY, but some cheerless places only allow specific ports outbound such as 80/443…
So here the Mac View client successfully connected using 443/RDP (it actually cranks up the native RDP client for Mac)
Whereas when I try to connect with PCoIP the connection fails because the Edge Gateway hasn’t got a DNAT rule for that protocol yet.
3. So clearer the next step is configure a DNAT rule to allow the PCoIP mapping.
That means I now have two DNAT rules for 172.168.5.21 – one for 443 and another for 4172.
I initially setup these rules with the firewall turned off (and if I’m honest with you – I was using ANY/ANY that would ALLOW absolute any TCP connection of any type to come in to 172.168.5.21). So remember all a DNAT could be very permissive, as it is my connection allows only for specific DNAT rule to happen to a particular node on a particular TCP Port, but I feel the proper configuration should also have a firewall rule as well.
4. So re-enabled the Firewall, and configured it to allow – and added my first rule to enable inbound 443 traffic:
and the second to allow 4172….
So here I’m allowing an traffic coming externally to connect to 172.168.5.21 on 1472/UDP/TCP…
… for what its worth this is really just a temporary configuration to make sure I can get this thing work. What I REALLY want to do next is setup my 2nd set of View Connection/Security Servers – and then enable the vCNS Edge Gateway for load-balancing. That’s going to require a different set of IP configuration – so clients come through on different 172.168.5.x and load-balanced across two of my security servers.