Citrix Receiver and StoreFront. The 2 single most important parts of your Citrix environment. These 2 components are the what your users see and interact with every day. You must ensure these are always up to date to take advantage of the latest XenApp and XenDesktop features. Above all, everything has to be easy to use. With StoreFront 2.6 and the most recent Receiver 4.2, you have the ability to create a very impressive user experience. You can use a single URL (single FQDN) to deliver a highly secure NetScaler Gateway powered SSL ICA proxy experience both inside and outside the company that is seamless to your users.

Using a single FDQN, meaning a single website URL, to access Citrix resources inside and outside of your company has been possible for a while now. But it finally became officially supported in StoreFront 2.6 just a few months ago. It is documented here and there have been some recent updates to the article as of a couple of weeks ago helping it become more clear for anyone looking to implement this:

http://support.citrix.com/proddocs/topic/dws-storefront-26/dws-configure-single-fqdn.html

The only issue is that this article uses NetScaler Gateway externally but StoreFront internally. I’m going to show you how to do it with NetScalers both inside and outside. There are some pros and cons in doing this:

PROS

• Identical user experience both inside and outside the company
• HDX Insight metrics
• Seamless user experience. Launch a session on an iPad going from home, to work, to lunch and coffee at Starbucks, back to work, and home again. The experience just flows, more on this later.

CONS

• No passthrough/single sign-on (SSON)
• No pre-populating Store info into Receiver via command line switches (the Store switch that does StoreFront discovery). Must use email discovery, type the NetScaler Gateway URL, provisioning file from StoreFront console, or Activate option in Receiver for Web to get the config into Receiver. All of these are interactive methods the user will need to perform. Which may turn out to be a good thing, I’ll cover more on this later.

This have a NetScaler Gateway both inside and outside using a single URL is not discussed in the eDocs but I have spoken to several people at Citrix and they have told me this is a 100% valid and supported solution. I hope to see an eDoc covering this deployment at some point. So until then, let me explain how it all works.

In the following example, I have chosen to setup gw.yourdomain.com to be the single URL for the NetScaler Gateways. You may choose whatever makes sense for your company such as citrix.yourdomain.com, apps.yourdomain.com, workspace.yourdomain.com, etc. but just remember the shorter the better. Users will need to remember the URL so the shorter and easier it is, the better off you will be. And with Citrix integrating XenMobile apps in the upcoming Receiver X1 and StoreFront for a unified “business workspace”, it is to your advantage to remain as generic as possible with your URL. You never know what other integration points you will add down the road.

HOW IT ALL WORKS

TRAFFIC FLOW: EXTERNAL NETSCALER
Let’s break down the diagram first and go over the traffic flow. First the outside. There are several ways to implement Netscaler for external access. I’m going to cover two of the more common ways people deploy them. It depends on what kind of network security requirements you have. First the old sandwich it in the DMZ method:

This puts your NetScaler in the DMZ with a firewall in front of and behind it. This method is often used because it’s the most straight forward setup and the firewall controls what gets in and what gets out. This method is not ideal from a security perspective because the firewall going internal is getting turned into swiss cheese punching holes through the firewall every time you need to deliver an internal resource. Additionally if you have other network appliances or Windows servers in your DMZ, all it takes is for one of them to get hacked and suddenly an attacker can get to the NSIP/management IP of your Netscaler. That is bad news.

The better method in my opinion is using a 3 tier network architecture when deploying a NetScaler:

You have a DMZ, a Protected zone, and then finally the Internal environment (192, 172, and 10 networks respectively in this diagram). Your NetScaler resides in the Protected zone. It has a SNIP in the DMZ and a SNIP in the Internal zone. The NSIP/management IP resides in the Protected zone completely buffered. So now you don’t have to tear up your internal firewall anymore. The SNIP in the internal zone does all the talking to internal resources. Also if your DMZ were to get owned, the attacker only sees a SNIP that’s using SSL. That’s it. They’re not going to be able to attack your NetScaler and potentially be able to get into the management console. Only the NSIP will have management functionality enabled in this setup.

