StoreFront 3.0 and older Config for NetScaler Gateway

Last Modified: Mar 23, 2019 @ 5:04 am

Navigation

Contained on this page are the following topics:

StoreFront Config

  1. See the NetScaler 10.5 page or NetScaler 11 page for instructions on configuring NetScaler Gateway for StoreFront.
  2. In the StoreFront Console, click Authentication on the left. On the right, click Add/Remove Methods.
  3. Check the box next to Pass-through from NetScaler Gateway and click OK.
  4. If you can’t resolve the NetScaler Gateway FQDN from the StoreFront server, edit the C:\Windows\System32\drivers\etc\hosts file and add an entry for the NetScaler Gateway FQDN.

    After configuring the HOSTS file, on the StoreFront server, open a browser and navigate to the DNS name. Make sure the Gateway vServer logon page appears.
  5. In the StoreFront Console, right-click NetScaler Gateway and click Add NetScaler Gateway Appliance.
  6. In the Gateway Settings page, enter a display name. This name appears in Citrix Receiver to make it descriptive. If you have multiple sites, include a geographical name.
  7. Enter the NetScaler Gateway Public URL. The NetScaler Gateway FQDN must be different than the FQDN used for load balancing of StoreFront (unless you are configuring single FQDN). This can be a GSLB-enabled DNS name.
  8. A Subnet IP address is not needed for NetScaler Gateway 10 and newer. However, if the NetScaler Gateway URL is GSLB-enabled then you’ll need to enter the VIP of the NetScaler Gateway Virtual Server so StoreFront can differentiate one NetScaler Gateway from another.
  9. Enter the Callback URL.
    1. In StoreFront 2.6 and newer, the Callback URL is optional. However, SmartAccess requires the Callback URL to be configured.
    2. The callback URL must resolve to any NetScaler Gateway VIP on the same appliance that authenticated the user. For multi-datacenter, edit the HOSTS file on the StoreFront server so it resolves to NetScaler appliances in the same datacenter.
    3. The Callback URL must have a trusted and valid (matches the FQDN) certificate.
    4. The Callback URL must not have client certificates set to Mandatory.
  10. If you have two-factor authentication (LDAP and RADIUS), change the Logon type to Domain and security token. Otherwise leave it set to Domain only.
  11. Click Next.
  12. In the Secure Ticket Authority page, click Add.
  13. Add both of your Controllers. Use http:// or https:// depending on the certificates installed on the Controllers. You can also enter a Load Balancing VIP here. However, you cannot use a Load Balancing VIP when configuring Secure Ticket Authorities on your NetScaler Gateway Virtual Server.
  14. Click Create when done.
  15. Then click Finish.
  16. Click Stores on the left. On the right, click Enable Remote Access.
  17. Select No VPN tunnel.
  18. Check the box next to the NetScaler Gateway object you just created and then click OK.
  19. Then in the StoreFront console, right-click Server Group and click Propagate Changes.

Single FQDN

Docs.citrix.com – Create a single Fully Qualified Domain Name (FQDN) to access a store internally and externally

Traditionally Receiver required separate FQDNs for StoreFront Load Balancing (internal) and NetScaler Gateway (external). Recently Citrix made some code changes to accept a single FQDN for both. This assumes that external users resolve the single FQDN to NetScaler Gateway and internal users resolve the same FQDN to StoreFront Load Balancing.

Single FQDN is fairly new and thus has the following requirements:

  • Receiver for Windows 4.2 or newer
  • Receiver for Mac 11.9 or newer
  • StoreFront 2.6 or newer
  • Split DNS – different DNS resolution for internal vs external
  • NetScaler 10.1 or newer

This section assumes NetScaler Gateway is in ICA Proxy mode. Different instructions are needed for when ICA Proxy is off. See docs.citrix.com for more information.

