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: 18.104.22.168. 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!