You have to remember the NetScaler is an extremely hardened network appliance. There is not much threat having a SNIP into each zone. Especially if management functions are disabled on those SNIPs. Some companies actually require that network engineers can’t even manage perimeter network appliances from the internal network. They require the network engineer to access a PC or virtual desktop that is in the Protected zone to manage their perimeter network appliances. If you don’t have a security requirement for this, just enable management tasks on the internal SNIP (or better yet create a dedicated internal VIP) and use that for management tasks from the internal network.

If you take the 3 tier approach then you may question why you even need a second pair of NetScalers on the internal network. There are several reasons for this such as balancing internal and external traffic loads separately, segmentation of traffic for QoS, requirements to keep internal traffic on the internal subnet (10 network in the example), etc. For my example diagram and the article, I chose to take a 2 tier approach which I find many companies like to implement initially. Most of the time they choose to move on to a 3 tier approach once they see exactly how much traffic flows through their NetScalers as it is much easier to manage.

TRAFFIC FLOW: INTERNAL NETSCALER
Now on to the Internal NetScaler. In this portion of the diagram you can see that we have NetScaler Gateway setup as well as a StoreFront load balanced VIP. This is a pretty standard setup for most companies.

TRAFFIC FLOW: STOREFRONT
Now let’s focus on the StoreFront servers. As you can see in this diagram the external Netscaler and the internal Netscaler don’t talk to each other. They don’t know about each other at all. But they both talk to StoreFront. StoreFront is composed of the the intelligent IIS web servers that know about the external Netscalers and the internal Netscalers. They handout the proper info to each NetScaler that talks to them. They are the glue that holds all this together.

And if StoreFront doesn’t like what’s being said or doesn’t know who you are, it will very nicely in plain English log it in the Citrix Delivery Services event log. Seriously, StoreFront has come a long way from the “dumb” Web Interface 5.4 days. Having a NetScaler Gateway on the inside load balancing the StoreFront servers is far better than using regular load balancing. You get to use HDX Insight Center (which I blogged about when it first came out here “How to use Citrix Netscaler Insight Center to report on web, HDX, and Access Gateway (AGEE) traffic)”. Insight Center has come a long way since it was first released and I can’t imagine not having it now. It let’s you each and every detail of the ICA channels. ICA RTT (round trip time), WAN Latency (client side), and DC Latency (server side) are some of the most important metrics for you to be able to see what the user experience is really like. If you have tons of branch offices that POP out of your primary datacenter where your NetScaler Gateway is, you can now see how each and every user in those branch offices is doing. You can spot a bottleneck or bandwidth issue before it happens.

I also highly suggest enabling the “nstcp_default_xa_xd_profile” TCP profile optimization intended for XenApp and XenDesktop when deploying your NetScaler Gateway. I’ve covered this in the past in my “Mitigating DDoS and brute force attacks against a Citrix Netscaler Access Gateway” article.

DNS
This is critical. You can see in the diagram that external DNS points as the external public IP which in turn points to the external NetScaler Gateway vserver. Internal DNS points at the internal NetScaler Gateway vserver. The TTL on both DNS host records must be set as low as possible. On a Microsoft DNS server, you can get fairly low but on a Linux DNS server, you can get down to seconds if needed. The lower the TTL, the easier it will be for users to transition from the external to internal and back to external NetScaler Gateway. This really depends on the use case. For a company with users with iPads that are very mobile coming in and out of the office all day, this is very critical. For the average company with users coming from home, to work, and going back home, it’s not as big a deal. By the time they get home the TTL will have already expired

Besides the 2 host records, you must have an SRV record both inside and outside for email based discovery in Receiver to work. Email discovery is very important, it makes users not have to memorize a URL. All they need to know is their work email. But keep in mind it will only work with an email address that matches the domain on the SSL you are using for your NetScaler Gateway. So [email protected] will work if your NetScaler Gateway URL is gw.yourdomain.com but if you recently acquired a company and they are still using [email protected], it will not work. So if you plan on doing a lot of acquisitions, it’s better to train your users to know and use the URL.