If you don’t care about email-based discovery then the configuration of Single FQDN is fairly simple. Sample DNS names are used below. Make sure the certificates match the DNS names.

  1. Internal DNS name = the Single FQDN (e.g. storefront.corp.com). Resolves to internal Load Balancing VIP for StoreFront. Set the StoreFront Base URL to this address.
  2. External DNS name = the Single FQDN (e.g. storefront.corp.com). Resolves to public IP, which is NAT’d to NetScaler Gateway VIP on DMZ NetScaler. Set the NetScaler Gateway object in StoreFront to this FQDN.
  3. Auth Callback = any internal DNS name (e.g. storefrontcb.corp.com) that resolves to a NetScaler Gateway VIP on the same DMZ NetScaler appliance that authenticated the user.

    • Auth callback is optional if you don’t need SmartAccess features.
    • The callback DNS name must be different than the Single FQDN.
    • Your external NetScaler Gateway certificate could match both the Single FQDN and the Callback FQDN. Or you can create separate NetScaler Gateway Virtual Servers on the same appliance with separate certificates that match these FQDNs.
  4. Internal Beacon = any internal website URL that is not externally accessible. You can’t use the Single FQDN as the Internal Beacon. Ideally, the Internal Beacon should be a new DNS name that resolves to the StoreFront Load Balancing VIP. However, this requires the StoreFront Load Balancing Virtual Server to have a certificate that matches both the Single FQDN and the Internal Beacon. See CTX218708 How to Configure Internal Beacon for Single FQDN on StoreFront.  💡

    • If are using Receiver for iOS internally then be aware that Receiver for iOS handles the Internal Beacon differently than Receiver for Windows. Receiver for iOS will append /Citrix/Store/discovery to the Internal Beacon and thus it only works if the Internal Beacon DNS name resolves to the StoreFront server. Since you can’t use the StoreFront Base URL as the Internal Beacon you’ll need a different DNS name that resolves to the StoreFront servers and matches the StoreFront certificate. Note: if you are not allowing internal iOS devices then this isn’t needed.
  5. Make sure the DMZ NetScaler resolves the Single FQDN to the internal StoreFront Load Balancing VIP. You typically add internal DNS servers to the NetScaler. Or you can create a local address record for the Single FQDN.
  6. In the NetScaler Gateway Session Profile, set the Web Interface Address and the Account Services Address to the Single FQDN.

If you need email-based discovery then here’s an example configuration for ICA Proxy NetScaler Gateway:

  • External DNS:
    • Storefront.corp.com resolves to public IP, which is NAT’d to NetScaler Gateway VIP on DMZ NetScaler.
    • If email-based discovery, SRV record for _citrixreceiver._tcp.email.suffix points to StoreFront.corp.com.
  • External publicly-signed certificate for NetScaler Gateway:
    • One option is wildcard for *.corp.com. Assumes email suffix is also corp.com.
    • Another option is the following Subject Alternative Names:
      • Storefront.corp.com
      • StorefrontCB.corp.com – for callback URL. Only accessed from internal.
        • Or you can create a separate Gateway vServer for callback with a separate certificate.
      • If email-based discovery, discoverReceiver.email.suffix
  • Internal DNS:
    • Storefront.corp.com resolves to Load Balancing VIP for StoreFront
    • StoreFrontCB.corp.com – resolves to NetScaler Gateway VIP on DMZ NetScaler. For authentication callback.
    • For the internal beacon, FQDN of any internal web server. Make sure this name is not resolvable externally.
    • If email-based discovery, SRV record for _citrixreceiver._tcp.email.suffix points to StoreFront.corp.com.
  • Internal certificate for StoreFront Load Balancing: publicly-signed recommended, especially for mobile devices and thin clients. Also can use the external certificate.
    • One option is wildcard for *.corp.com. Assumes email suffix is also corp.com.
    • Another option is the following Subject Alternative Names:
      • Storefront.corp.com
      • If email-based discovery, discoverReceiver.email.suffix

StoreFront Configuration:

  • Base URL = https://storefront.corp.com
  • Internal beacon = FQDN of internal web server. Make sure it’s not resolvable externally.
  • Gateway object:
    • Gateway URL = https://storefront.corp.com
    • Callback URL = https://storefrontcb.corp.com

