Write a comment

This article deals with the Citrix Cloud Network Locations Services (NLS) and explains why "Undefined" is the new external at Citrix. If you are dealing with the network locations, you might get confused because the wording might not be quite correct, at least for me.

Why do I write that the undefined is the new external? Let's clarify that first: In the NLS settings, I can define internal and external, e.g. my head office as internal and my branch office that is not connected to the network as external. From a technical point of view, these are two fixed IP addresses and usually the firewall through which communication with external parties takes place. So all the other tens of millions of IP addresses are undefined and not external? Yes, but that is precisely the case with Citrix Network Locations Services and is also perfectly understandable if we look at it from the definition side. We define IP addresses that we know, i.e. that are known to us, so everything else is undefined and therefore logical.

It could also be described like this:

 

Intern = Direct access between Citrix Workspace app and Citrix VDA

Client -> VDA

Extern = Indirect access (Gateway Service) between Citrix WorkspaceApp and Citrix VDA, known origin.

Company client -> Gateway Service -> VDA

Undefined = Indirect access (Gateway Service) between Citrix Workspace app and Citrix VDA, of unknown origin.

All unknown clients -> Gateway Service -> VDA

 

With these three definitions, there are also three standard tags: LOCATION_internal, LOCATION_external and LOCATION_undefined. These TAGs can then be used in different places.

Here is an example of network locations that have been set up:



Network Locations

This splits the TAGs as follows

LOCATION_internal = HQ_DE and Azure_Amsterdam

LOCATION_external = BranchOffice_muenster,BranchOffice_mannheim,BranchOffice_luxemburg and BranchOffice_goettingen

LOCATION_undefined = Everything else..



We can then use these TAGs in Citrix policies, for example, and assign a policy to all BranchOffice or prohibit all unknown (undefined) client drive connections.
Additional location TAGs can then be used to assign separate policies, as the location BranchOffice_luxemburg still has the location TAG "luxemburg", this can only be used for the location Luxembourg, with LOCATION_TAG_luxemburg. This means that, for example, policies can be assigned individually.


Question: My company uses Zscaler and thus a cloud-based proxy to protect the company's clients - Zero-Trust. This also made internal clients LOCATION_undefined.

Answer: Exceptions, bypass or whatever the solution calls it should be used here. The exception *.cloud.com would be a start.

 

 

 

Write comments...
or post as a guest
Loading comment... The comment will be refreshed after 00:00.

Be the first to comment.