Test driving vCloud Air On-Demand–Part 2

In part 1 of my vCloud Air test drive we went through the vCloud Air UI as well as went over the steps it took to get a VM up and running in the cloud.  This is all great except for the fact that our VM had no connection to the internet – nor did we have any way of accessing our VM outside of the default console that vCloud Air provides.  This section will deal with just that – we will explore the NAT and firewall rules that need to be setup in order to get our VM access to the internet as well as port forward our public IP in order to provide ssh access into resources within vCloud Air.

Just a note – If you wanted to try out vCloud Air On-Demand on your own you can do so by following this url – and using the promo code Influencer2015.  This will get you $500 in service credits to burn in 90 days – more than enough credit to give it a valid test.  This code and url expires June 30, 2015 so be sure to register ASAP – also, it’s valid only for new MyVMware accounts meaning you will most likely need to register under a different email than you currently use.

Just as I did in the first post in this series, part 2 will have a video an an accompanying blog post.  The video, embedded below along with the blog post both accomplish the same result – so hopefully I’m covering off everyone’s content type of choice!

https://www.youtube.com/watch?v=2Kr0OPvudTs

Connecting our cloud to the internet

As we seen in part 1 our VM was not connected to the internet by default.  Thankfully accomplishing this task is not that hard, even automated to a certain extent inside of vCloud Air (notice a recurring pattern here?), basically creating the NAT and firewall rules that we need in order to allow communication out.

Speaking of NAT let’s get a little of the vCloud Air terminology straight before we continue.   First up is our firewall – the vCloud Air firewall essentially is closed by default, meaning all traffic both in and out from the public IP is blocked by default.  In order to change this, we create what’s called Firewall Exceptions.  How vCloud Air interprets NAT is always based on the internal vCloud Air network, as follows

• SNAT (Source NAT). – Deals with traffic originating from within the vCloud Air Network (source) destined for another network (ie Internet)
• DNAT (Destination NAT) – Deals with traffic originating from another network (ie Internet) destined for the vCloud Air network (destination).

Now before we can get into any natting or firewalling we need to create a public ip address to nat out of.  This is done by browsing to your gateway configuration and then the ‘Public IPs’ tab.  The actual adding of the IP is done by clicking ‘Add IP Address’ – tricky huh?

Once we have our public IP setup we can do one of two things – we can create the SNAT and Firewall exceptions manually or we can right-click our VM and selected ‘Connect to Internet’  The latter option will automatically create the SNAT and Firewall exceptions that we need in order to allow outbound access from our newly created VM.

Just a note here as well – I found it best to simply let the UI report back that everything has completed successfully – not just here but when doing things such as deleting VMs and creating data centers.  Sometimes navigating away from a page while a task was in process caused either the task to take and extremely long time or forced me to log back into the UI.  Anyways, after the task completes you should see the following rules that were created.

Now if you are wondering how to manually create a firewall rule don’t worry because we are going  to do this as well.  Although the rules have been created to allow http/https/dns out of our network there is nothing created around ICMP or ping.  This is a commonly used method of testing connection to systems, so I’m not sure why this isn’t included in the ‘Connect to Internet’ workflow.  Either way it gives us the opportunity to go through the process.  Simply clicking the Add button will allow us to configure the following rule, which allows ping out not only from our VM (109.2) but our whole 109.0 network out to our external IP (shown below).

At this point we are almost there in terms of access to the internet.  vCloud Air has statically assigned us and IP from our default IP pool, however it hasn’t done any configuration in regards to dns – so if you were to go try and ping google.ca at this point your VM would have no way of resolving it.  If you need to add some name servers to your Ubuntu VMs interface you can do so by running the following commands.

echo “dns-nameservers 8.8.8.8 8.8.4.4” >> /etc/network/interfaces

ifdown eth0 && ifup eth0

At this point, we should be successful in pinging google.ca or any other network address located on the internet – we have properly connected our cloud to the internet.

Connecting the Internet to our cloud.

Remember back in part 1 when I was griping a bit about not being able to send CTRL+ commands to my VM through the default console?  Well, one way around this might be to configure and allow ssh through our firewall, which would allow me to use putty or any other ssh client and issue CTRL+ to my hearts delight.  Keep in mind these scenarios would also work for Windows VMs and RDP by simply using port 3389 or whichever port you desire.

So, since our ssh traffic is going to be originating from the internet and destined to our vCloud network we first need to create a DNAT rule in order to port forward port 22 from our external IP to our internal Ubuntu server (Note:  The default Ubuntu image already is listening on port 22 for ssh).  The setup of the DNAT rule is shown below, remember to wait after clicking ‘Finish’ till vCloud Air reports success back.

Even though we have our DNAT setup now we still need to allow access on port 22 on our external IP through our firewall – remember everything is blocked by default so the following firewall exception will need to be created.  I’m left the source IP and port as Any/Any, essentially allowing access from anywhere – if you had a specific IP that you would always be connecting from you could technically be a bit more secure and use that.  For my testing though, I don’t care so much…

And there you have it!  After waiting for the rules to apply (just wait) you should know be able to open up putty or your favorite ssh client, enter in your external (public) IP and log in to your VM.  Any other services and ports you want to open up?  Just simply repeat the following steps using whichever port you desire.

Although writing all this down after the fact seems pretty self explanatory and easy, to be honest, I struggled a bit during the networking portion.  Not to say it isn’t intuitive, but with everything else being a breeze within the vCloud Air UI I would’ve thought there would be some pre-built workflows around opening up services given the number of steps it takes.  Even if it was just common items such as ssh, rdp, or www.  That said, it is possible that maybe if I RTFM it might have been a bit easier – but I like to jump right in – helps me evaluate the usability.

All in all VMware has a great service in vCloud Air On-Demand.  It’s a piece that was originally missing from their cloud offerings.  Having a pay-as-you-go service where you don’t need to fork out long term commitments or budget is key, especially when you think in terms of timely workloads, dev/test, etc.  In the end vCloud Air has impressed me – a clean UI, easy to use solution without breaking the bank!

Again, if you want to test out vCloud Air On Demand for yourself go ahead and get a new MyVMware account and sign up at this URL using the promo code Influencer2015.  I know I’ve mentioned this a lot over the past two blog posts but it will get you $500 in service credits and that’s more than enough to get a solid judgment on the service.  Honestly, who doesn’t want free things!  Thanks for reading/watching.