Receiver for Web session policy (basic mode or ICA Only is checked):

  • Policy expression = REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver
  • Client Experience tab:
    • Home page = https://storefront.corp.com/Citrix/StoreWeb
    • Session Timeout = 60 minutes
    • Clientless Access = Off
    • Clientless Access URL Encoding = Clear
    • Clientless Access Persistent Cookie = Deny
    • Plug-in Type = Windows/Mac OS X
    • Single Sign-on to Web Applications = checked
  • Security tab:
    • Default authorization = ALLOW
  • Published Applications tab:
    • ICA Proxy = On
    • Web Interface address = https://storefront.corp.com/Citrix/StoreWeb
    • Web Interface Portal Mode = Normal
    • Single Sign-on Domain = Corp

Receiver Self-Service session policy (basic mode or ICA Only is checked):

      • Policy expression = REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver
      • Client Experience tab:
        • Session Timeout = 60 minutes
        • Clientless Access = Off
        • Clientless Access URL Encoding = Clear
        • Clientless Access Persistent Cookie = Deny
        • Plug-in Type = Java
      • Security tab:
        • Default authorization = ALLOW
      • Published Applications tab:
        • ICA Proxy = On
        • Web Interface address = https://storefront.corp.com
        • Web Interface Portal Mode = Normal
        • Single Sign-on Domain = Corp
        • Account Services address = https://storefront.corp.com

Multiple Datacenters / Farms

If you have StoreFront (and NetScaler Gateway) in multiple datacenters, GSLB is typically used for the initial user connection but GSLB doesn’t provide much control over which datacenter a user initially reaches. So the ultimate datacenter routing logic must be performed by StoreFront. Once the user is connected to StoreFront in any datacenter, StoreFront looks up the user’s Active Directory group membership and gives the user icons from multiple farms in multiple datacenters and can aggregate identical icons based on farm priority order. When the user clicks on one of the icons, Optimal Gateway directs the ICA connection through the NetScaler Gateway that is closest to the destination VDA. Optimal Gateway requires datacenter-specific DNS names for NetScaler Gateway.

Docs.citrix.com Set up highly available multi-site store configurations explains configuring XML files on StoreFront to aggregate identical icons from multiple farms/sites. Identical Icons are aggregated in farm priority order or load balanced across multiple farms. To specify a user’s “home” datacenter, configure different farm priority orders for different Active Directory user groups.

Shaun Ritchie Citrix StoreFront High Availability and Aggregation – A dual site Active Active design has a sample multi-site configuration using XML Notepad and explains how to use the Primary and Secondary keywords to override farm priority order.

Citrix Blogs StoreFront Multi-Site Settings: Some Examples has example XML configurations for various multi-datacenter Load Balancing and failover scenarios.

When Citrix Receiver switches between StoreFront servers in multiple datacenters, it’s possible for each datacenter to be treated as a separate Receiver site. This can be prevented by doing the following. From Juan Zevallos at Citrix Discussions: To have multiple StoreFront deployments across a GSLB deployment, here are the StoreFront requirements:

  • Match the SRID – in StoreFront, if you use the same BaseURL in the 2 separate installations, then the SRID should end up being identical. If the BaseURL is changed after the initial setup, the SRID doesn’t change. The SRID can be safely edited in the \inetpub\wwwroot\Citrix\Roaming\web.config file. It will be replicated into the discovery servicerecord entry in the Store web.config which can be edited as well or refreshed from the admin console by going into Remote Access setup for the store and hitting OK. Make sure to propagate changes to other servers in the group.
  • Match the BaseURL
  • Match the Delivery Controller names under “Manage Delivery Controllers” – The XML brokers can be different, but the actual name of the Delivery Controller/Farm must be identical. Here’s the exact setting I’m referring to: https://citrix.sharefile.com/d/sa562ba140be4462b

If you are running XenApp / XenDesktop in multiple datacenters, you must design roaming profiles and home directories correctly.

Optimal Gateway

