In my previous blogpost I was looking at DNAT rules with a vApp/VM on the “Organization Network”. For peace of mind I wanted to look at the similar scenario if the vApp was behind a vApp Network. As you might recall DNAT rules allow you to “publish” VM’s within a vApp and make them available to outside the organization. That could be to other organizations – or it could be to the Internet. In my case its to the Internet. Publishing a web-server for example behind a vApp Network is easy to do as another configuration. That’s because all VMs within a vApp network get an “internal” address that’s valid for the vApp Network as well as an “external” address that’s valid for the Organization…
So in the screen grab above the web-server called “corphqweb01” internal address is 192.168.15.101 for the vAppNetwork – Web, and it’s external IP address is 172.168.5.18. That means all I need to do is create DNAT rule at the organization that redirects one of my “external IPs” to the 172.168.5.18 address.
In my case that 192.168.3.11 address has been mapped from my physical Juniper Firewall. In fact I asked my colo to make the rule ANY:ANY so that makes the Edge Gateway my affective firewall. I dare say in the “real world” I would open port80 for one my “Internet IPs” (81.83.84.86) to the 192.168.3.11 address. That would give me three layers of firewall – the Juniper FW, The Organization Firewall, and the vApp Firewall. Such fun as Miranda might say, I’m sure Edward Haletky would approve! 
As it is all I needed to do was review the Firewall settings on my vApp Network to make sure that port80 would be passed through it:
Success!!!
Anyway, the more I look at these “external networks” (mine is ridiculious based on the 192.168.3.x range as if I was on homelab with a WiFi router!) the more I’m thinking how different they might be say from a private cloud and public cloud. For a private cloud it seems “fair” to me to say that Organizations can use their external network to get to other entities within the Corp Holdings, Inc and the Internet. In this scenario it seems reasonable that the number of these external networks would be pretty small, and shared amongst the trusted members (the different organizations). However, when it comes to public cloud. I could easily imagine EACH Organization/Tenant wanting demanding their own EXCLUSIVE external network – and the IP associated with each of those external networks would be the standard 8-16 IP’s assigned from an Internet range of address (81.82.83.10-81.82.83.18). Yes, perhaps this “external” network would be shared by multiple Organizations in vCD (Org1-Test/Dev, Org1-Staging, Org1-Production) but configured in such away that Org2/3/4 could not access them….