In this article we will take a look on how to configure SSL VPN-Plus functionality in VMware NSX. With SSL VPN-Plus, remote users can connect securely to private networks behind a NSX Edge gateway. Remote users can access servers and applications in the private networks.
- Lab Environment
- Introduction
- Prerequisits
- Configuring SSL VPN-Plus
- Additional Functional Requirements
Lab Environment
The logical design of this lab can be seen HERE.
Introduction
The Kaloferov.com company has made design decision and is planning to extend it’s existing network infrastructure to allow external (public) access to some segments of it’s internal network. To accomplish this the company will be utilizing the already existing VMware NSX virtual network infrastructure platform to create a Virtual Private Network (VPN).
The company has identified the following requirements for their VPN implementation:
- UC1-R1: SSL VPN solution should utilize a certificate issued by the company’s private internal Certificate Authority.
- UC1-R2: External (public) users should be able to access the VPN under the URL: ssl-vpn.vmware.com.
- UC1-R3: External (public) accessing the VPN are located on the 128.1.1.0 subnet. The VPN will be published on the external network with IP 128.1.1.10.
- UC1-R4: Windows Active Directory will be used to authenticate identities (users) accessing the VPN. Only users within a given Organizational Unit (OU name: NSX VPN Users) should be given access connect through the VPN.
- UC1-R5: Users should be able to access only the Kaloferov.com company Management Network (192.168.1.0) and the Load-Balancer-Tier-01 VXLAN (172.16.50.0) logical network .
Later on the Kaloferov.com company will identify the following additional requirements for their VPN implementation:
- UC1-R6: Users should be utilizing User Principal Names (UPN’s) to authenticate to the VPN.
- UC1-R7: Not all users from the SSL VPN Users organizational unit (OU) should have SLL VPN Access. Only users who have Kaloferov.com company employee ID number should have access to the SSL VPN.
I’ve already covered hot to generate and install a CA certificate on an Edge device. To view the process , visit Managing NSX Edge and Manager Certificates
Prerequisits
Edge Interfaces
The Kaloferov.com company has already an NSX Edge deployed which is currently being utilized. The edge is called Perimeter-Gateway and will be used for the SSL VPN-Plus configuration.
To gain a better understanding of the company’s network infrastructure, visit Kaloferov.com Lab Logical Design
Lets see hot to configure the NSX Edge and it’s interface to use with SSL VPN-Plus.
Login to NSX , navigate to the NSX Edges and select the NSX edge that will be used.
Navigate to Settings, and then Interfaces. Select the first available vnic and click Edit.
The following information will need to be filled in:
- Name: Public-Uplink (I’m naming it this way because this network is my uplink access to my public network)
- Type: Uplink (you need a Uplink interface to use with SSL VPN)
- Connected To: vDS_MGMT – Public
(This is my vCenter virtual distributed switch which gives me access to the external (public) network) - Connectivity Status: Connected
- IP Address: 128.1.1.10 / 24 (This is the publicly accessible IP address that corresponds to the URL ssl-vpn.vmware.com)
We have just satisfied the following Kaloferov.com company requirement:
- UC1-R3: External (public) accessing the VPN are located on the 128.1.1.0 subnet. The VPN will be published on the external network with IP 128.1.1.10.
Certificates
Although we can use the NSX default certificate for SSL VPN-Plus, the Kaloferov.com company has a requirement to use a CA signed and generated certificate.
I’ve already covered hot to generate and install a CA certificate on an Edge device. To view the process , visit Managing NSX Edge and Manager Certificates
VPN Clients
For an external client I will be using a Windows Server 2012 R2 client residing on the 128.1.1.0 subnet.
For simplicity I’ve added a record in the hosts file of my client machine which maps ssl-vpn.vmware.com to the IP 128.1.1.10
Active Directory Users
Use Case 1 (UC1) requires that we use Active Directory for NSX SSL VPN-Plus Authentication. I’ve created a separate Organizational Unit (OU) no hold all user accounts that will have access through the VPN.
Configuring SSL VPN-Plus
Server Settings
To start the configuration of the SSL VPN go to the selected NSX Edge and navigate to SSL VPN-Plus tab , select Server Settings, click Change.
Provide the following information:
- IPv4 Address: 128.1.1.10 (This is the Edge vnik interface connected to the external (public) network)
- Server Certificate: Uncheck [Use Default Certificate). Select the certificate you want to use.
After clicking OK we should see similar configuration:
We have just satisfied the following Kaloferov.com company requirement:
- UC1-R1: SSL VPN solution should utilize a certificate issued by the company’s private internal Certificate Authority.
IP Pool
Select the NSX Edge that will be used and navigate to SSL VPN-Plus tab , select IP Pool, click + (Plus sign).
Provide the following information:
- IP Range: 10.10.10.20-10.10.10.30 (Type the begin and end IP address for the IP pool. These addresses will be assigned to VPN Clients)
- Netmask: 255.255.255.0
- Gateway: 10.10.10.1 (Type the IP address which is to add the routing interface in the NSX Edge gateway)
- Status: Enabled
- Primary DNS: 192.168.1.1
- DNS Suffix: vmware.com
You should have now created the IP Pool.
Private Networks
To satisfy the Kaloferov.com company requirements we will set up two Private Network and by thus giving access to the Management Network (192.168.1.0) and the Load-Balancer-Tier-01 VXLAN (172.16.50.0) logical network.
Select the NSX Edge that will be used and navigate to SSL VPN-Plus tab , select Private Networks, click + (Plus sign).
Provide the following information:
- Network: 192.168.1.0
- Netmask: 255.255.255.0
- Description: HQ Management subnet access
- Send Traffic: Over Tunel
- Status: Enabled
Add another Private Network with the following information:
- Network: 172.16.50.0
- Netmask: 255.255.255.0
- Description: Load Balancer Tier 01 subnet access
- Send Traffic: Over Tunel
- Status: Enabled
You should now have created the Private Networks .
We have just satisfied the following Kaloferov.com company requirement:
- UC1-R5: Users should be able to access only the Kaloferov.com company Management Network (192.168.1.0) and the Load-Balancer-Tier-01 VXLAN (172.16.50.0) logical network .
Authentication
To satisfy the Kaloferov.com company requirements we will set up an AD Authentication. The AD authentication will grant access to the VPN to users within the [NSX VPN Users] organizational unit.
Select the NSX Edge that will be used and navigate to SSL VPN-Plus tab , select Authentication, click + (Plus sign).
Provide the following information:
- Authentication Server Type: AD
- Enable SSL: (unchecked)
- IP Address: 192.168.1.1 (This is my AD server)
- Port: 389 (This port is used for LDAP)
- Status: Enabled
- Search base: OU=NSX VPN Users,DC=vmware,DC=com
This is the destinguisedName of the OU I’ve created for SSL VPN users. You can find the distinguished by selecting the AD group and navigating to [Properties > Attribute Editor > distinguishedName]. If you do not see the Attribute Editor tab , go in the Active Directory Usres and Computers console under View and select Advanced Features.
Note that in this case i’m not using a buildin Windows OU (like the [Users] OU). I’ve created this manually. If you are suing a Windows building OU like [Users] the destinguishedName will not start with OU=<GroupName> but will start with CN=<GroupName>
- Bind DN: CN=Administrator,CN=Users,DC=vmware,DC=com (This is again the distinguishedName of an user account with enough permissions to query AD. You can find this name the same way as described above. )
- Bind Password: (enter password)
- Login Attribute Name: sAMAccountName (default)
- Search Filter: objectClass=* (default)
You should now have configured AD Authentication.
We have just satisfied the following Kaloferov.com company requirement:
- UC1-R4: Windows Active Directory will be used to authenticate identities (users) accessing the VPN. Only users within a given Organizational Unit (OU name: NSX VPN Users) should be given access connect through the VPN.
Installation Packages
We will create a VPN Client installation package and make this available for download to clients.
Select the NSX Edge that will be used and navigate to SSL VPN-Plus tab , select Installation Package, click + (Plus sign).
Provide the following information:
- Profile Name: SSL VPN
- Gateway: ssl-vpn.vmware.com (This is the URL form which clients will access the VMware SSL VPN-Plus home page. )
- Client installation packages for: Windows (I’m using Windows machines as clients. )
- Status: Enabled
You should now have configured the installation package.
We have just satisfied the following Kaloferov.com company requirement:
- UC1-R2: External (public) users should be able to access the VPN under the URL: ssl-vpn.vmware.com.
Client Configuration
Select the NSX Edge that will be used and navigate to SSL VPN-Plus tab , select Client Configuration, click Change.
Here you can adjust the Tunneling Mode. In split tunnel mode, only the VPN flows through the NSX Edge gateway. In full tunnel, the NSX Edge gateway becomes the remote user’s default gateway and all traffic (VPN, local, and internet) flows through this gateway.
We have no reasons to change the default Split Mode.
Edge Firewall
I do not have any firewall enabled on my Edge device , but in case you do don’t forget to make the appropriate adjustments.
Enable SSL VPN-Plus
Before we can use SSL VPN we must first enable it.
Select the NSX Edge that will be used and navigate to SSL VPN-Plus tab , select Dashboard, click Enable.
Test SSL VPN-Plus
Now it’s time to test the SSL VPN connection from our external (public) client.
From the client open a browser and enter https://ssl-vpn.vmware.com. Examine the certificate of the page. This should be valid.
Login with a user member of the AD organizational unit you’ve added in NSX earlier.
Download and install the SSL VPN Client.
Open four powershell consoles and run the following four commands:
- ipconfig /all
- ping 192.168.1.1 (IP address on my Management Network)
- ping 172.16.50.1 (IP address on my Load Balancer Tier 02 VXLAN logical network)
- route print
You should not have connection to these networks or have routes in the routing table.
Now start the SSL VPN Client and login with a user who is member of the appropriate AD organizational user.
In this example I’m loggin in with user PU01.
You should not be able to login with user account which is not in the selected AD organizational unit.
Run again the same commands. You should now have connectivity to the networks and you should see route for these in the routing table.
You should only be able to access the subnets we defined earlier in the Private Networks tab of the NSX SSL VPN-Plus configuration
Note: Each time you make any change in the NSX SSL VPN-Plus configuration, you should download and upgrade the SSL VPN Client
We now have successfully fulfilled all the requirements presented by the Kaloferov.com company:
- UC1-R1: SSL VPN solution should utilize a certificate issued by the company’s private internal Certificate Authority.
- UC1-R2: External (public) users should be able to access the VPN under the URL: ssl-vpn.vmware.com.
- UC1-R3: External (public) accessing the VPN are located on the 128.1.1.0 subnet. The VPN will be published on the external network with IP 128.1.1.10.
- UC1-R4: Windows Active Directory will be used to authenticate identities (users) accessing the VPN. Only users within a given Organizational Unit (OU name: NSX VPN Users) should be given access connect through the VPN.
- UC1-R5: Users should be able to access only the Kaloferov.com company Management Network (192.168.1.0) and the Load-Balancer-Tier-01 VXLAN (172.16.50.0) logical network .
Additional Functional Requirements
The Kaloferov.com company has identified the following additional requirements for their VPN implementation:
- UC1-R6: Users should be utilizing User Principal Names (UPN’s) to authenticate to the VPN.
- UC1-R7: Not all users from the SSL VPN Users organizational unit (OU) should have SLL VPN Access. Only users who have Kaloferov.com company employee ID number should have access to the SSL VPN.
Using UPN for Login Name
To be able to use UPN name (<user>@vmware.com) we must do changes to the NSX SSL VPN+ authentication.
Select the NSX Edge that will be used and navigate to SSL VPN-Plus tab , select Authentication, select the authentication server we created earlier, and click Edit.
Change the Login Attribute Name to userPrincipalName and click OK.
You can find userPrincipalName and all other possible attributes the same way you found the distinguishedName before. Open Active Directory Users and Computers console , select the user account , go to properties, and go to Attribute Editor. If you do not see the Attribute Editor tab , go in the Active Directory Usres and Computers console under View and select Advanced Features.
Test again form the client machine to login to the SSL VPN, but this time use a UPN name. You should be able to successfully login to the VPN.
We have just satisfied the following Kaloferov.com company requirement:
- UC1-R6: Users should be utilizing User Principal Names (UPN’s) to authenticate to the VPN.
Using Filters to Control VPN Access
To be able to filters the user accounts in the NSX VPN Users OU and grant access to only those who have employee ID we have to change the authentication search filter in NSX.
Earlier we have created two user accounts in the NSX VPN Users OU: PU01, PU02.
None of these users has a employee ID set. We will set employee ID only to PU01 user.
As we did earlier, I will edit the attributes of PU01 user object and populate the employeeID attribute with value [VWID0001]
Select the NSX Edge that will be used and navigate to SSL VPN-Plus tab , select Authentication, select the authentication server we created earlier, and click Edit.
The default Search Filter value of [objectClass=*] searches for all objects.
Change the Search Filter value to [employeeID=*]. This way the LDAP search will return only users who have employeeID attribute set.
Click OK.
Now test the SSL VPN again. For user name use the UPN name. You should be able to login with only users who have employeeID set.
The Login Attribute Name and Search Filter properties allow for great flexibility when choosing who can access the VPN and what user name should they use.
We have just satisfied the following Kaloferov.com company requirement:
- UC1-R7: Not all users from the SSL VPN Users organizational unit (OU) should have SLL VPN Access. Only users who have Kaloferov.com company employee ID number should have access to the SSL VPN.