The Optimal Gateway feature lets you override the NetScaler Gateway used for ICA connections. Here are some scenarios where this would be useful:

  • The NetScaler Gateway Virtual Server requires user certificates. If ICA traffic goes through this Virtual Server then each application launch will result in a certificate prompt. Use Optimal Gateway to force ICA connections through a different NetScaler Gateway Virtual Server that doesn’t have certificate authentication enabled. Note: Callback URL also cannot use a NetScaler Gateway Virtual Server where client certificates are set to Mandatory.
  • Multi-site Load Balancing. If the icon selected by the user is published from XenApp/XenDesktop in Datacenter A, then you probably want the ICA connection to go through a NetScaler Gateway Virtual Server in Datacenter A. This requires separate NetScaler Gateway DNS names for each datacenter. Also, Optimal Gateway is applied at the farm/site level so if you are stretching a farm across datacenters then Optimal Gateway won’t help you.
  • NetScaler Gateway for internal connections (AppFlow). If you want to force internal users to go through NetScaler Gateway so AppFlow data can be sent to Citrix Insight Center then you can do that using Optimal Gateway even if the user originally connected directly to the StoreFront server. See How to Force Connections through NetScaler Gateway Using Optimal Gateways Feature of StoreFront for more information.

Optimal Gateway is configured by editing the StoreFront Store’s web.config file. See Docs.citrix.com: To configure optimal NetScaler Gateway routing for a store. For an example configuration see Docs.citrix.com: Examples of highly available multi-site store configurations.

Optimal Gateway works great if you have separate XenDesktop sites/farms in each datacenter. However, for those of you with a central XenDesktop site running globally dispersed VDAs and a NetScaler Gateway in each location, or a single globally distributed XenApp farm (which I know an awful lot of you still have), see the Citrix blog post – How to direct remote XenApp/XenDesktop users based on active directory group membership:

    1. On a Load Balancing NetScaler, create multiple StoreFront load balancers. Each has a unique Net Profile with a unique SNIP.
    2. On StoreFront, create multiple Gateway objects, each with a SNIP that matches the Net Profiles created on the load balancer. Each Gateway object has a datacenter-specific Gateway FQDN.
    3. On each NetScaler Gateway:
      1. Configuration LDAP group extraction.
      2. Create a session policy for each datacenter pointing to the one of the StoreFront Load Balancers.
      3. Create AAA groups and bind the session policies.

Gateway in Closest Datacenter

Citrix Blog post ‘Accurately’ Direct XenApp/XenDesktop Users to a Correct Location Based Datacenter:

  • An unsupported extension to StoreFront
  • Read’s the client’s IP and looks it up in a location database (GeoLite2) to determine the user’s closest datacenter
  • Adjusts the Gateway FQDN in the rendered .ica file to direct users to the closest datacenter.
  • Requires datacenter-specific or region-specific Gateway DNS names.
  • Every NetScaler Gateway should know about every potential Secure Ticket Authority server.

Multiple Gateways to One StoreFront

If you have multiple NetScaler Gateways connecting to one StoreFront Server Group, and if each of the NetScaler Gateways uses the same DNS name (GSLB), then you will need some other method of distinguishing one appliance from the other so the callback goes to the correct appliance.

  • In the StoreFront console, create multiple NetScaler Gateway appliances, one for each datacenter. Give each of them unique names.
  • Enter the same NetScaler Gateway URL in all of the gateway appliances. Since all of the appliances use the same DNS name, you cannot use the DNS name to distinguish them.
  • Each appliance has a different NetScaler Gateway VIP. This VIP can be entered in the Subnet IP field. StoreFront will use this VIP to distinguish one appliance from another. The field label is SNIP but we actually need to enter a VIP.
  • The callback URL must be unique for each Gateway appliance. The callback URL must resolve to a NetScaler Gateway VIP on the same appliance that authenticated the user. Create new datacenter-specific DNS names. For example: gateway-prod.corp.com and gateway-dr.corp.com.
  • The datacenter-specific DNS name must match the certificate on the NetScaler Gateway Virtual Server. Here are some options to handle the certificate requirement:
    • On the main NetScaler Gateway Virtual Server, assign a wildcard certificate that matches both the GSLB name and the datacenter-specific name.
    • On the main NetScaler Gateway Virtual Server, assign an SSL certificate with Subject Alternative Names for both the GSLB name and the datacenter-specific name.
    • Create an additional NetScaler Gateway Virtual Server on the appliance. Bind a certificate that matches the datacenter-specific name.
  • Configure name resolution for the datacenter-specific NetScaler Gateway DNS names. Either edit the HOSTS file on the StoreFront servers or add DNS records to your DNS servers.
  • When enabling Remote Access on the store, select both Gateway appliances. Select one as the default appliance.

