Now that we know what the flow looks like for a XenMobile application when connecting via NetScaler, let's look at some troubleshooting suggestions. Both XenMobile and NetScaler provide some excellent tools to support this integration.
XenMobile can be complex to configure manually. There are many components and operating systems (IOS, Android, Windows) each with their own characteristics, which means a lot of policies. Citrix has made this job a lot simpler by providing a wizard in NetScaler Gateway to help create these policies with just a few clicks. If you see issues during your deployment, I would highly recommend redoing the configuration using the wizard. This is available in the Integrate with Citrix Products section of the GUI:
Between the client devices, NetScaler, the XenMobile server, and the backend infrastructure, there are a lot of connectivity points that need verifying. Citrix provides three excellent tools to help verify that the necessary connectivity and configurations are in place:
- On the NetScaler Gateway: Go to the Integrate with Citrix Products section where the wizards are. Click on XenMobile and you will find a Test Connectivity button in the top right-hand corner. This button runs through a number of important checks for you and verifies the following:
- On the XenMobile server: Go to the page at
https://<XenMobile_Server_IP>:4443/support.html(or click on the wrench on the configuration screen) and you will have the means to test connectivity to NetScaler and see whether the necessary settings are in place:
- Using the XenMobile Cerebro Utility: Cerebro is a small diagnostic utility (it needs Excel on your PC) that can either run checks against NetScaler if your PC has direct access to it, or alternatively accept an
ns.conf, analyze it and tell you whether the necessary configuration pieces are all in place. This tool is available at KB Article CTX141060 (http://goo.gl/jZSH6V).
Just as with other NetScaler Gateway scenarios the authentication exchange and any issues are captured in aaad.debug. The connection attempts and the start and end of sessions are captured in ns.log.
WorxHome and XenMobile server have their own logs as well. These can sometimes seem unintuitive, especially when captured with the level set to debug (as this may sometimes contain references to internal functions). Nonetheless, coupled with the timestamp of the issue, they can provide you with a good starting point by looking for the keywords Error or Failed.
The procedures to collect these logs are covered in the XenMobile Logs Collection Guide. You can use the shortened URL https://goo.gl/tBtjtV which points to this document. This article covers the following topics:
Here are some of the integration issues that commonly get reported in the XenMobile-NetScaler field.
MicroVPNs tunnels each use up a VPN license, one per device. So ensure that sufficient licenses are in place.
For any issues involving WorxApps being unable to connect, verify the following:
- The DNS suffix configured is correct – this is very important for Android, since an incorrect setting means the VPN tunnel does not start and any resources that are only accessible via the gateway VIP will be unreachable.
- Network access is set to the right value. This is a setting on the XenMobile server, which is independently set for each application. There is a very popular blog that shows sample settings for WorxMail; you can access it here: https://goo.gl/fXiB3v.
- Whether the application traffic uses the tunnel or not depends on this setting. Here is a screenshot of the options and what they mean in NetScaler VPN parlance:
- Following is the explanation of the preceding options
- Unrestricted: Split tunnel ON
- Blocked: No network access at all
- Tunneled to the Internal Network: Split tunnel OFF
If you choose the Tunneled to the internal network setting, you need to be sure that NetScaler SNIP can reach the backend server without any firewall issues.
Verify that this field is configured on the session profiles. If this is missing, WorxHome autodiscovery will fail. Here is an example taken from my lab. The URL should point to the XenMobile server or an LB VIP representing it:
If you are load balancing multiple XenMobile servers, verify that persistence is set to ACNODEID, and that this ACNODEID is being received in the requests, by looking at a trace. Try disabling all but one XenMobile server to rule out load balancing issues as a cause of the problem:
SAML-based SSO for ShareFile is a very popular use case. Consider the following three steps if you see any issues here:
- Verify that the ShareFile account works by logging into the ShareFile site without SAML.
- Ensure that the times are set correctly on NetScaler and the XenMobile server. As we discussed in our AAA chapter, time skews will cause SAML authentication to fail, as the assertions will be deemed invalid.
- To validate that the configuration is set correctly, open a web browser (this can even be on your PC) and access the following URL:
https://<subdomain>.sharefile.com/saml/login. For example https://bobleroy.sharefile.com/saml/login.
This should present you with the NetScaler login page without any errors. You should be able to log in and see all your ShareFile files and folders. If this doesn't work, the SSO URL configured on the XenMobile server might be incorrect or there might have been a certificate failure.