Physical efforts in virtualization and mobility
Category Archives: NetScaler
It has been a VERY long time since I’ve posted anything but I just had to get this quick one out.
Standard NetScaler Gateway for Citrix Virtual Apps and Desktops, with StoreFront, with Universal Gateway feature of SSL VPN. Laptops have the Citrix NetScaler Gateway Plug-In, Split tunnelling is set to OFF, so all traffic is forced down the VPN connection.
Connect to the URL with either the browser of the Gateway Plug-in works fine, intranet site and proxying to the Internet works fine. User home drives, and general departmental shares do not work however, even though SMB port 445 is open from the NetScaler (SNIP) to the file servers.
What we found is that mapping the file shares using IP address instead of the host name the file shares worked fine. What we also found is that using a non-domain joined laptop, the file shares worked fine with both host name AND IP address.
- Add the laptop to the domain – Fails
- Remove it from the domain – It works again
Please bear in mind this article is not to scale and this took a very long time to bottom out, this article was a clue. So we got the firewall guy on the phone and did a trace from the NetScaler SNIP to ANYWHERE to see if there were any drops. The key one we found was port 88 Kerberos, to the domain controllers. This was denied, and to be fair we hadn’t requested it.
Next day this was added and SMB shares were now working fine.
Note that port 88 is UDP with a TCP failback so ensure that both are requested.
It’s also worth pointing out that this port is not listed on either the Citrix Ports or Industry saviour Carl Stalhood’s firewall rules guide , if it was it would have been requested already. Personally I feel that mapping drives via VPN is a standard requirement, even in this day and age of using OneDrive etc.
Until next time….maybe!
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