Related Pages

Additional StoreFront Configuration

NetScaler 10.5

Session Policies for StoreFront – NetScaler Gateway 10.5

Last Modified: Sep 2, 2018 @ 7:38 am

Navigation

This page details creation of session profiles and policies for NetScaler Gateway 10.5 where ICA Only (formerly known as Basic Mode) is checked.

Partly based on Citrix Knowledgebase Article – How to Configure NetScaler Gateway with StoreFront

Session Profiles/Policies CLI Commands

The CLI commands are shown below:

add vpn sessionAction "Receiver Self-Service" -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://storefront.corp.com" -ntDomain Corp -clientlessVpnMode OFF -storefronturl "https://storefront.corp.com"

add vpn sessionAction "Receiver for Web" -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://storefront.corp.com/Citrix/StoreWeb" -ntDomain Corp -clientlessVpnMode OFF

add vpn sessionPolicy "Receiver Self-Service" "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" "Receiver Self-Service"

add vpn sessionPolicy "Receiver for Web" "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" "Receiver for Web"

Session Profiles

Or use the GUI to create the policies/profiles:

  1. On the left, expand NetScaler Gateway, expand Policies, and click Session.
  2. On the right, switch to the Session Profiles tab, and click Add.
  3. Name the first one ReceiverSelfService or similar. This is for Receiver Self-Service (not in a web browser).
  4. Switch to the Client Experience tab.
  5. Check the Override Global box next to Clientless Access, and set it to Allow. Scroll down.
  6. Check the Override Global box next to Plug-in Type and set it to Java.
  7. Check the Override Global box next to Single Sign-on to Web Applications and enable it. Scroll up.
  8. If you need two-factor authentication, the session policy for Receiver Self-Service needs to be adjusted to indicate which authentication field contains the Active Directory password. On the Client Experience tab is Credential Index. This needs to be changed to SECONDARY. Leave the session policy for Web Browsers set to PRIMARY.
  9. On the Security tab, check the Override Global box next to Default Authorization Action and set it to Allow.
  10. On the Published Applications tab, check the Override Global box next to ICA Proxy and set it to ON.
  11. Check the Override Global box next to Web Interface Address, and enter the load balanced URL to the StoreFront servers. You can use an IP address. Don’t add any path to the end of the URL.
  12. If you only have one domain, then check the Override Global box next to Single Sign-on Domain and enter the name of your Active Directory domain. StoreFront needs to accept this domain name (Configure Trusted Domains).
  13. If you have multiple domains, then leave Single Sign-on Domain field blank, and ensure the LDAP authentication servers have userPrincipalName in the SSO Name Attribute field.
  14. For Account Services Address, enter the Base URL for StoreFront. NetScaler needs to be able to resolve this DNS name.
  15. Click Create.
  16. Highlight the existing session profile, and click Add. This copies the settings from the existing profile into the new one.
  17. Change the name of the second Session Profile to ReceiverForWeb or similar.
  18. On the Client Experience tab, Clientless Access should be set to Allow. Scroll down.
  19. Plug-in Type should still be set to Java.
  20. Single Sign-on to Web Applications should be enabled.
  21. If you need two-factor authentication, the session policy for Receiver for Web needs Credential Index set to PRIMARY. Only the Receiver Self-Service policy needs SECONDARY as detailed earlier.
  22. On the Security tab, the Default Authorization Action should still be Allow.
  23. On the Published Applications page, for the Web Interface Address field, add the path to your Receiver for Web site (e.g. /Citrix/StoreWeb).
  24. Everything else should be the same. If you only have one domain, then check the Override Global box next to Single Sign-on Domain and enter the NetBIOS name of your Active Directory domain. If you have multiple domains, then leave this field blank and ensure the LDAP authentication servers have userPrincipalName in the SSO Attribute field.
  25. Account Services Address is not needed in this profile but there’s no harm in leaving it.
  26. Click Create.

