In this second part of the NSX 6.0 solution architectures series, we are building up on the pervious blog post. If you haven’t already done so, please take a few minutes to read that post at this link.
In this solution, we are changing the way the end-users are accessing the cloud services. In the last part it was a direct web access that was NAT’ed through the External Edge. Here, we are adopting a different approach by enabling the SSL VPN-Plus service on the very same external Edge to allow the end-users to connect directly to the external perimeter network. Let’s examine that in details.
As you can see from the diagram above, we have now one public IP address assigned to the “Uplink” interface of the external Edge. This IP address will be used as the VPN gateway that will allow our end user to passthrough to our External Perimeter network. Once this is configured, the End-user can point his/her browser to the URL: https://vpn.hypervizor.com and from there login with his/her username and password that would be assigned by the service provider. The web interface/portal that the end-user login from is actually part of the SSL VPN-Plus service of the Edge. It is highly customizable as well to reflect your corp identity.
From that portal, the end-use can either launch a publish web application (like a traffic monitory solution), or download the full VPN client to get connected to the external perimeter network as I’ve mentioned earlier. This VPN client has different versions for Windows, Linux or even Mac. Once the client is installed on the end-user machine, he/she can then authenticate (with the same user/pass) and get the applicable IP address (172.16.20.100 in our case here). At this point, the end-user can access either the vCD portal or other applications/services that are running on the external perimeter network like vCenter Operations for monitoring the VMs or perhaps vCenter Chargeback for monitoring the usage and charges and so forth.
Note here that we can still load-balance the vCD portal (https service) and the VMRC like what we did in the last post. The difference here is that we are only load-balancing (but not NAT’ing) the 172.16.10.xx IPs directly. For example, we pick a new IP address, say, 172.16.10.4 and we designate it as the virtual IP of the https service so we configure it to LB to the vCD cell IPs 172.16.10.11 & 13. Same thing holds true for the VMRC service.
Configuring the Parameters
Now let’s take a closer look into some important configuration parameters related to the SSL VPN-Plus service:
In the IP Pool as you see from the screenshot above, you (as the service provider) can set here the IP address pool(s) you want your end-customers to consume their IP configuration from (e.g 172.16.20.100-200). Note here that the IP address you give as a default gateway will be assigned automatically to the Edge. You may also want to setup a dedicated DNS on the external perimeter network for name resolution. The hostnames here would be, for example, anything.ext.hypervizor.com. And the IP addresses being resolved are basically the ones on the 172.16.10.x subnet.
The Private Networks here are the networks that you want your end-user to connect to. In our case here it is the external perimeter network (172.16.10.00/24). Of course, the External Edge will automatically take care of the routing between the 172.16.20.0/24 and 172.16.10.0/24 networks.
The last part I want to show you here is the Installation Package. Here, you can add the external hostname and IP address of the Edge Gateway (or VPN Service if you will). In our case, the hostname is vpn.hypervizor.com and it is resolving to the public IP: 126.96.36.199. You can see also that this package will be available in Windows, Linux or Mac executables.
A look from an End-User perspective
When our end-user connects to the vpn.hypervizor.com from the web, he would get this screen (which again, is customizable).
Once logged in for the first time, the user can download the VPN package (titled Hyper-VPN in our case here).
After the installation is done, the end-user can fire-up the VPN program and connect the network.
As you have seen in these two blog posts, the NSX 6.0 for vSphere product can play a major role in improving, securing and simplifying the way you used to architect and configure your L2-L7 services. We’ve just scratched the surface here to show some of the cool things that can be done with NSX. Imagine the amount of innovation and creativity you (as an architect or an administrator) can have now. What really stands out for me here is how fast you can get all this from sketching the ideas on a piece of paper to real services up and running in a matter of minutes or hours at the most!
Preparing the layout components
The Internal Edge
The External Edge
Configuring the relevant Firewall rules
In my next post, I will show you a different approach to this by enabling the SSL VPN-Plus feature on the external Edge and how that will change the external access to the vCD cells.
P.S. If you are a VMware employee, I have this lab running on the VMware OneCloud if you want to examine the configurations, functionalities or architecture. Reach out to me over email to give you access.
Now that VMware NSX 6.0 for vSphere is GA, I can finally start blogging about this incredibly powerful platform! I have been working with NSX 6.0 in my lab for quite sometime and I must say, I am quite impressed with the great new functionalities and improvements over the traditional vCloud Network & Security (vCNS). My personal favorite feature is the unicast VXLAN mechanism that eliminated the requirement for the IP multicasting in your physical network. You can literally get NSX 6.0 up and running in 30min or less! You think I am exaggerating? You should have a look then on my four-part videos here : http://www.hypervizor.com/nsx/
In this post, however, I am presenting the overall NSX 6.0 system architecture. I have used some of the great VMworld2013 presentations as the foundation of this architecture (hats off to our awesome NSBU tech marketing team), but I added my own architecture components to make it thorough as much as an A4 page size could fit.
That being said, this is by no mean a complete architecture of NSX 6.0, but rather a general or high-level design of the main components and how they all interact with each other. As you would expect, I will be publishing in the near future a highly detailed architectures that are focused on technologies like: VXLAN, Distributed Firewall, VPN, Load Balancing, Dynamic Routing (just to name a few). I will be exploring also other solution architectures for NSX 6.0 with VMware products like vCloud Director, vCloud Automation Center and so forth.
Until then, I encourage you to start getting your hands down and dirty with the product through the HOL available online at this link: http://labs.hol.vmware.com/HOL/#lab/558
Before that, and if you feel you are missing the installation and configuration bit of the product, I recommend to watch first my videos on YouTube to get you up-to-speed on this part and to give you also a better understanding on how things should be built and in which order.
- VMware NSX 6.0 for vSphere: 01 Deploying the NSX vAppliance.
- VMware NSX 6.0 for vSphere: 02 Deploying the NSX Controllers.
- VMware NSX 6.0 for vSphere: 03 Preparing Hosts and Configuring Unicast VXLAN.
- VMware NSX 6.0 for vSphere: 04 Configuring a Logical Switch