RECEIVER
Finally we get to the crown jewel. David Coleman (Director of Product Management for Receiver) hails Receiver 4.2 as the best Receiver ever released by Citrix:

http://blogs.citrix.com/2014/12/04/receiver-for-windows-4-2-the-best-ever/

And it really is. For the reasons described in that article as well as one amazing feature that is not. Check out what you can do with SSP now. The self-service.exe plugin is a part of the Receiver install that does several things. It brings so much incredible scripting power with the latest Receiver 4.2. I’m still trying different things with it but you can read all about it here in this CTX article that was released a couple of weeks ago for a good primer. Check out all the available parameters you can use toward the bottom:

http://support.citrix.com/article/CTX200337

I expect Receiver X1 which will be coming very soon to build upon all these capabilities.

SSL CERTIFICATE
A wildcard or SAN cert will work just fine. If you don’t want to pull your hair out, use a wildcard cert first if you already have one just to get the initial setup going. Once you verify your setup is how you want it, go back and replace the wildcard with a SAN cert if your security policy requires it.

NOW LET’S BUILD IT

CONFIGURATION: STOREFRONT
All right, enough theory right? Let’s get to the configuration. Let’s work from the inside outward. First is StoreFront. I’m going to assume you know the basics of StoreFront already.

1. Install StoreFront

2. Install an SSL cert and bind to the Default website in IIS Manager:

3. Create a Base URL. Make sure this is NOT the same URL as you plan on using for your single FQDN/URL for your users. In my example diagram I am using storefront.yourdomain.com for this purpose. You must make sure this does NOT have a DNS record. No user or Receiver should ever be able to resolve this URL. If you ping storefront.yourdomain.com from your PC, it should not resolve:

4. Create a Store. It’s going to be setup for both Internal and External access (the Enable Remote Access option) but we’re not going to set this until we add our NetScaler Gateways first:

5. Add your Delivery Controllers to the Store.

6. Create an External NetScaler Gateway. The callback URL needs to be something that doesn’t exist in DNS just like the base URL above. In this example I use cbext.yourdomain.com. In the SNIP section, don’t put in the SNIP of your external Gateway if it has to go through a firewall or is NATed. It is not documented yet but you can put the vserver IP of your external NetScaler Gateway here and StoreFront will recognize it. Pretty cool, huh?

Create an Internal NetScaler Gateway. Same thing with the callback URL. I call mine cbint.yourdomain.com in the example:

7. Now edit the host file on each of your StoreFront servers with the following:

127.0.0.1 storefront.yourdomain.com
192.168.0.4 cbext.yourdomain.com
10.0.0.3 cbint.yourdomain.com


where cbext is my external virtual server IP and cbint is my internal SNIP.

8. Beacons, don’t worry about them. You don’t need beacons to identify if your users are internal or external since you are using NetScaler Gateway inside and outside using a single FQDN. Point the internal beacon at storefront.yourdomain.com and the external beacon at www.citrix.com if you want. If you really sit and think about it you are treating all your users as external users at all times.

9. Don’t forget to set NetScaler Gateway as an authentication method:

10. Finally go back to your Store and ad both your external and internal NetScaler Gateways. Click Enable Remote Access on your Store. The Default appliance does not matter, I have it set as External in this example:

CONFIGURATION: INTERNAL NETSCALER
I am going to assume you already know how to setup a NetScaler Gateway. The vServer, session profiles/policy, authentication profiles/policy, etc. I have an older article titled “How to setup Citrix Netscaler (Access Gateway) with multiple domains for web browsers and mobile devices” if you need help. Or you can run through the XenDesktop/XenApp wizard in the newest versions of NetScaler firmware.

1. Setup your NetScaler HA pair. Please configure the LOM ports on them. They are so handy to have available in emergencies.

