Physical efforts in virtualization and mobility
Category Archives: Load Balancing
Following on from my last post which focussed on traffic flows to enable remote connectivity, I thought I would look at the internal side of things. I am coming across more and more on premises environments where there are lots of VLANs with firewalls inbetween them so this is becoming more of a requirement.
For this post I have just produced a diagram which you may find useful, when I get time, maybe I’ll produce another firewall spreadsheet. This diagram assumes that there is a common server VLAN hosting the likes of the Connection Servers and App Volumes Managers so I have not added the ports required between those sorts of components.
You may have noticed that I favour flat diagrams over the 3D ones that VMware produce. I have created a basic Visio stencil set for these which you can download if you wish.
When deploying Virtual Desktop/Application remote access solutions you often need to engage with ‘The Firewall Guy’. This can often be a difficult conversation involving lots of questions such as “what?”, “from where?”, “to where?” and “why?”
To this end I have created a Unified Access Gateway Firewall Rules Generator which you can download. You just need to plug in the parameters on the lookup tab and it will pre-populate the firewall rules for you. Other than the standard back end stuff which you (as the Virtual Desktop Consultant) should already know, the only things you need to ask the firewall guy for are:
- Unified Access Gateway owned IP addresses in the DMZ
- Internet facing IP Address for the NAT rule – You don’t actually need to know this yourself but it helps in order to provide a fully completed rule set
- Certificates – May be from someone else entirely
Hopefully you won’t even need to talk to the firewall guy at all after that! You can fill in the sheet and email it off to him/her. Here’s a diagram I put together with the ports:
A Few points to note:
- This is based upon the information from this VMware article which I found to be missing items such as DNS and RADIUS so I have added these in
- The deployment mode is based upon the two IP addresses per Access Point; Single IP will work fine, just enter the same IP in both the Front-End and Back-End Management sections
- When Deploying the Unified Access Gateway either via PoSH or OVF, the first IP entered becomes the external one, not the Management/Backend Communication one, which is the second one entered
- If you want to read a blog on actually deploying UAG, this by Carl Stalhood is probably the best one out there
I’ve used the PowerShell deployment method before but since 2.8 the OVF deployment actually works properly so it’s just as easy to deploy it that way then import your predefined settings from a JSON file.
So it turns out that TLS 1.1 and 1.2 is not supported on the NetScaler VPX platform to communicate with the backend servers.
Update: At the time of writing this was the case but support has now been provided with version 10.5 Build 65. MPX and SDX appliances would also be affected if they are running firmware older than 10.5 Build 58. I have since load balanced these services successfully using MPX 10.5 Build 60.7004.e with no need to carry out the procedure below.
The check boxes are there on an SSL Service Group but they won’t allow you to tick them. The trouble with this is that Horizon View 6.2 forces use of 1.2 on Server 2012/R2 so if you have created an SSL service group and point to 6.2 Connection servers (or recently carried out an upgrade), the members will show as Red (Down). Given the lack of support on the NetScaler end, the only workaround at the present time is to add TLS 1.0 support to the connection servers, which is achieved by editing the View LDAP instance on the Connection Servers using ADSI Edit. Below is a procedure I have adopted from the VMware documentation center but is specific to this issue:
1. Start the ADSI Edit utility on your View Connection Server computer.
2. In the console tree, select Connect to.
3. In the Select or type a Distinguished Name or Naming Context text box, type the distinguished name DC=vdi, DC=vmware, DC=int (exactly this DN, not your own domain)
4. In the Select or type a domain or server text box, select or type localhost:389
5. Expand the ADSI Edit tree, expand OU=Properties, select OU=Global, and select CN=Common in the right pane.
6. On the object CN=Common, OU=Global, OU=Properties, select pae-ServerSSLSecureProtocols, this will be configured as <not set>
7. Enter the following string in this field \LIST:TLSv1.2,TLSv1.1,TLSv1
8. Restart the View Connection Server Service
You do not need to do this on the other connection servers as this change will replicate to all other servers in the cluster. Restarting the Connection Server service on all of the all of them will suffice. As a side note, this also seemed to affect Imprivata OneSign appliances connecting to the Connection Servers so it looks like they don’t support TLS 1.2 either.
Now true to form this isn’t a how to on “Load Balancing Exchange 2010 with NetScaler”; there are plenty of blogs on that, some of the best ones I’ve come across are below:
For the process end to end, these are very good:
Two from Dave Stork:
For handling rewrite which basically means appending ‘/owa’ to the end of a blank URL:
and another detailing content switching:
Actually the best one I have found, particularity for content switching is this one, which has a smart single expression covering OWA, RPC and OAB. It also has a summary of some useful tips at the end:
I do a fair amount of NetScaler work normally due to XenApp or XenDesktop and a requirement to include remote access within the solution. On the odd occasion I am called upon to do pure load balancing assignments however. Most of them are pretty straightforward including Exchange if you have a lot of IP addresses at your disposal. When you don’t you will need to get your head around content switching. One of the above blogs will help you there.
SSL Offload – Quick how to
Now to the point, Content Switching to one side, most blogs and guides you will come across will blindly advise the same course of action to achieve load balancing of Exchange. In summary:
- Create the targets to be load balanced
- Assign them to either an HTTP based Service Group or Service (which, is a personal preference but I always prefer flexibility from Service Groups).
- Assign the Service Groups to an SSL based vServer with a commercial public SSL certificate assigned
- Modify the IIS virtual directories on the Exchange Servers to Not Require SSL and set Client Certificates to ‘Accept’
- Ensure authentication is set correctly in the IIS virtual directories or the Exchange console.
- In HKLM\system\CurrentControlSet\Services\MSExchange OWA Create a DWORD SSLOffloaded = 1
Collectively these steps enable SSL offload on the NetScaler; that is the CPU intensive decryption process is moved away from the Exchange servers onto the NetScaler appliances. This is a particularly good thing if you have physical MPX NetScalers as they have dedicated SSL offload cards built into them, ultimately the Exchange servers will have improved efficiency. For a VPX it’s probably marginally better than having your Exchange servers carrying out this task but it will increase CPU utilisation on the associated hypervisor host(s).
So although I’m quite comfortable with NetScalers, Exchange is not my thing, so I’m not really happy about blindly making these changes to a production Exchange servers which have thousands of internal users on-board. After-all in many cases you may only have a maybe fifty or a few hundred concurrent external users to cater for, but with thousands of internal users using these CAS servers, there could be adverse affects.
The needs of the many outweigh the needs of the few
Consider the following:
- Remote access for Exchange services is only likely to be used for ~100 concurrent users, meaning SSL transaction load will be low
- These SSL transactions are going to be spread across a number of CAS servers
- Modification of the IIS settings could adversely affect internal users of OWA (I’ve seen this happen)
- Removing the requirement for SSL would mean some internal Exchange related traffic will be sent in plain text
Going against the grain
I decided I didn’t like the smell of the above scenario so I thought what’s wrong with using an SSL only Service Group assigned to my SSL vServer? To me it sounded like SSL bridge was the ticket, this will just proxy the connection through carrying out no decryption. There are two issues with this:
- The Exchange CAS servers will require the public SSL certificate (more changes to the Exchange infrastructure that I don’t want to make)
- SSL Bridge is a very limited option, it removes the possibility of carrying out move ‘advanced’ features such as Content Switching and Rewrites on the NetScaler.
So the only remaining course of action is to use standard SSL service groups and vServers with no SSL offload, and do you know what? It works. OWA, ActiveSync, RPC over HTTP etc, all work just fine; there is no need to to make any changes to your Exchange servers that you may not fully understand (like me) at all. Sure you have no SSL offload but consider how many users you will be presenting this solution to, and the capability of your CAS servers.
What actually occurs in the scenario is:
- The vServer accepts SSL traffic
- Traffic is then decrypted within the NetScaler
- As traffic leaves the Netscaler on it’s way to the Exchange servers, it is re-encrypted
- The public SSL certificate is only required on the NetScaler, specifically the Load Balancing vServer and Service Group and the Content Switching vServer