FAQ: XenMobile 10 and NetScaler Gateway Integration

Event NetScaler Xenmobile

This post contains frequently asked questions about XenMobile 10 and NetScaler 10.5 Integration.

The concept is the same with latest NetScaler Firmware.

Q. What versions of NetScaler are supported with XenMobile 10 deployment wizard?

A: NetScaler 10.5 build 54.9 or later are recommended with XenMobile 10 deployment wizard. For list of compatible NetScaler versions/builds with XenMobile 10, go to Citrix eDocs.

User-added image
Q. Do I need to upgrade to NetScaler 10.5 to integrate with XenMobile 10?

A: No. Even though it is recommended to use the latest build of NetScaler 10.5, it is not required. You can still use NetScaler 10.1.
Ensure to check the XenMobile issues fixed in NetScaler available in Citrix.com. This would assist you in the decision to upgrade or not. For example, NetScaler 10.5 (Main) Release Notes describes the overall fixes included on NetScaler 10.5 build 55.8.
Note: Some of these fixes are related to XenMobile.
When NetScaler Gateway is deployed with clientless access and Secure Browse is used with an HTTPS Proxy, the appliance fails if users close the connection when the proxy connection is still being established.

Q. What is deployed by the new XenMobile 10 wizard?

A: The new XenMobile 10 wizard is very similar to the one introduced back with NetScaler 10.1 release for earlier releases of XenMobile. The following list provides a brief description of some of the new prompts.

When you launch the XenMobile 10 wizard, you will be prompted to select the settings/components you want to configure for XenMobile.

By default, Access through NetScaler Gateway and Load Balance XenMobile Servers are checked.

User-added image

Next, there is a new prompt to configure a load balancing virtual server for MAM traffic. Ensure to follow these tips to properly deploy your XenMobile 10 solution.

  • Load Balancing FQDN for MAM: This FQDN must match with the XenMobile Server hostname defined during the initial configuration of XenMobile 10. If this FQDN does not match, then, users would not be able to access the WorxStore.
    User-added image

    Example of XenMobile 10 CLI configuration

    User-added image
  • Load Balancing IP address for MAM: This virtual IP address must follow the RFC 1918 standard of private IP addresses. If you use a non-private IP address for this virtual server, then, the NetScaler will not be able to contact the XenMobile Server successfully during the authentication process.
    User-added image
  • Port 8443: This is the port pre-defined for the MAM traffic.
    User-added image
  • SSL Traffic Configuration: This setting allows you to define how to communicate with the XenMobile Server for MDM & MAM traffic.
    User-added image
  1. Selecting HTTPS communication to XenMobile Server (for MDM traffic): NetScaler will set the load balancing virtual servers to SSL Forward (also known as SSL Bridge) on ports 443 and 8443. In this configuration, the NetScaler will not terminate the SSL traffic to XenMobile Server. It will forward it to the XenMobile Server over secured ports 443 and 8443. Hence, make sure the defined XenMobile Server hostname (ie. FQDN) can be reached externally. Otherwise, users would not be able to enroll successfully. Please refer to this article – (CTX200847) Second Profile Installation Fails when Enrolling iOS Devices.
User-added image
  • For the MAM traffic, the NetScaler will set the load balancing virtual server to SSL Offload listening on port 8443. The communication to the XenMobile Server is configured on port 8443.

Example of MAM Load Balancing virtual server.

User-added image

Example of MAM Service Group.

User-added image
  1. Selecting HTTP communication to XenMobile Server (MDM & MAM traffic): SSL Offload configuration would be used on NetScaler. In this configuration, the NetScaler will contact the XenMobile Server(s) via port 80 in the back-end.

Note: If you plan to use HTTP communication to XenMobile Server, you must allow port 80 traffic on XenMobile’s built-in firewall. By default, port 80 is not allowed. To allow port 80, navigate to the CLI console > Configuration Menu > Firewall. Set “y” to enable port 80.

User-added image

Example of MDM Load Balancing virtual servers.

User-added image

Example of MAM Load Balancing virtual servers.

User-added image

Example of MDM/MAM (shared) service.

User-added image

Next, you need to select what Server Certificate to use for the load balancing virtual server for MAM.

User-added image
This SSL server certificate can be either from a public or private CA. Ensure to have the full SSL Root CA chain (that is, intermediate certificates) bundled in the certificate file.
Q. Why is the persistence type for MAM load balancing virtual server set to Custom Server ID?
A: When XenMobile Server 10 is deployed in a multi-node cluster solution, NetScaler needs to maintain the MAM-traffic session by checking the server ID value of each node. This value is automatically obtained by NetScaler (from each node) when using the wizard.
Each XenMobile Server node has a unique server ID. To change the server ID value, you have to change the IP address of the XenMobile Server. After reboot, the system will generate a new value.

Example of XenMobile node service with Server ID value.

User-added image

You can manually gather this value from each XenMobile cluster node in the CLI console.
Select Clustering Menu > Show Cluster Status.
User-added image

Example of MAM load balancing persistence type Custom Server ID.

User-added image

In the MAM load balancing virtual server, the NetScaler will set a timeout value of 2 mins along with an expression – HTTP.REQ.COOKIE.VALUE(“ACNODEID”).

User-added image

This expression means that the NetScaler will check for this cookie value (provided by the client in the communication flow) and determine which node to redirect the traffic.

Q. After running the XenMobile 10 wizard, why do I see a local DNS (A) record created with the XenMobile hostname?
User-added image

A: This value is vital to ensure the NetScaler Gateway virtual server contacts the MAM load balancing virtual server (internally) and decide which XenMobile Server node to contact. The DNS record value points to the MAM load balancing virtual server (listening on 8443).
This DNS record is not applicable for MDM traffic (for example, enrollment, application/policies push, and so on).

Q: Is there a high-level communication flow diagram to understand how MDM and MAM traffic flows through the NetScaler?

A: Yes. The following is a communication flow diagram for XenMobile Cluster environment.

User-added image

MDM Traffic:

  1. Mobile device uses Worx Home to enroll the device.
  2. NetScaler will intercept this communication using both LB vservers listening on port 443 and 8443.
    To balance the MDM traffic, NetScaler is using SSL Session ID as persistence.
  3. When the device is enrolled, one of the XenMobile Servers in the cluster ‘push’ policies/apps along with the NetScaler Gateway URL to the mobile device.
MAM Traffic:
  1. If the user wants to access Web/SaaS/MDX apps from XenMobile Server, Worx Home will communicate with the NetScaler Gateway vserver (port 443). Note that users will be prompted to enroll as an option if they bypass the enrollment process.
  2. When the user is authenticated on NetScaler Gateway, NetScaler will contact the internal LB vserver used to load balance MAM traffic sessions. To balance the MAM traffic, NetScaler is looking for cookie value called ACNODEID.
    The NetScaler will use the persistence of CustomServerID to identify which XenMobile Server node to contact based on the ACNODEID.