2. Create your NetScaler Gateway vserver. SSL ICA proxy.

3. Create a loadbalanced vserver for your StoreFront servers. Make sure you create this as an SSL Bridge so it uses the SSL cert on the StoreFront servers (passes through):

4. Create a DNS A record on your Netscaler for your storefront.yourdomain.com pointed at the above loadbalanced VIP:

CONFIGURATION: EXTERNAL NETSCALER
1. Setup your NetSclaer HA pair just like you did your internal. Again, LOM port. Takes just 10 min to get setup so do it.

2. Create your NetScaler Gateway vserver. SSL ICA proxy here as well.

3. Create a DNS A record on your Netscaler for your storefront.yourdomain.com pointed at the loadbalanced VIP of your internal NetScaler. This is actually the one and only instance of your external NetScaler talking to your internal NetScaler. Just simple loadbalanced communication. Nothing intelligent that actually wires your 2 sets of NetScalers together.

CONFIGURATION: RECEIVER
Again, the options with this kind of deployment are all interactive for your users:

1. Email discovery or type in the URL:

2. Export provisioning file from StoreFront console:

3. Use the Activate option in Receiver for Web:

Receiver CLI switches will work for component installation but adding a Store won’t work. Example, if you used to do something like this:

It will complete the install but the Store won’t get added properly. You’ll get a message like this:

Your apps are not available at this time. Please try again in a few minutes or contact your help desk with this information: Cannot contact Store.

You have to take out the whole Store part:

I am hoping in future version of Receiver we may be able to add a NetScaler Gateway URL but at this time there is no option for this. And additionally, SSON won’t work. Users will be asked to login when they launch Receiver and you can specify the time out value on the NetScaler Gateway vserver. In my opinion, just keep it simple and don’t complicate things. This type of setup is treating your internal users just like they are external users. And what do external users do? They go to http://www.citrix.com/go/receiver.html and install the Receiver on their home Windows PCs just like they do on their iPads, iPhones, Android devices, etc. So why split the user experience? Just let them do the same exact thing inside that they are already used to doing on the outside. If you want to push Receiver using an Electronic Software Deployment (ESD) system, my suggestion is don’t make it complicated. Do something like this:

This will give them the exact same Receiver experience as they do at home on their personal devices. For most enterprises this is a departure from how they used to do things if they used to slipstream StoreFront/Web Interface URLs into the Receiver package. You need to re-train your users to use email discovery or remember the URL. It is much easier for them to learn a single way of accessing your Citrix environment that is identical both outside and inside the company. It will reinforce the idea they can access their workspace anywhere in the world on any device by remembering a single URL or using their company email address.

For those use cases were SSON is required like a kiosk or certain scenarios I’ve seen in the healthcare industry, point those Receivers at the StoreFront LBVIP to a separate Store. Those should be considered special cases in my opinion. Unless there is a true need for single sign-on, your users should be fine without. Most of the time users only use a handful of apps and if you have your session idle timeout values set right, they can login to Receiver in the morning, launch their apps, and be fine throughout the entire work day without having to touch Receiver again.

One thing not to freak out about. Open Receiver and click your name at the top. Then click Accounts. Then hover over your store. Notice something? It says storefront.yourdomain.com.

Yeah, the one without a DNS record. So how is all this working? It doesn’t even ping!

Don’t worry about it. It’s a purely cosmetic. I assure you that you are using gw.yourdomain.com and it will work both inside and outside the company just fine. Receiver has to pull the base URL and Store URL in StoreFront into Receiver. That’s all this is.

FINAL THOUGHTS

I’ve covered all the pros and cons of using a single URL (single FQDN) for Citrix access using NetScaler Gateway both inside and outside your company. Giving your users a seamless user experience that is easy to use should be your primary focus when you build a solution like this. It may seem complicated at first but if you break it down piece by piece like I have done, it is not very hard at all to get setup.

As always if you have any questions or comments, please leave a comment below. If this article helped you, please leave a comment as well! I enjoy hearing everyone’s experiences.