Part 2 of this series on how to set up vSphere Stretch Deploy with vCloud Air will deal specifically with the requirements and workings of the vShield Edge Gateway component in the local vSphere infrastructure. The reason I think this aspect is important is that from my experience most vSphere only customers may have never introduced this into their environment. However, it is a requirement for the Stretch Deploy SSL VPN to get created between the public cloud and your local datacenter. Frankly speaking this was the first time I ever deployed one and I started with a few questions of my own.
vSphere Stretch Deploy – Understanding the Edge Gateway Design
If you are like most vSphere users you have some port groups on your vSphere infrastructure where your virtual machine happily live. like I do. You are using VLAN’s and tagging the traffic and everything is working just fine. Now you have decided to Stretch Deploy one of those virtual machines that has an existing IP Address and Default Gateway, living on a production port group. You are reading these posts and hearing that you need an Edge Gateway and wondering a few things like I did. Tell me if any of this sounds like questions you might already be asking:
- How am I going to introduce a firewall to my existing environment?
- I don’t want my existing port group firewalled!
- Firewalls usually use NAT and security rules will I need those?
- Will I need to change the Default Gateway of the virtual machine?
- How is the traffic going to flow once it’s moved?
The good news is so far I have seen some pretty interesting answers to these which I will attempt to answer.
How am I going to introduce a firewall to my environment?
When I started to think about this I was in the vCloud Director mode of thinking. That when you deploy a vShield Edge Gateway it has two interfaces where one is external and one is internal. The internal is using NAT and the virtual machines are all on the NAT subnet. However, in the use case here the virtual machine is existing, but Stretch Deploy will not configure without the portgroup having an Edge Gateway on it. I started to stretch my head and just take a stab at something.
I deployed the vShield Edge Gateway in the configuration below and Stretch Deploy seemed to be happy enough to let me start the process:
- vnic0 – External Network
- vnic1 – Internal Network
- Firewall Rules = Default
- NAT Configuration = Default
I tried to do this with a single interface on the Edge Gateway and it did not seem to be 100% happy. What you need to realize is that you may NEVER put a virtual machine behind the “Internal” interface as a Default Gateway like you would in a vCloud Director deployment. The only reason this Edge Gateway exists is to establish the Bridged Mode SSL VPN to the vApp Edge device. Once that connection is established your Virtual Machine should still continue to use its original Default Gateway and it will be reachable through the SSL VPN. You can of course deploy new virtual machines in your protected port group using the new Edge Gateway as their default gateway and start using the firewall function, but for this use case that is not what we are trying to do. I am trying to avoid any re-configuration on the original virtual machine. Below is the logical diagram of the “before” picture
Note: I have noticed some of the firewall rules get created at he start of the process, but the final SSL VPN does not appear to be done until after the virtual machine is copied completely.
What do I need to do now that I Stretch Deployed my virtual machine?
There is about 50 articles out there on which buttons to click so I am not going to repeat those. However, I do want to touch on some of the things I have been thinking about. Especially the network connectivity flow since we have assumed we are not changing any information about the virtual machine. Below is the “After” picture once the process is completed.
Most notably you will see there is some duplicate IP information on the internal side of the two Edge Gateways. This is fine and if you did have machines behind the NAT in the original location using the Edge Gateway as the default gateway, things will continue to work the same. In this case however we said originally the Default Gateway of the machine we are moving is already set to the corporate gateway. This is important as there may be upstream rules that are using this IP address for something and we want to keep things the same.
In this case the Stretched machine will still be able to reach its original Default gateway through the Bridge Mode SSL VPN and traffic will flow accordingly. Nothing should need to be changed for connectivity to work as if the machine was in the local datacenter. We do not require any Edge Gateway firewall rules or other things to establish connectivity to the machine. I was also able to ping the stretched machine from my laptop on the .100 network.
What about multiple virtual machines on the same network?
This is something I will try to tackle in part 3. I am also thinking about the question, “Can I add a NEW machine in the cloud as part of the vApp network that has been stretched using the original subnet from a vCloud Catalog Item”? What happens if I have other virtual machines on the original subnet I want to move to the new Stretched vApp? These are the next two common things I think will come up when dealing with this use case. I also want to try to discuss the process by which you would do these other additions.
This is proving out to open up some more interesting questions and answers about this technology and feature. I am sure I will get some good conversations at VMworld about it!