(or how I learned to get communication between two vApps on the SAME Routed Organization Network and get them to speak to the External Network…)
In my previous post(s) I looked at two vApp Networks residing on the SAME isolated Organization Network. I figured it would be interesting to have a look at the same sort of configuration – but in situation where the two vApp reside on the SAME routed Organization Network namely my CORPHQ-CorpHQNetwork. Remember with a routed Organization network it is configure via vCNS Edge Gateway up to one of the External Networks in your vCloud instance. In this case I had two vApp Networks called Web and Database. Web resided on the 192.168.15.x network and the external interface for the Edge Gateway was 172.168.5.12, and the Database resided on the 192.168.14.x network with the Edge Gateway for it on 172.168.5.13.
I wanted to experiment with configuring not the vApp Networks static routing settings – but the Static Routing options that exist for the Edge Gateway on the routed Organization Network. As ever a little whiteboard video can help illustrate the configuration I’m handling…
First I needed to login as the Organization Admin, and located the Edge Gateway for the CORPHQ-Network. That’s located under the “Administration” tab, > Cloud Resources, >Virtual Datacenters, and Org VDC Networks – in my case I was dealing with the “CorpHQ – Production Virtual Datacenter“
Next I right-click the Coro-HQ-CorpOrgNetwork and selected Configure Services – just like I would if it were a vApp Network, and select the Static Routing tab. Next I needed to tell the Organization vCNS Edge Gateway of the new networks hanging beneath it and that:
192.168.14.0/24 was accessible via 172.168.5.13
192.168.15.0/24 was accessible via 172.168.5.11
Note: As this is a lab environment I turned off the Firewall on the Organizational Network (under the firewall tab) and also ensured the firewall on the vApp Network and within the Guest Operating System was turned off as well. This allowed me to do ping tests & tracert tests with impunity.
The screen grabs shows the standard fair – a successful ping test, what’s interesting in the tracert taken from 192.168.14.100. It show it crossing the vCNS Edge Gateway of the Database vApp Network (192.168.14.1), up to the vCSN Edge Gateway of the Organization Network (172.168.5.1), then down the vCNS Edge Gateway of the Web vCNS Edge Gateway (172.168.5.12) until it reaches the VM in the vApp (CORPHQWEB01 on 192.168.15.100)
Note: I’m not 100% satisfied with this setup just yet. I found although I could ping – when I went to browse \\192.168.15.100 it would not connect – also after enabling RDP access to 192.168.15.100 that wouldn’t work either. That’s despite having no firewalls enabled on any of the vCNS Edge Gateways. I’m not really sure why this happening, and I will be coming back to the setup again when I have more time…
and how I enabled communication out from the Organization Network to the External Corporate Network:
Now that I had comms working WITHIN an Organization BETWEEN two vApps – I wanted to make sure that the two vApps could speak through the Organization Network and on to the External Network – specifically because that’s where corp.com’s domain controllers reside (dc01nyc – 192.168.3.130 and dc02nyc – 192.168.3.131). This would mean my Windows based vApps could be joined to the domain if needs be using the OU structure specifically setup for CORPHQ.
Again perhaps a little whiteboard video might help set the scene a little.
To achieve communicate from the vApps to the Domain Controllers (and vice-versa) I needed to enable a couple of options. Firstly in vCloud Director I needed to modify the vCNS Edge Gateway that services the Organization Network that allows access to the Corp Network. That meant adding source NAT rule to explain how packets coming from the 172.168.5.x network arrived at the 192.168.3.x network. The Edge Gateway has two IP on internal interface (172.168.5.1) and an External Interface (192.168.3.10). If your unsure of these addresses they can be located in the vCD UI. The External IP assigned from a pool of IP addresses from the Organization Network – and can be found on the “Org VDC Networks” of the relevant Organization Virtual Datacenter:
The Internal IP of the Edge Gateway for an Organization can be located on the “Edge Gateways” tab – by examining the properties of the Edge Gateway on the “Configure IP Settings” tab – in my case this was statically assigned when I created the Edge Gateway alongside the Organization.
It’s this second IP address that is important to us when creating source (outbound) NAT rules that will allow VMs from either vApp to speak to the Corporate Network. Armed with this information we cancel this dialog box, right-click the Edge Gateway and choose the “Configure Services” option. The NAT tab allows us to add the appropriate rules…
So here the rule is saying to get to the “The Corporate Network” for any packet coming from 172.168.5.0 use the 192.168.3.10 IP address. A simple ping, tracert and nslookup test is all I need to confirm the communications path is valid.
The ping test was done from a VM with a 192.168.15.100 address – it went via its Edge Gateway on the vApp Network (192.168.15.1 > 172.168.5.12) on to the Edge Gateway for the Organization (172.168.5.1 > 192.168.3.10) and then on to the domain controller on the External Network (192.168.3.130). This NAT translation is only one direction, so my VM can ping to my domain controller, but not in the opposite direction. In fact my domain controller when it speaks to its default gateway the router on this network has no idea of how to reach 192.168.15.0 or 192.168.14.0 network. That was easily fixed by adding a route to this network which allows for communications to the vApp Network – either by updating the router (in my case software router I have 192.168.3.1) on the External Network or by manually adding a route on the client.
route add -p 192.168.15.0 mask 255.255.255.0 192.168.3.10
route add -p 192.168.14.0 mask 255.255.255.0 192.168.3.10
So here the domain controller (192.168.3.130) sent a ping to a VM in a vApp (192.168.15.100) and it went via its default gateway (192.168.3.1) on to the Edge Gateway device for the CorpHQ Organization (192.168.3.10 > 172.168.5.1) then on to the vApp Network Edge Gateway device (172.168.5.12) and then on to the VM within the vApp (192.168.15.100)