In Part 1, we looked at what NLS is, configuring it and some troubleshooting around this new service. As a second part to this blog I am going to look into this a little bit further and highlight what we have seen in the field.
There is many advantages of using NLS in Citrix Cloud and I think really it all comes down to speed. When the gateway signs off on your call to launch an app or desktop as being internal, an ICA file is returned to the endpoint with the internal IP of the VDA. A direct connection with the machine is always going to be faster than having to go all the way through the cloud to have to come back down to reach the workload you requested.
This Citrix article highlights what are the big advantages when it comes to EDT which will only work with UDP. The main two for most though is that:
- It just gets the data where it needs to go faster (it’s a transport protocol).
- RTP Audio, HDX Real-time Optimization Pack for Skype for Business and Teams all rely on it. For these scenarios, an unreliable “best effort” protocol works very well.
When the endpoint makes a call to the Citrix Cloud Gateway it will check to see what NLS site external IP you setup. If it’s outside the range setup it will report it as being external and you will go normally through the gateway and fall back to normal TCP. In most common cases your endpoint where you launch the workspace app from, this will be on the same external network as your VDA’s and this is the external IP you would set up for your NLS site as shown in the last blog. If this is the case best to check https://www.whatismyip.com/ and use the external IP in the PowerShell script. If you keep seeing TCP in director, then most likely you are on a different external network to where the VDA’s are so double check this on the endpoint too.
From the field we have seen customers/partners host the VDA’s/workloads in a datacentre off site. They then may have a VPN connection from the customer’s office direct to the datacentre. When we originally setup up the NLS site in the last blog we just spoke about the external address of where the VDA’s were. But it’s important to remember in circumstances like this that it’s not the external address of the VDA’s that we want to use it’s the customer site external address that needs to be added here.
You can see below from the very basic diagram drawn that when the endpoint makes a call to the Citrix Cloud gateway it will check to see what NLS site external IP you setup. If it’s outside the range setup it will report it as being external and use the gateway (TCP). In the below example if we set the external IP of the VDA’s as 220.127.116.11 /24 then only endpoints in this range will utilise UDP. What you need to do here is then add additional NLS sites for your different locations so below I would add a new NLS site for the Partner office as well as one for the customer so that they too can use NLS for the benefits of UDP over TCP.
One other thing to note, a side effect/limitation of this is that when accessing the workspace through the Receiver for HTML5, you will be going to a HTTPS URL (https://customer.cloud.com), applications and desktops will fail to start. The following error message is displayed:
“Citrix Receiver cannot create a secure connection in this browser. Refer to the Citrix Knowledge Centre article CTX134123.”
The reason this is happening is because when we are using workspace with the Citrix Receiver for HTML5 through an HTTPS URL (https://customer.cloud.com), applications and desktops cannot be started. The reason for this is that HTML5 receiver uses WebSocket connections, and most browsers only support secure WebSocket connections. So the HTML5 Receiver requires TLS to the VDA. In our case with NLS configured we are using UDP for internal connections and will see the above in the browser. You can see the highlighted ica log showing this and the need for a secure connection.
Solution 1 There is a workaround for Firefox in the article highlighted above, but how many of us will be using Firefox.
Solution 2 Is to enable SSL on the VDA using one of these Citrix guides:
Some other drawbacks
There is another great MYCUGC article here that speaks about extending NLS with beacons, but with everything there is limitations:
- In a POC or testing in your lab this is great but in production I’m sure there will be security concerns around allowing any endpoint to be dynamically setup.
- “There is no fallback to CGS when a client is presumed internal, the VDA is not reachable via the internal network.”
- “The script will fail if a client had a DirectAccess connection at the time the beacon check was made. When, at the moment of a reconnect, no DA connection was available, the launches to the VDA will fail.”
HTML 5 Receiver Logging
Additionally, if you are running into any issues with the HTML5 receiver for workspace you can reference the following Citrix article for help:
In short though while logged into the Citrix workspace in the browser using HTML5 receiver, before you reproduce the problem open another tab.
My account as an example will look like this:
In the new tab, amend it to look like this:
You can then hit Start Logging and move back to your original tab to reproduce the problem. Come back here, and stop logging. You can then download the log to view any issues you encounter.