Session Policies

  1. On the right, switch to the Session Policies tab, and click Add.
  2. Name the Policy ReceiverSelfService or similar.
  3. Change the Request Profile to ReceiverSelfService.
  4. In the Expression box, either type the following, or use the Expression Editor link to build the following expression:
    REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver

  5. Then click Create.
  6. Add another policy, and name it ReceiverForWeb or similar.
  7. Change the Action to ReceiverForWeb.
  8. In the Expression box, either type in the following, or use the Expression Editor. It’s the same as the previous expression, except it’s NOTCONTAINS instead of CONTAINS.
    REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver
  9. Click Create.

Next Step

Create NetScaler Gateway Virtual Server

StoreFront Load Balancing – NetScaler 10.5

Last Modified: Jan 4, 2019 @ 7:54 am

Navigation

Monitor

Note: This is a Perl monitor, which uses the NSIP as the source IP.

  1. On the left, expand Traffic Management, expand Load Balancing, and click Monitors.
  2. On the right, click Add.
  3. Name it StoreFront or similar.
  4. Change the Type drop-down to STOREFRONT.
  5. If you will use SSL to communicate with the StoreFront servers, then scroll down, and check the box next to Secure.
  6. Scroll up, and switch to the Special Parameters tab.
  7. In the Store Name field, enter the name of your store (e.g. Store).
  8. The other two checkboxes are not working with StoreFront 2.6. Click Create.

    add lb monitor StoreFront STOREFRONT -scriptName nssf.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -secure YES -storename Store

Servers

  1. On the left, expand Traffic Management, expand Load Balancing, and click Servers.
  2. On the right, click Add.
  3. Enter a descriptive server name, usually it matches the actual server name.
  4. Enter the IP address of the server.
  5. Enter comments to describe the server. Click Create.
  6. Continue adding StoreFront servers.

    add server SF01 10.2.2.57
    add server SF02 10.2.2.58

Service Group

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.

  2. On the right, click Add.
  3. Give the Service Group a descriptive name (e.g. svcgrp-StoreFront-SSL).
  4. Change the Protocol to HTTP or SSL. If the protocol is SSL, ensure that StoreFront Monitor has Secure checked.
  5. Scroll down and click OK.
  6. On the right, under Advanced, click Members.
  7. Click where it says No Service Group Member.
  8. If you did not create server objects, then enter the IP address of a StoreFront Server. If you previously created a server object then change the selection to Server Based and select the server objects.
  9. Enter 80 or 443 as the port. Then click Create.

  10. To add more members, click where it says 1 Service Group Member and then click Add. Click Close when done.

  11. On the right, under Advanced, click Monitors.
  12. Click where it says No Service Group to Monitor Binding.
  13. Click the arrow next to Click to select.
  14. Select your StoreFront monitor, and click OK.
  15. Then click Bind.
  16. To verify that the monitor is working, on the left, in the Service Group Members section, click the Service Group Members line.
  17. Highlight a member, and click Monitor Details.
  18. The Last Reponse should be Success – Probe succeeded. Click Close twice.
  19. On the right, under Advanced, click Settings.
  20. Check the box for Client IP and enter X-Forwarded-For as the Header. Then click OK.
  21. Then click Done.

    add serviceGroup svcgrp-StoreFront-SSL SSL -maxClient 0 -maxReq 0 -cip ENABLED X-Forwarded-For
    
    bind serviceGroup svcgrp-StoreFront-SSL SF01 443
    bind serviceGroup svcgrp-StoreFront-SSL SF02 443
    bind serviceGroup svcgrp-StoreFront-SSL -monitorName StoreFront
  22. If the Service Group is http and you don’t have certificates installed on your StoreFront servers (aka SSL Offload), then you’ll need to enable loopback in StoreFront:
    1. In StoreFront 3.5, you enable it in the GUI console.
    2. In StoreFront 3.0, run the following commands on the StoreFront 3.0 servers as detailed at Citrix Blog Post What’s New in StoreFront 3.0.
      & "C:\Program Files\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1"
      
      Set-DSLoopback -SiteId 1 -VirtualPath /Citrix/StoreWeb -Loopback OnUsingHttp

