INTRODUCTION
If you are working regurlarly with Citrix Cloud it may be common knowledge by now that the fundamental connectivity requirement of the Cloud Connectors, on each resource location, is to open up port 443 for outbound connections towards the Internet.
In my experience this is fine and dandy and all, however this won’t be enough for a client’s criteria sometimes. Occasionally we need to jot down the explicit domain names (FQDNs) in which the Cloud Connectors accesses, thus only open up the standard HTTPS port towards these known FQDNs.
This very demand was something I was recently met with so in this post I will share a lesson on pursuing this route.
THE FACTS
In addition to the aforementioned port 443 requirement, a specific Citrix Cloud product documentation page also states that the following wildcarded FQDNs are mandatory for common Cloud Connector services should you operate within environments comprising of an Internet proxy server or certain firewall restrictions[1]:
https://*.citrixworkspacesapi.net
https://*.cloud.com
https://*.blob.core.windows.net
https://*.servicebus.windows.net
If we scroll down further to the next header on the same page, we’re also presented with the option of using Citrix’s complete list containing the explicit FQDNs required for all of the Citrix services[2]. This is in the form of a .json file, available here:
https://fqdnallowlistsa.blob.core.windows.net/fqdnallowlist-commercial/allowlist.json
In that list, make sure that the following FQDN corresponds with your Citrix Cloud Customer ID when using the Citrix DaaS service[3].
https://<CUSTOMER_ID>.xendesktop.netTHE ISSUE
Now, with that very .json file as basis, the client insisted on allowing these known 220~ URL’s solely through their firewall. Fine, I thought. Not what I endorsed, but we’ll make do if there’s no other option.
Once they confirmed that the FQDNs were put into place, I continued with installing their new Cloud Connectors. During the install, the initial ping tests reported success and I could also successfully authenticate with my Citrix Cloud account. Despite this, it went downhill from here.
Regrettably, I wasn’t able to take any screenshots of this behaviour but trust me when I say that the Cloud Connector software installer refused to continue. Not even through a CLI installation using a Secure Client ID and its Secret, I was simply redirected to a blank browser page trying to load “https://accounts.cloud.com”. Strange I thought, since this URL is already included as part of the allow list I personally edited and supplied to the client.
Perhaps there’s an additional URL redirect occuring in the background which we cannot see? Or did the customer not tell me the whole story, fiddled about with the exceptions and didn’t want to admit their fault?
A long troubleshooting session with the customer’s network team ensued and after much pressure from me they finally agreed on allowing the wildcarded FQDN “https://*.cloud.com” through their firewall.
Lo and behold, the Cloud Connector installer continued and I was able to pick the correct Cloud Tenant along with the relevant resource location and then let the finalizing ping tests run without issues. In other words, the installation completed as hoped for.
THE LESSON
In an utopia, I would simply recommend to open up port 443 for outbound connections towards the Internet for the Cloud Connectors, no fuss. In most cases it should be sufficient security-wise, no opening for incoming traffic necessary and the outbound traffic is encrypted. Plus, you will also avoid immense head-scratching when Citrix adds any newly required FQDNs further along the line.
If this isn’t possible, I would kindly advise to NOT rely on the allowlist.json blindly for firewall openings! In that case, use the wildcarded FQDNs in conjunction with the allow list, meaning that you use it as a baseline for all other URL’s but let the known wildcarded FQDNs cover the URL’s sharing the same domain name. This should help ensure that vital functionality remains into place.
In the case of a client still refusing to have wildcarded sub-domains allowed, clarify and explain that they would then be responsible of checking Citrix’s allow list regurlarly and add new exceptions accordingly. Not to mention if they’re going to manually enter over 220 URL’s in the beginning, it’s tedious work and mistakes are bound to happen which most likely was the situation at hand. I would also bring a network tracing tool or similar here, it can be good fun to prove a client wrong now and then. 😉
All things considered, security in all glory, indeed. However, it should be known that pursuing an “explicit FQDN allow” route is a huge risk to take when the other side of the coin could entail a total outage for the customer’s Citrix environment. I’m not trying to sound unnecessarily doomful here, but just imagine how irritable the situation would be to find out that an entire outage was caused by a newly required FQDN not yet allowed.
To put it in another way, assess the environment’s criticality and then choose your design and route wisely.
Sidenote; At the time of writing this blog post I double-checked within my CTA channels whether the allowlist.json is up-to-date and accurate. Indeed, it should be.
REFERENCES
[1] https://docs.citrix.com/en-us/citrix-cloud/overview/requirements/internet-connectivity-requirements.html#cloud-connector-common-service-connectivity-requirements
[2] https://docs.citrix.com/en-us/citrix-cloud/overview/requirements/internet-connectivity-requirements.html#allowed-fqdns-for-cloud-connector
[3] https://docs.citrix.com/en-us/citrix-cloud/overview/requirements/internet-connectivity-requirements.html#allowlistjson