XenMobile environments that have NetScalers can take advantage of several enhancement options. Following are some of those options that may help optimize a XenMobile environment.
Ldap/(s) Virtual Server
Ldap and, the SSL based version Ldaps, are commonly used forms of authentication in a XenMobile environment. When a NetScaler is available best practice would be use a Virtual Server (Vserver) to load balance Ldap/(s) traffic for resiliency and scalability. Setting up an Ldap Vserver is a fairly straight forward process using the TCP protocol on port 389, while Ldaps calls for SSL_TCP on port 636 and a few additional steps.
Last year a colleague published a good tech note regarding how to setup an Ldaps virtual server for use by Access Gateway. http://support.citrix.com/article/CTX133893 The Ldaps Vserver can be setup in the same manner for NetScaler Gateway, and may also be utilized by XenMobile Device Manager, and or XenMobile AppController. Just be sure that the controllers reference a domain name corresponding to the certificate bound to the Vserver IP address. Also be sure to reference the domain controllers by domain name rather than IP address.
add server domainserver1.domain.com_ldaps_srv srv1.srv1.srv1.srv1
add server domainserver2.domain.com_ldaps_srv srv2.srv2.srv2.srv2
add service domainserver1.domain.com_ldaps_svc domainserver1.domain.com_ldaps_srv SSL_TCP 636
add service domainserver2.domain.com_ldaps_svc domainserver2.domain.com_ldaps_srv SSL_TCP 636
add lb vserver vservername.domain.com_ldaps SSL_TCP vs1.vs1.vs1.vs1 636
bind lb vserver vservername.domain.com_ldaps domainserver1.domain.com_ldaps_svc
bind lb vserver vservername.domain.com_ldaps domainserver2.domain.com_ldaps_svc
bind ssl vserver vservername.domain.com_ldaps -certkeyName “*.domain.com”
[NOTE: There are a few options for an Ldap/(s) Vserver monitor, each with a bit more setup involved:
1) Use the build-in TCPS, yet monitoring is limited to TCP/SSL
2) Create a custom LDAP monitor /blogs/2011/01/29/monitoring-secure-ldap-using-citrix-netscaler/
3) Create a custom USER monitor http://support.citrix.com/article/CTX132944]
Mobile Traffic Profile
Early TCP implementations assumed fairly accurately that a lost packet equated to congestion and subsequently invoked “harsh” congestion avoidance algorithms. With mobile devices connecting over Wifi or carrier networks lost packets may only indicate a change in Wifi band, or a switch to a carrier network for example and “harsh” action like halving the outstanding window would not be beneficial. Subsequently algorithms such as “Westwood” have been introduced to account for mobile devices and maximize the transfer window while still mitigating congestion. Wikipedia provides an overview of the algorithm http://en.wikipedia.org/wiki/TCP_Westwood_plus
Last year my colleague Abhilash Verma did a nice job introducing the TCP Westwood algorithm for NetScaler within a series of blogs on TCP optimization. /blogs/2012/04/26/netscaler-10-tune-tcp-stack-for-wireless-use-cases-with-westwood/
TCP Westwood is included in a built-in TCP profile “nstcp_default_Mobile_profile” which includes other Mobile TCP optimizations. Applying the profile may improve overall mobile session traffic, but should always be verified in a test environment before migrating to production.
From the NetScaler GUI under System > Profiles you can see the details of the nstcp_default_Mobile_profile. To apply the profile to a NetScaler Gateway Virtual Server select the TCP profile under the Advanced tab as shown below:
DNS Virtual Server
DNS is also a critical component of any XenMobile environment. Setting up a NetScaler Vserver for DNS is also a best practice to provide resilience and scalability to controllers. Under DNS > Name Servers selecting “DNS Virtual Server” pops up a “Create Virtual Server” screen populated for DNS. Here an IP address for the Vserver may be entered and associated services may be added as shown below:
Then once the DNS Vserver is created be sure to reference it in NetScaler Gateway session policies Network Configuration tab as shown below:
SSL_BRIDGE is a versatile form of Vserver which can provide a conduit to SSL based servers that are not capable of being proxied for SSL Offload. It is often used for XenMobile Device Manager controllers, but can also be used as a form of network address translation.
To help mitigate the risk of Single Sign-on (SSO) to untrusted targets NetScaler Gateway will only allow SSO to “private IP addresses” defined in Rfc 1918 http://www.rfc-editor.org/rfc/rfc1918.txt (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). Some companies, particularly hosting providers, use public IPs in DMZs where controllers, that are SSO targets, are hosted. To “workaround” this SSL_Bridge may be employed.
For example add an SSL_BRIDGE Vserver for AppController as shown below:
Be sure add a DNS record referencing the private IP address in the enterprise DNS servers or add a Virtual Server as shown above, and add an A record directly on the NetScaler for the NetScaler Gateway to reference as shown below:
For more information regarding XenMobile or NetScaler see Citrix eDocs: http://support.citrix.com/proddocs/topic/cloudgateway/xmob-landing-con.html
Worldwide Consulting Solutions – Mobility Practice