Load Balancing Virtual Server

  1. Create or install a certificate that will be used by the SSL Offload Virtual Server. This certificate must match the DNS name for the load balanced StoreFront servers. For email discovery in Citrix Receiver, the certificate must either be a wildcard (*.corp.local) or have a subject alternative name for discoverReceiver.domain.com (domain.com = email address suffix)
  2. On the left, under Traffic Management > Load Balancing, click Virtual Servers.

  3. On the right click Add.
  4. Name it lbvip-StoreFront-SSL or similar.
  5. Change the Protocol to SSL.
  6. Specify a new internal VIP.
  7. Enter 443 as the Port.
  8. Click OK.

    add lb vserver lbvip-StoreFront-SSL SSL 10.2.2.221 443 -persistenceType SOURCEIP -timeout 60
  9. On the left, in the Services and Service Groups section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.
  10. Click the arrow next to Click to select.
  11. Select your StoreFront Service Group, and click OK.
  12. Click Bind.

    bind lb vserver lbvip-StoreFront-SSL svcgrp-StoreFront-SSL
  13. Click OK.
  14. Click where it says No Server Certificate.
  15. Click the arrow next to Click to select.
  16. Select the certificate for this StoreFront Load Balancing Virtual Server, and click OK.
  17. Click Bind.

    bind ssl vserver lbvip-StoreFront-SSL -certkeyName WildCorpCom
  18. On the right, in the Advanced column, click Persistence.
  19. On the left, in the Persistence section, select SOURCEIP.  Do NOT use COOKIEINSERT persistence or Android devices will not function correctly.
  20. Set the timeout to match the timeout of Receiver for Web.
  21. The IPv4 Netmask should default to 32 bits.
  22. Click OK.
  23. On the right, in the Advanced column, click SSL Parameters.
  24. If the NetScaler communicates with the StoreFront servers using HTTP (aka SSL Offload), at the top right, check the box next to SSL Redirect. Otherwise the Receiver for Web page will never display.
  25. Uncheck the box next to SSLv3.
    set ssl vserver lbvip-StoreFront-SSL -sslRedirect ENABLED -ssl3 DISABLED
  26. NetScaler VPX 10.5 build 57 and newer lets you enable TLSv11 and TLSv12. Click OK.
  27. Perform other normal SSL vServer configuration including: disable SSLv3, bind a Modern Cipher Group, and enable Strict Transport Security.
    bind ssl vserver lbvip-StoreFront-SSL -certkeyName MyCert
    
    set ssl vserver lbvip-StoreFront-SSL -ssl3 DISABLED -tls11 ENABLED -tls12 ENABLED
    
    unbind ssl vserver lbvip-StoreFront-SSL -cipherName ALL
    
    bind ssl vserver lbvip-StoreFront-SSL -cipherName Modern
    
    bind ssl vserver lbvip-StoreFront-SSL -eccCurveName ALL
    
    bind lb vserver lbvip-StoreFront-SSL -policyName insert_STS_header -priority 100 -gotoPriorityExpression END -type RESPONSE
  28. Then click Done.

SSL Redirect – Down vServer Method

If you created an SSL Offload Virtual Server that only listens on SSL 443, users must enter https:// when navigating to the website. To make it easier for the users, create another load balancing Virtual Server on the same VIP that listens on HTTP 80 and then redirects the user’s browser to reconnect on SSL 443.

