In a previous blogpost I skirted around the issue of the firewall with the vCNS Edge Gateway, as used by vCloud Director. It got snuck in during a blogpost about monitoring – because monitoring includes syslogging, and syslogging is used by the firewall rules is was introduced in a rather Trogen Horse kind of way. In case you have realized all those post about static routing we done with the firewall switched OFF, as that aided troubleshooting – that of course, is neither best practice or realistic. Even if you do allow traffic from NetworkA to NetworkB within or without of an Organization its unlikely to be unfiltered. So I decided to play around with my configuration of the firewall on my “web” vApp Network and see if I could tighten the screws a little more.
The configuration of the firewall component can get quite involved – the more vCNS Edge Gateway’s you deploy – each one will have it own firewall – which is turned on by default. It’s tempting to keep the number of vApps and vApp Networks to minimum, since each vApp Network created generates a new vCNS Edge Gateway, and potential firewall management. I guess much depends on what your trying to achieve (as ever!) if you essentially want to protect those VMs and give them outbound access to the Internet that’s a relatively trivial affair.
To keep things simple in my lab environment I create quite a permissive rule that allows ANY network to ping the VMs in my “Web” vApp Network. To do that I use the key words “external” and “internal”. It means in my lab I can still use ping/tracert and so on to do tests. It lets me verify that the network path is good, and validate that its the firewall blocking the traffic and not some other source – such a bad route or NAT entry. I think there maybe practical use of this rule to allow for diagnostics. So the rule could be disabled during ordinary hours, and enabled for diagnostic purposes. This allows any inbound traffic coming in “external” to the vApp Network pass traffic across the vApp Networks Edge Gateway into the “internal” network using ICMP…
Additionally, I keep the default vApp Network firewall rule that allows the VMs speak outside of the vApp Network, onto the Organization Network to which they have been connected. This allows all “internal” traffic out across the “external” network (on to the Organization Network in my case) using any TCP/UDP port they need. That’s quite handy for external services like querying the DNS service that either resides on the Organization Network or the External Network.
My next task was to grant wide access to the web-services residing on the VMs on the vApp. For testing purposes I installed Microsoft IIS to Windows 2008 R2, and replaced the default.htm file will basic file that said hello world – and name of the web-server in question. If you’ve followed my vApp Network series of post, you will know I setup static routing between vApp in OrgA to vApp in OrgB – in my case between the Web-Servers in the CorpHQ Organization to the QuarkReporting vApp in the COIG Organization – this allows traffic to flow from/to 192.168.30.x network (the QuarkReporting App) to the Web-Servers vApp (192.168.15.0). As a quick test I did pathping from one of the QuarkReporting VMs to one of the CorpHQ Web-servers just to validate the connection was good. I wish in my other posts I’d used pathping rather just ping/tracert as it seems to show more about the true direction of the packets.
So here you can see the coigqurkrepts01 VM speaking via its default gateway (192.168.30.1) on to the COIG Organization vCNS Edge Gateway (172.168.8.1) which then speaks across the External Network (192.168.3.x) to external interface of the CorpHQ Organization vCNS Edge Gateway, and then on to the vApp Network vCNS Edge Gateway (172.168.5.12) where web-servers residing on the 192.168.15.x network – in this case the packets arrive at the corphqweb01 web-server on 192.168.15.100.
So I wanted a more specific firewall rule than just internal/external allow – so I created a firewall rule on the vApp Network of the web-servers just to the VMs within the QuarkReporting vApp.
This rule blocks any access from VMs within the CorpHQ Organization – so I added a second file wall rule to allow the vApps on the Corp HQ Organization Network.
Here’s a summary of my rules:
Once I had this configuration in place I just cranked up a web-browser on the 192.168.30.x network to see if I could reach http://corphqweb01