The SSL VPN service for remote client connections is a pretty cool feature of the NSX Edge Gateway. The service can be setup to granularly allow specific internet networks to be presented back to the connecting client, can be configured to authenticate against AD/LDAP, and is all around a much easier approach than configuring SSH tunneling in order to access home lab resources remotely.
To start, let’s log into the Web client and navigate to “Networking & Security”.
Select the NSX Edge Service Gateway that will be performing the SSL VPN function.
DASHBOARD
Once into the configuration area of the selected NSX Edge, you are dropped into “Dashboard” where you can enable/disable the service, as well as see some nice high level information regarding number of connections, failed authentications, and bandwidth consumption. Sadly, other than changing the timeline on these charts, it isn’t possible to customize this dashboard in any way. I guess this is why they sell Operations Manager… $$$ J
From this initial page we are also presented with all sub-configuration selections summarized in the left pane.
SERVER SETTINGS
Navigate to “Server Settings” so that we can begin the configuration. From here we can set the interface that the SSL VPN service will bind to, as well as select the encryption scheme and associated SSL Certificate that we wish to use. Enter the config by hitting “Change” in the upper right.
The first dropdown is to select the IPV4 address that the service will bind to. It will by default show you all IP’d interfaces on the Edge device that are of type “Uplink”. (You cannot light up the service on an “Internal” interface.)
The NSX Edge in this lab is positioned in a “three legged” configuration. It is functioning as my lab’s upstream Gateway router and firewall, with a single uplink facing my Verizon POS (FIOS) router, which is the untrusted zone/internet. It has a second internal interface facing a Services VLAN, which has DNS, AD, NFS, etc. Its third and final interface is facing a transit network that connects back to a Logical Distributed Router, with routing via OSPF between the LDF and Edge.
Accordingly, I select the IP and uplink interface facing my Verizon POS router. The Verizon POS router is configured to treat my Edge as a DMZ host, allowing all incoming traffic to be forwarded to the Edge, therefore I shouldn’t have to mess with any NAT rules on the Verizon POS.
I’m not using IPv6 so this is blank.
For Port, I am changing from the default of 443 as I already have a web SSL service behind the Edge Load Balancer utilizing that port in this lab, so I am setting to something random and out of the way of normal port scans.
For Cipher, select AES256-SHA. With today’s CPU processing power, I can’t see a reason for choosing a lesser strength cipher.
For Server Certificate you can select any certificate already present in the certificate store. For the lab we aren’t using a trusted cert, so the default self-signed is what we will choose. Obviously for a professional use of this product a validated cert is required to protect against MITM.
Once this is set to your liking, go ahead and enable logging for future troubleshooting needs.
IP POOL
Next up is setting our “IP Pool”. This is the pool of IP addresses that will be handed out to incoming clients authenticating to the SSL VPN service. This pool obviously can’t overlap with anything already being referenced by a route presently on the NSX Edge. I pick something out of the ranges that I typically use for internal systems, so that the range sticks out in any logging that I want to look at.
The Gateway IP selected here will be created on the virtual pseudo interface created by the Edge device facing the clients. You also set DNS settings for the client here, which I am changing to a couple BIND servers running in my lab. DNS suffix and WINS settings can also be specified here.
PRIVATE NETWORKS
Next task is defining the protected networks that we want presented to our VPN clients. Routes to these networks will be pushed out to connecting clients, with the gateway to reach them being set to whatever we defined in the IP pool above.
Select “Private Networks” to make the selections. I am setting access to three of my home lab’s IP ranges – 10.0.0.0/16, 192.168.122.0/24, and 172.16.0.0/16. You can get as granular or as wide as you want here, even specifying a single host via x.x.x.x/32.
Select the green plus to add a new network definition. You have to enter this wizard for each range – you can’t enter multiple ranges in a single wizard window.
I want my traffic to be included over the tunnel, and am selecting TCP optimization.
AUTHENTICATION
For “Authentication”, the product allows you to leverage external user authentication services such as LDAP, Active Directory, RADIUS, and RSA-ACE, or you can simply create local accounts native to the Edge device if desired. Certificate based authentication is also available. I am going to leverage the AD in my lab for this demo, so I hit the green plus and select and fill out the Active Directory specific configuration.
Once the wizard opens, first up is to select the desired service and set IP and port information. As elsewhere in this product, you have to enter a hard coded IP for the AD server – it won’t take a FQDN. I am leveraging SSL on port 636, so this is set as such.
The other fields are standard to an AD/LDAP configuration. For Search Base, I am simply entering the top level OU that contains all my users (CN=Users,DC=cardiffgiant,DC=org), but you can set this lower in your LDAP tree if desired.
I set the BIND Distinguished Name to a non-privileged service account set up specifically for the Edge service to authenticate users with (CN=svcAuth,CN=Users,DC=cardiffgiant,DC=org).
Login Attribute Name I am leaving as default. SAMAccountName will simply reference my Windows Logon name, which is what is generally desired.
The Search Filter field allows you to specify LDAP attributes that must be met to grant a successful login. The default is a catch all, meaning if the login attempt references an account within the Search Base, and the credentials are correct, no further requirements are needed.
For my lab, I don’t want every Tom, Dick and Harry who happens to have an account in my AD to be able to use the SSL VPN, so I am going to set a requirement to be a member of AD group “VPN” for access. I set this field to be “memberOf=CN=VPN,OU=Groups,DC=cardiffgiant,DC=org” to achieve this.
Finally, there is the selection to set the configured authentication service as a backup if desired. I could see a use case of setting up a local user specific to the Edge under a LOCAL authentication service, and perhaps setting this as secondary in case the AD server(s) are down, but I am not playing with this here.
INSTALLATION PACKAGE
“Installation Package” is where we create the software installation package that authenticated clients will download and install to access the service. The Edge natively can roll up packages for Windows, Mac, and Linux, which is cool since I tend to work remotely on a laptop running the latest Fedora distro.
Once the wizard for a new installation package is opened, you first enter a name for the package profile, followed by a gateway IP. The entry here will be hard coded into the installer – once the package is installed, users cannot manually enter multiple Edge device IP’s to connect with. This isn’t like Cisco AnyConnect – the package created here will be native to this specific SSL VPN service.
Enter the IP that clients will be routing to. If your Edge is behind an upstream NAT device, like me, then here you would put the public IP which is NAT’d back to your Edge. In my case this is the public IP Verizon FIOS has handed to my Verizon POS router. (Remember my setup has my Edge promoted in Verizon POS as a DMZ host, so all incoming traffic is forwarded to the Edge without having to set up NAT rules in the Verizon POS.)
Same deal for port entry – what is entered here is what clients will attempt to connect to from the internet. If you are behind a NAT config, set accordingly, but since I am effectively facing the internet, I am simply setting to match what I put in my Server Settings above.
The remaining settings relate to how the client software behaves once installed on the user’s machine. This is pretty cool as it allows the ability to mask much of what is happening with the install and run state of the client to end users if desired. Most parameters are self-explanatory, but Check the NSX 6.2 documentation for explicit descriptions. My selected config is below.
USERS
“Users” is where you enter local users to be leveraged by an authentication service defined as type LOCAL. You get some standard security functions with the product such as setting password expiration policy, ability to change password, and forcing a change on next login. I am using my AD, but have shown the window below for good measure.
WEB RESOURCE
“Web Resource” allows you to publish internal http(s) URL’s to connecting clients. This is useful if you simply want clients to access a protected website behind the Edge maybe for security reasons you don’t want facing the open internet. This may be because of lack of HTTPS, or simply you want to lessen your attack vector to the service.
I am adding a few internal http services so that we can get our Web Portal populated with some resources to access. Below I add the URL to access the NSX Manager itself. We will see this presented on the Web Portal once we turn up the service and authenticate.
CLIENT CONFIGURATION
This is where you can set tunnel mode, as well as some additional client settings relating to upgrade notification and auto reconnect. You have the option to select FULL Tunnel mode, which forces all traffic initiated from the client back to the Edge. I just want traffic destined for my subnets routed back to my lab – the rest of the client traffic can route out its existing gateway. For security reasons, some organizations want all traffic egressing through their systems while a client is connected, but I don’t require this. My settings are below.
LOGIN / LOGOFF SCRIPTS
Scripts can be set for login and logoff, and the order that they can be run can be set as needed. This is a pretty powerful feature that sets the sky as the limit as far as any customizations you need done to a user’s environment once they are connected. Admittedly, I haven’t played around with this very much yet (specifically I want to see if bash and python scripts work via my Linux client), but I will update the post once I burn this functionality in a bit.
GENERAL SETTINGS
General settings offer some additional security based tweaking to the SSL VPN service. For my lab I am not concerned with more than one device connecting leveraging the same credentials, nor timeout settings.
PORTAL CUSTOMIZATION
Portal Customization is an area of the product that could use some improvements, but is cool none the less. Here you can lightly modify the portal to show different colors, labels, and even upload your own personal JPG for some personalized branding.
Although the customizations are pretty elementary, it is a quick way to make the service appear more customized for a specific customer or service.
You can customize both the login web portal itself, as well as how various elements of the thick client appear to users.
The logo and banner changes seem to be very picky about pixel sizing, so you may have to play around with sizing your icons to get this to encode and render properly.
That’s it for configuration!! Navigate back to the Dashboard, and select “Enable” to start the service.
INSTALLATION
Now… for the fruits of our labor. From a client system external to your Edge, navigate to the IP and Port defined in the Installation Package section. If like me you are using the self-signed cert, accept the security exception per your browser.
Log in via appropriate credentials per your config. In my case, I am logging in with an AD account that is a member of AD group “VPN” per the filter I set up in the “Authentication” section.
Once authenticated, you are dropped to the Home page which shows the Web Resources that we configured. Looks good! These can be selected to access the protected HTTP services which are proxied through the SSL VPN Edge Service.
This is cool, but let’s get to the interesting part! What we really want is to leverage the full client so we can get IP based access to all of the internal resources we defined in “Private Networks”.
Select “Full Access” to be presented with the list of installation packages that have been configured for the service. We have configured one package – so we will download and install the full client now.
Click to start the installation.
Once downloaded run the installer. I am installing this package on my Windows 10 tablet.
Once installed, you will see the Edge SSL-VPN icon in your system tray.
Double click and login. Accept the self-signed certificate.
Connection will be established. Yay!
Let’s check out what network settings got pushed to our system. A quick look at IP and route settings show that we have been allocated an IP via our “IP Pools” configuration, have the correct DNS settings pushed, and we have routes referencing the “Protected Networks” that we defined.
Looks legit. Let’s test out some pings to these resources.
Awesome… we are successfully VPN’d into the lab!!
(All of the systems in my lab have routing configured via OSPF to ultimately bubble up to this Edge as the default gateway, so all of these systems know how to get back to the SSL VPN IP Pool that I defined.)
CONCLUSION
In my opinion this is one of the cooler services of the NSX Edge. In the past I have leveraged either Open SSL or SSH Tunneling to achieve internal access to my systems – the Edge gateway offers better functionality for this need, and is a snap to set up.