Another approach to a unified FQDN for storefront and NetScaler Gateway

8:39 PM
Another approach to a unified FQDN for storefront and NetScaler Gateway -

How users can be made to use a single URL, while still maintaining a storefront to have the base URL that is of the NetScaler Gateway URL differently? We will show you.

Please note this solution best for Receiver for Web works. This solution with the native receiver working, but the provisioning file, the easiest way to configure the Native receiver in my opinion.

would in this scenario, I'll connect.example.com for external access to the use Citrix environment. Int-connect.example.com will be used for internal access to the Citrix environment

Here is an overview of the requirements for the scenario :.

  1. SAN certificate for int-connect.example.com and connect.example.com.
  2. Connect.example.com will resolve to the public NetScaler Gateway VIPs.
  3. Int-connect.example.com will solve the internal Storefront load balancing VIPs.
  4. CNAME on the internal DNS. connect.example.com - ..> int-connect.example.com
  5. redirect
  6. Responder policy connect.example.com to int-connect.example.com

to provide now for the magic of each FQDN that users need to know.

In this example, the "single URL" for users is is connect.example .com. On the internal DNS infrastructure, you create a CNAME for connect.example.com to show to int-connect.example.com. Then, on the NetScaler appliance, create a Responder policy that redirects the traffic to the HTTP host header of "connect.example.com" on "int-connect.example.com". Bind this Directive on the facade LB VIP on NetScaler.

So what is the expected usage patterns?

A user on the internal network types connect.example.com in their browser. Connect.example.com solves a CNAME for int-connect.example.com. The user will solve int-connect.example.com. the IP address for int-connect.example.com the user connects to the SF LB VIP with the IP address and the HTTP host header connect.example.com Following receipt. The responder policy redirects the user to int-connect.example.com. The user's browser follows the redirect and is capable of the facade LB VIP access. a SAN certificate with the name The use we need, the user will receive a certificate warning.

Single FQDN Diagram

The workflow is up seamlessly with the internal subscriber. In their view, give internal users connect.example.com, and brings them to the resources they need to focus their work. External users use connect.example.com for their connection through an external view of NetScaler Gateway VIP proxied be.

Please note that this workflow is unique for web receiver. users that need to manually configure the receiver on the internal network "int-connect.example.com" Enter to connect the facade VIP and avoid diversion. I recommend the provisioning file from StoreFront with the native receiver to configure.

Let me know in the comments below if you have questions!

Brooks

Previous
Next Post »
0 Komentar