This procedure details the Down vServer method of performing an SSL redirect. An alternative is to use the Responder method.

  1. On the left, under Traffic Management > Load Balancing, click Virtual Servers.

  2. On the right, find the SSL Virtual Server you’ve already created, right-click it, and click Add. Doing it this way copies some of the data from the already created Virtual Server.
  3. Change the name to indicate that this new Virtual Server is an SSL Redirect.
  4. Change the Protocol to HTTP on Port 80.
  5. The IP Address should already be filled in. It must match the original SSL Virtual Server.
  6. Click OK.
  7. Don’t select any services. This vServer must intentionally be marked down so the redirect will take effect. Click Continue.
  8. On the right, in the Advanced column, click Protection.
  9. In the Redirect URL field, enter the full URL including https://. For example: https://storefront.company.com/Citrix/StoreWeb. Click OK.
  10. Click Done.

    add lb vserver lbvip-storefront-HTTP-SSLRedirect HTTP 10.2.2.201 80 -redirectURL "https://storefront.corp.com"
  11. When you view the SSL redirect Virtual Server in the list, it will have a state of DOWN. That’s OK. The Port 80 Virtual Server must be DOWN for the redirect to work.

StoreFront Base URL

  1. Create a DNS Host record that resolves to the new VIP.
  2. The DNS name for StoreFront load balancing must be different than the DNS name for NetScaler Gateway. Unless you are following the Single FQDN procedure.

  3. In the Citrix StoreFront console, right-click Server Group and click Change Base URL.
  4. Enter the new Base URL in https://storefront.corp.com format. This must match the certificate that is installed on the load balancer. Click OK.

Subscription Replication Load Balancing

If you have multiple StoreFront clusters (separate datacenters), you might want to replicate subscriptions between them. StoreFront subscription replication uses TCP port 808. To provide High Availability for this service, load balance TCP port 808 on the StoreFront servers. See Configure subscription synchronization at Citrix Docs for more information.

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.

  2. On the right, click Add.
  3. Give the Service Group a descriptive name (e.g. svcgrp-StoreFront-SubRepl).
  4. Change the Protocol to TCP.
  5. Scroll down and click OK.
  6. On the right, under Advanced, click Members.
  7. Click where it says No Service Group Member.
  8. In the IP Address field, enter the IP address of a back-end StoreFront server.
  9. Enter 808 as the port. Then click Create.

  10. To add more members,  on the left, in the Service Group Members section, click where it says 1 Service Group Member.
  11. Click Add to add a member. Click Close when done.
  12. On the right, under Advanced, click Monitors.
  13. Click where it says No Service Group to Monitor Binding.
  14. Click the arrow next to Click to select.
  15. Select the tcp monitor, and click OK.
  16. Then click Bind, and click Done.

    add serviceGroup svcgrp-StoreFront-FavRepl TCP
    bind serviceGroup svcgrp-StoreFront-FavRepl SF01 808
    bind serviceGroup svcgrp-StoreFront-FavRepl SF02 808
  17. On the left, under Traffic Management > Load Balancing, click Virtual Servers.

  18. On the right click Add.
  19. Name it lbvip-StoreFront-SubRepl or similar.
  20. Change the Protocol to TCP.
  21. Specify the same VIP that you used for SSL Load Balancing of StoreFront.
  22. Enter 808 as the Port.
  23. Click Continue.
  24. Click where it says No Load Balancing Virtual Server ServiceGroup Binding.
  25. Click the arrow next to Click to select.
  26. Select your StoreFront Subscription Replication Service Group, and click OK.
  27. Click Bind.
  28. Click OK.
  29. On the right, in the Advanced column, click Persistence.
  30. Select SOURCEIP persistence.
  31. Set the timeout to 5 minutes.
  32. The IPv4 Netmask should default to 32 bits.
  33. Click OK.
  34. Then click Done.

    add lb vserver lbvip-StoreFront-FavRepl TCP 10.2.2.201 808 -persistenceType SOURCEIP -timeout 5
    
    bind lb vserver lbvip-StoreFront-FavRepl svcgrp-SF-FavRepl

Related Posts