ICA Proxy (StoreFront) – Citrix Gateway

Last Modified: Apr 30, 2024 @ 10:22 am

131 Comments

This article applies to Citrix Gateway 13.x, Citrix Gateway 12.1, and NetScaler Gateway 12.0. Citrix ADC is the new name for NetScaler. Citrix Gateway is the new name for NetScaler Gateway.

Navigation

💡 = Recently Updated

Change Log

Overview

Here’s a high level overview of internal connectivity from client devices to Citrix Virtual Apps and Desktops (CVAD):

  1. HTTP connection to Citrix StoreFront:
    • Authentication to StoreFront
    • User interface that displays a list Citrix published icons
  2. ICA connection directly to a Citrix Virtual Delivery Agent (VDA)
    • ICA is a display protocol similar to RDP protocol

Citrix Gateway has an ICA Proxy feature that authenticates the user, proxies HTTP traffic to StoreFront, and then proxies ICA traffic to VDAs.

  • ICA Proxy is just one of the features that Citrix Gateway supports. Other Gateway features include: SSL VPN, Unified Gateway, RDP Proxy, PCoIP Proxy, etc.
  • ICA Proxy only exposes a single IP address to the user. All communication from all external Citrix clients to all internal StoreFront servers and all internal VDAs is proxied through the one IP address.
    • The “single IP address” feature is also sometimes useful internally, especially if there’s any Network Address Translation between internal subnets, or if the Citrix VDAs are protected behind an internal firewall.
  • Citrix Gateway supports many different authentication methods, including: LDAP, RADIUS, SAML, OpenID Connect, nFactor, Client Certificates (Smart Cards), etc.
    • Citrix Gateway has more authentication options than StoreFront. Sometimes Citrix Gateway is deployed in front of StoreFront just for the additional authentication options that Citrix Gateway provides.
  • Both HTTP and ICA are proxied through a single TLS-encrypted port 443. ICA Proxy decrypts the traffic and inspects it.
    • If the traffic is HTTP protocol, then ICA Proxy forwards it to Citrix StoreFront. The address of the StoreFront server is defined in a Session Policy/Profile on the Published Applications tab.
    • If the traffic is ICA protocol, then ICA Proxy uses a Secure Ticket Authority (STA) server to authenticate the connection, and then forwards the unencrypted ICA traffic to the VDA.
    • DTLS-encrypted (UDP) port 443 is also an option – UDP protocol for ICA traffic performs better than TCP on high latency links

There are two user interface options for connecting to Citrix Virtual Apps and Desktops (CVAD). Both user interface options rely on a connection to StoreFront. ICA Proxy is configured differently for each user interface.

  • Web Browser – Chrome, Safari, etc. connecting to the Receiver for Web website hosted on Citrix StoreFront.
  • Receiver Self-Service – native user interface built into Workspace app that connects to an XML-based API hosted on Citrix StoreFront.
    • In all operating systems, Receiver Self-Service is the user interface that opens when you launch Receiver or Workspace app from the app launcher.
    • In Windows, Receiver Self-Service is the user interface that you can open from the Receiver / Workspace app systray icon.
    • In Windows, Receiver Self-Service can download icons from StoreFront and put the icons on the client device’s app launcher (Start Menu and/or Desktop) without needing to actually open the Receiver Self-Service window.

Links:

Session Profiles

Partly based on Citrix Docs Configure Citrix Gateway Session Policies for StoreFront.

To create Session Profiles/Policies for ICA Proxy (StoreFront):

  1. On the left, expand Citrix Gateway, expand Policies, and click Session.
  2. On the right, switch to the Session Profiles tab, and click Add.

    1. Name the first one Receiver Self Service or similar. This is for the Receiver Self-Service interface (not from a web browser).
    2. Switch to the Client Experience tab.
    3. On the Client Experience tab, check the Override Global box next to Clientless Access, and set it to Off. Scroll down.
    4. Check the Override Global box next to Plug-in Type, and set it to Java.
    5. Check the Override Global box next to Single Sign-on to Web Applications and enable it. Scroll up.

      • If you need two-factor authentication (RADIUS) using classic Authentication Policies (not nFactor, not AAA vServer), 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. Only change this in the Receiver Self-Service profile; leave the session profile for Web Browsers set to PRIMARY.
    6. Scroll up and switch to the Security tab.
    7. Check the Override Global box next to Default Authorization Action, and set it to Allow.
    8. Switch to the Published Applications tab.
    9. Check the Override Global box next to ICA Proxy, and set it to ON.
    10. Check the Override Global box next to Web Interface Address, and enter the load balanced URL (FQDN) to the StoreFront servers. You can use an IP address instead of FQDN. Don’t add any path to the end of the URL.
    11. 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. Enter the same domain name that’s configured in StoreFront’s Configure Trusted Domains.

    12. For Account Services Address, enter the Base URL for StoreFront. Citrix Gateway needs to be able to resolve this FQDN’s DNS name.
    13. Click Create.
  3. Right-click the just-added session profile, and click Add. This copies the settings from the existing profile into the new one.

    1. Change the name of the second Session Profile to Receiver For Web or similar.
    2. Switch to the Client Experience tab.
    3. On the Client Experience tab, Clientless Access should be set to Off. Scroll down.
    4. Plug-in Type should still be set to Java.
    5. Single Sign-on to Web Applications should be enabled.

      • If you need two-factor authentication using Classic authentication policies (not nFactor, not AAA vServer), the session profile for Receiver for Web needs Credential Index set to PRIMARY. Only the Receiver Self-Service policy needs SECONDARY as detailed earlier.
    6. Scroll up and switch to the Security tab.
    7. The Default Authorization Action should still be Allow.
    8. Switch to the Published Applications tab.
    9. For the Web Interface Address field, add the path to your Receiver for Web site (e.g. /Citrix/StoreWeb).
    10. 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 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 Name Attribute field.
    11. Account Services Address is not needed in this profile but there’s no harm in leaving it.
    12. Click Create.
  4. On the right, switch to the Session Policies tab, and click Add.

    1. Name the Policy Receiver Self Service or similar.
    2. Change the Profile to Receiver Self Service.
    3. In the Expression box, type in the following expression: 
      HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver")
    4. Then click Create.
  5. Right-click on the just-added Session Policy, and click Add.

    1. Change the name to Receiver For Web or similar.
    2. Change the Profile to Receiver For Web.
    3. In the Expression box, either type in the following, or use the Expression Editor. It’s the same as the Receiver Self-Service expression, except it has .NOT on the end. 
      HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver").NOT
    4. Click Create.

The CLI commands for these Session Policies/Profiles are shown below:

add vpn sessionAction "Receiver Self-Service" -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://storefront.corp.com" -ntDomain Corp.local -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.local -clientlessVpnMode OFF

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

add vpn sessionPolicy "Receiver for Web" "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"CitrixReceiver\").NOT" "Receiver for Web"

Traffic Policy

In Citrix ADC 13.0 build 64.35, the SSO option in Session Policy/Profile no longer sends credentials to StoreFront. To work around this issue, add a Traffic Policy that enables SSO. See Enable SSO for Basic, Digest, and NTLM authentication at Citrix Docs. Citrix says that this won’t be necessary for StoreFront on newer builds of ADC 13.0.

  1. On the left, expand Citrix Gateway, expand Policies and click Traffic.
  2. On the right, switch to the tab named Traffic Profiles.
  3. Click Add.
  4. Name it something similar to StoreFrontSSO.
  5. Change the setting for Single Sign-on to ON. This is the only setting we need.
  6. At the bottom, click Create.
  7. On the right, switch to the tab named Traffic Policies.
  8. Click Add.
  9. Name it something similar to StoreFrontSSO.
  10. Select the Request Profile (aka Traffic Profile) you created earlier.
  11. In the Expression box, enter true. This assumes you are doing Advanced (Default) syntax policies.
  12. Click Create.

  13. See the next section to bind the Traffic Policy to the Gateway Virtual Server.

The CLI commands to create the Traffic Policy for StoreFront Single Sign-on are shown below:

add vpn trafficAction StoreFrontSSO http -SSO ON
add vpn trafficPolicy StoreFrontSSO true StoreFrontSSO
# or for full VPN:
add vpn trafficPolicy StoreFrontSSO "HTTP.REQ.METHOD.EQ(post) || HTTP.REQ.METHOD.EQ(get) && false" StoreFrontSSO

Citrix Gateway Virtual Server

This section assumes LDAP authentication, with optional RADIUS for two-factor. Create the Authentication Policies before beginning this section.

  • You can configure StoreFrontAuth as an alternative to LDAP. StoreFrontAuth delegates authentication to StoreFront servers, instead of performing authentication on Citrix Gateway.
  • For other forms of authentication, see the Authentication section in the Citrix ADC menu page.

To create the Citrix Gateway Virtual Server for ICA Proxy and StoreFront:

  1. At Traffic Management > SSL > Certificates > Server Certificates, Create a Server Certificate for the Citrix Gateway Virtual Server. The certificate must match the DNS name users will enter to access the Citrix Gateway.

    • For email discovery in Citrix Receiver / Workspace app, the certificate must have subject alternative names (SAN) for discoverReceiver.email.suffix (use your email suffix domain name). If you have multiple email domains then you’ll need a Subject Alternative Name for each suffix.
  2. Link the certificate to the Intermediate CA certificate. Do not link the Intermediate CA certificate to the Root CA certificate.
  3. On the left, right-click the Citrix Gateway node, and click Enable Feature.
  4. On the left, expand Citrix Gateway, and click Virtual Servers.
  5. On the right, click Add.
  6. Name it gateway.corp.com or similar.
  7. Enter a new VIP that will be exposed to the Internet (typically through NAT).
  8. Click More.

    1. If you don’t have enough Citrix Gateway Universal licenses installed for all of your Gateway users, then check the box next to ICA Only. This option disables SmartAccess and VPN features but does not require any additional licenses.  Note: most Citrix ADC Editions come with built-in Gateway Universal Licenses.
    2. Note: it’s also possible to disable authentication on Gateway and make StoreFront do it instead as described in Configure StoreFront Log On when authentication is disabled on Citrix Gateway VIP at Citrix Docs. However, it’s more secure to require Gateway to authenticate the users before the user can communicate with StoreFront.
    3. On the right, check the box next to DTLS.
      • DTLS enables EDT protocol, and UDP Audio.
      • EDT requires UDP 443 on client side, and UDP 1494/2598 on the server side.
      • VDAs support MTU Discovery for EDT traffic since UDP cannot be fragmented. ADC 13.1 build 17 and newer can enforce the Don’t Fragment bit when VDAs perform EDT MTU Discovery. See PMTUD discovery and DF bit propagation for EDT over Citrix Gateway at Citrix Docs for details. The setting can be enabled on the ADC at System > Settings > Change ICA Parameters.

    4. Click OK to close the Basic Settings section.
  9. In the Certificate section, click where it says No Server Certificate.

    1. In the Server Certificate Binding section, click where it says Click to select.
    2. Click the radio button next to a previously created certificate that matches the Citrix Gateway DNS name, and then click the blue Select button at the top of the window.
    3. Click Bind.
  10. Click Continue to close the Certificate section.
  11. In the Basic Authentication section, click the plus icon in the top right. Note: Citrix Gateway only seem to only support Basic Authentication policies, and not Advanced Authentication policies. For Advanced Authentication Policies, you’ll instead need to configure nFactor.

    1. Change the Choose Policy drop-down to LDAP,
    2. Leave the Choose Type drop-down set to  Primary, and click Continue.
    3. If you’ve already created an LDAP Policy, then click where it says Click to select, and select the policy.

    4. If you used the Authentication Dashboard to create an LDAP Server, then you probably haven’t created the corresponding LDAP Policy yet. Click the plus icon (Add button) to create a new policy.

      1. Use the Server drop-down to select the previously created LDAP Server.
      2. Give the policy a name. The Policy name can match the Server name.
      3. In the Expression box, enter ns_true (a Basic or Classic expression), or select it from the Saved Policy Expressions drop-down. Click Create.
    5. Click Bind.
    6. Or for two-factor authentication, bind two Basic authentication policies to Primary and two Basic authentication polices to Secondary. Note: if you instead do nFactor authentication, then you don’t need to swap the fields for Workspace app.
      • Primary = LDAP for Browsers (User-Agent does not contain CitrixReceiver)
      • Primary = RADIUS for Receiver Self-Service (User-Agent contains CitrixReceiver)
      • Secondary = RADIUS for Browsers (User-Agent does not contain CitrixReceiver)
      • Secondary = LDAP for Receiver Self-Service (User-Agent contains CitrixReceiver)
  12. Click Continue to close the Basic Authentication section.
  13. In the Advanced Authentication section, click Continue.
  14. Scroll down to the Profiles section, and click the pencil icon.
  15. In the TCP Profile drop-down, do one of the following:
    1. Follow the instructions at Citrix CTX232321 Recommended TCP Profile Settings for Full Tunnel VPN/ICAProxy from NetScaler Gateway 11.1 Onwards. In this case, there’s no need to change the TCP Profile.
    2. Or, select nstcp_default_XA_XD_profile, and click OK to close the Profiles section.
  16. To bind the Session Policies, scroll down to the Policies section, and click the plus icon near the top right.

    1. Select Session, select Request, and click Continue.
    2. Click where it says Click to select.
    3. Click the radio button next to one of the Receiver Session Policies, and click the blue Select at the top of the window. It doesn’t matter in which order you bind them.
    4. There’s no need to change the priority number. Click Bind.
  17. Repeat these steps to bind the second policy. In the Policies section, click the plus icon near the top right.

    1. Select Session, select Request, and click Continue.
    2. Click Add Binding.
    3. Click where it says Click to select.
    4. Click the radio button next to the other Receiver session policy, and click Select.
    5. There’s no need to change the priority number. Click Bind.
    6. The two policies are mutually exclusive so there’s no need to adjust priority. Click Close.
  18. In ADC 13.0 build 64.35, bind a Traffic Policy that enables Single Sign-on. Citrix says that this won’t be necessary on newer builds of ADC 13.0.
    1. Click the plus icon near the top right.
    2. Select Traffic, select Request, and click Continue.
    3. Click where it says Click to select.
    4. Click the radio button next to the Traffic Policy you created earlier and click Select at the top of the window.
    5. There’s no need to change the priority number. Click Bind.
  19. To bind Secure Ticket Authorities (STAs), on the right, in the Advanced Settings section, click Published Applications.
  20. On the left, in the Published Applications section, click where it says No STA Server.

    1. Enter a Delivery Controller in the https://<Controller_FQDN> or http://<Controller_FQDN> format, depending on if SSL is enabled on the Delivery Controller or not. This must be a FQDN or IP address. Short names don’t work.
    2. Click Bind.
  21. To bind another Secure Ticket Authority server, on the left, in the Published Applications section, click where it says 1 STA Server.

    1. In the VPN Virtual Server STA Server Binding section, click Add Binding.
    2. Enter the URL for the second Controller, and click Bind.
    3. This view shows if the STAs are reachable or not. To refresh the view, close the STA Server Bindings list, and reopen it.
    4. The list of Citrix Gateway Virtual Servers also shows you if the STAs (STA Status) are up or not.
    5. By default, STA server reachability is only checked every 2 minutes. You can change this at Traffic Management > Load Balancing > Monitors, and edit the sta and stasecure built-in monitors (source = CTX231916 NetScaler Takes 3-4 Minutes to Mark STA as DOWN)

  22. On the right, in the Advanced Settings column, click Portal Themes.
  23. On the left, in the Portal Theme section, change the drop-down to X1 or RfWebUI. You can also click the plus icon to create a theme. Note: many existing Portal Theme customizations are written for X1, but not for RfWebUI.
  24. Click OK to close the Portal Theme section.
  25. If you haven’t enabled the Default SSL Profile, then perform other normal SSL configuration including: disable SSLv3, bind an A+ Cipher Group, and enable Strict Transport Security.
  26. Click Done when done.
  27. Configure SSL Redirect for the Citrix Gateway DNS name and VIP.
  28. Configure StoreFront to use Citrix Gateway.

The CLI commands to create a Citrix Gateway vServer for ICA Proxy are shown below:

add vpn vserver gateway.corp.com SSL 10.2.2.200 443 -icaOnly ON -dtls ON -tcpProfileName nstcp_default_XA_XD_profile
bind vpn vserver gateway.corp.com -policy "Receiver Self-Service" -priority 100
bind vpn vserver gateway.corp.com -policy "Receiver for Web" -priority 110
bind vpn vserver gateway.corp.com -policy StoreFrontSSO -priority 100
bind vpn vserver gateway.corp.com -policy Corp-Gateway -priority 100
bind vpn vserver gateway.corp.com -staServer "http://xdc01.corp.local"
bind vpn vserver gateway.corp.com -staServer "http://xdc02.corp.local"
bind vpn vserver gateway.corp.com -portaltheme RfWebUI
set aaa parameter -wafProtection AUTH VPN -securityInsights ENABLED

Verify SSL Settings

After you’ve created the Citrix Gateway Virtual Server, run the following tests to verify SSL:

  1. Go to https://www.ssllabs.com/ssltest/ and check the security settings of the website. Citrix Blogs – Scoring an A+ at SSLlabs.com with Citrix NetScaler – Q2 2018 update.
  2. Citrix CTX200890 – Error: “Failed with status 1110” When Launching Desktops or Apps Through NetScaler Gateway: You can use OpenSSL to verify the certificate. Run the command: openssl s_client -connect gateway.corp.com:443. Replace the FQDN with your FQDN. OpenSSL is installed on the Citrix ADC, or you can download and install it on any machine.

WAF for Citrix Gateway

In NetScaler 14.1 build 21 and newer, you can enable Web App Firewall (WAF) on NetScaler Gateway. This feature is available in all editions of NetScaler.

  1. In the left menu, expand NetScaler Gateway and click Global Settings.
  2. On the right, in the right column, click Change authentication AAA settings.
  3. Find the WAF Protection drop-down and change it to AUTH and VPN. This enables the built-in WAF profiles globally.
  4. Change the Security Insights drop-down to ENABLED.

    set aaa parameter -wafProtection AUTH VPN -securityInsights ENABLED
  5. Scroll down and click OK.
  6. In NetScaler Console build 21 and newer, you can enable WAF Security Violations when enabling or editing Analytics on the Virtual Server.

  7. If you have NetScaler Premium Edition, then you can go to Security > NetScaler Web App Firewall > Profiles to see the WAF configuration.

    1. There are three built-in WAF profiles with names starting with ns-.
    2. If you edit one and click Security Checks, notice that only REST API Schema Validation is enabled. You can optionally enable the other security checks, but you will need a process to train/learn the config and correct issues. NetScaler Docs details some modifications you can make to the WAF profiles.

View ICA Connections

To view active ICA proxy sessions, click the Citrix Gateway node on the left, and then click ICA Connections on the right.

show vpn icaconnection

To view historical ICA sessions, search your Syslog server for ICASTART and/or LOGIN.

Or, if you don’t have Syslog server configured, then search /var/log/ns.log on the local appliance. Source = CTX232581 How to View Active Users Sessions Connected to Specific NetScaler Gateway vServers.

Logoff is Successful

With newer versions of StoreFront and Citrix Gateway, when you logoff StoreFront 3.15+ that is proxied through Citrix Gateway, all you see is a white page with the text “Logoff is successful”.

Alternatively, you can redirect to the Gateway logon page by creating and binding a Responder policy: (source = Storefront 3.15 “Logoff Is Successful” at Reddit)

  1. In the menu, go to AppExpert > Responder > Actions.
  2. Enable the Responder feature if it isn’t already enabled.
  3. On the right, click Add.
  4. In the Create Responder Action window:
    1. Give the Responder Action a name. The purpose of this Responder is to redirect to the Gateway logon page after StoreFront is logged off.
    2. Change the Type drop-down to Redirect. Note: it’s easy to miss this step.
    3. In the Expression box, you can enter "https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE or you can enter the actual https:// URL to the Gateway Virtual Server. The first option uses the Gateway FQDN originally entered by the user.
  5. Click Create.
  6. On the left, in the menu, click the Policies node under Responder.
  7. On the right, click Add.
  8. In the Create Responder Policy window:
    1. Give the Responder Policy a name.
    2. Change the Action drop-down to the name of the Responder Action you just created.
    3. If and higher, in the Expression box enter HTTP.REQ.URL.CONTAINS("/vpn/logout") || HTTP.REQ.URL.CONTAINS("/cgi/logout"). ADC 13.0 build 13.0 76.x  changed the URL from /cgi/logout to /vpn/logout.
  9. Click Create.
  10. In the menu, go to Citrix Gateway > Virtual Servers.
  11. Edit your Citrix Gateway Virtual Server.
  12. Scroll down to the Policies section and click the plus icon.
  13. Change the Choose Policy drop-down to Responder and click Continue.
  14. In the Policy Binding section, click where it says Click to select.
  15. Click the radio button (circle) next to the Responder Policy you just created and then click the blue Select button at the top of the page.
  16. Click Bind.

Related Pages

131 thoughts on “ICA Proxy (StoreFront) – Citrix Gateway”

  1. Hi Carl,
    We’re deploying a brand new CVAD infrastructure alongside our current production setup (EOL NetScaler mpx8*** 14.1, Ica Proxy, CVAD 2206) and I’m having an issue with external connections only. Details:
    NetScaler MPX9100 premium, Unified Gateway w/Content Switch, nFactor, ICA Proxy (mounted on rfWebUi) pointing at StoreFront, which has a fake (unresolvable) internal beacon and two external beacons. VMs are Win11 running on vCentres. Full enterprise CA chain installed and working. Session policies for Web and Receiver are working (nsconmsg).

    When we launch from an internal client (web or workspace) everything works perfectly. No issues. Using multiple different external clients (with our enterprise CA chain) and launching HTML5 VMs works perfectly. However, if I disable HTML5 and launch through Web or Workspace, we get the dreaded SSL Error 31. The VM attempts to launch, I get Connection Timeout in Director, but it just doesn’t complete.
    Should I be looking at the Cert Chain, noting it works fine internally? These external clients are coming through proxy servers, could this potentially be the issue when ICA attempts to route through proxy servers?

    Reply

    1. Is your firewall or reverse proxy doing content inspection? ICA protocol won’t work through an HTTP inspection device.

      Reply

      1. Hey Carl, no they aren’t (and the current ICA Proxy works fine through the same servers). We actually discovered the cause and fix today; we’re running CVAD2404LTSR and it enables HDXAdaptiveTransport by default. We compared two .ica files (working and not-working) and found the addition of the line VDAAuthInfo00*. A Google reverse image showed us this page: https://www.julianjakob.com/microsoft-entra-using-private-access-to-tunnel-citrix-hdx-sessions-and-giving-hdx-direct-a-try/
        Once we disabled the HDX Policies in Studio for our External Access policies, it all worked. Hope this helps other teams in the future!

        Reply

  2. Hi Carl

    Whether CWA for IOS support HTTP store front via gateway?
    configure the WI as http://fqdn of SF for the self service policy/profile.

    as we knows, adding a registry could support http store to add in the CWA

    Reply

    1. correct typo
      as we knows, adding a registry could support http store to add in the CWA

      —>

      as we knows, adding a registry could support http store to add in the CWA for windows

      Reply

  3. How can we achieve HDX over UDP (for UDP audio) through F5 Big-IP for ICA Proxy? found documentation for achieving same through Citrix Gateway using DTLS. Could not find any article for F5

    Reply

      1. Thanks for the response Carl. to ellaborate the issue we are facing, we are facing an Audio issue with calls through softphone.

        Tried accessing the Desktop through the Storefront URL by bypassing the F5 URL , session launches over EDT and audio calls works fine.

        However, while accessing the desktops through F5, session launches over TCP and audio calls have lot of static and jitters.

        We even created a 443 UDP Virtual Server on the F5, but no luck.

        Any thoughts or inputs ?

        Can the avove be re

        Reply

        1. Most Citrix customers are getting free NetScalers when they renew their CVAD licenses.

          Otherwise, F5 ICA Proxy simply doesn’t have the same features as NetScaler ICA Proxy.

          Reply

  4. Hello, i just configured the netscaler gateway for connecting to storefront. When i log on i can start a citrix desktop. But after loading the desktop i get an error: unknown client error 0. Do you know what this could be?

    Reply

  5. Great article Carl, do you know where I can find some documentation for setting up conditional access for Citrix users coming in through Citrix Gateway on NetScaler? I am looking to limit access to certain published applications based on device posture (i.e. domain joined)?

    Thank you.
    Simon

    Reply

  6. Hi,

    is there a bug for citrix workspace for windows or iOS?

    we had netscaler 12. 1 and have now 13.1

    but when i configure storefront, i am getting the error “server address cannot be verified, than i need to click manual setup and have the netscaler gateway inside but cannot save anything like password or use FaceID on Ipad.

    using MFA with RFWebUI Portal Theme..

    with 12.1 it was working flawless..
    any ideas? created all policies from here..

    Reply

      1. ok, will try it, thank you so much.

        but we are also getting this error on workspace for windows, just says “cannot add server url” …maybe the same error?

        Reply

        1. What is your Gateway theme?

          Edit your Session Policies. Make sure the expression does not include Referer.

          Reply

          1. RFWebUI

            what do you mean with “does not include referer”?

            side note:
            ios is now working again, thanks for this.

          3. i have created all the session policies from scratch and followed your article..

            so i have “HTTP.REQ.HEADER(“User-Agent”).CONTAINS(“CitrixReceiver”)

            and HTTP.REQ.HEADER(“User-Agent”).CONTAINS(“CitrixReceiver”).NOT

  7. Hi Carl, more great, easy to follow documentation.
    I have a working storefront service. I’ve followed the steps to put in the Netscaler as a citrix gateway.
    I can log on and display the list of applications, but when I click on one, there’s a spinny thing, but no ICA file is downloaded
    If I access the url via the storefront LB, that works fine. It’s only failing through the ICA proxy vserver.
    Any thoughts?

    Reply

      1. Hmm. There were no alerts or odd events because it was actually working. When I tried in Chrome rather than Edge, the ICA file appeared. That made me recreate the receiver session policy, which then worked.
        Thanks for the speedy response.

        Reply

  8. Hey Carl,

    Thanks, for your great work. Since Gateway 13.1 I get on Workspace App the Issue “This store does not exist” If I Add the URL of the Gateway.

    Hope you have an Idea.

    Reply

    1. Does your Session Policy have the Account Services address configured?

      Login to the webpage. On the top right click Account Settings. There’s a link to download the Receiver configuration file. If you open it, does it work?

      Reply

      1. 1. Session Policy have the Account Services address in (same as Web Policy)
        2. The Config to download does not work say Storefront ist noch reachable

        Have tested same Config on an Version 13.0 –> all ok –> Upgrade to 13.1 all ok
        Config a new 13.1 (49.13 / Version 50 – Citrix Gateway) issue as described.

        Thanks for your help!

        Reply

        1. Is your Internal Beacon only reachable internally?

          Is your NetScaler able to resolve the StoreFront Base URL?

          Do a network trace on the NetScaler while somebody tries to add a store to Workspace app. When you do the network trace you can select the SSLPLAIN option to decrypt it so you can see the HTTP traffic.

          Reply

          1. ok check all!
            1. No Internal Beacon is reachable external
            2. Yes, because connection over Webbrowers works fine
            3. in the trace you can see a TLS1.3 communication where the same thing is played 3 times. Between the attempts there is a communication between 127.0.0.1 127.0.0.2 which looks like a connection to the Storfront (GET /logon/LogonPoint/index.html HTTP/1.1\r\n) and so on.
            It seems to be a direct problem from version 13.1.

            Citrix support is informed.

            Thank you very much for your help.

          2. If you have a working config: you could find out the differences by comparing ns.conf.
            The path you posted is not used by Storefront but by Citrix Gateway.

          3. Here is some final feedback on the topic. Citrix Support has confirmed a bug in version 13.1. Version 14.1 works great and classical policies are still supported.
            Unfortunately, there is still no possibility to run MFA with Citrix Gateway license (50) and Advanced Policies.

            Have a nice day!
            Christian

  9. i have configured a gateway, the gateway works fine but i am curious the name shows “gateway.com/logon/LogonPoint/index.html” instead of “gateway.com/vpn/index”. may i know the reason?

    Reply

      1. Hi Carl, thanks for your response, how can I get back to vpn/index as I am not able to see updated page even after applying portal themes to on my gateway virtual server, I am just using LDAP authentication and no advance auth policies.

        Reply

        1. Switch to a theme that is not based on RfWebUI. Also remove any Authentication Profiles bound to the Gateway.

          Reply

  10. Thank Carl,

    i got all the way to launch the desktop. however i got a Warning: “the Citrix SSL server you have selected is not accepting connection” follow by “unknow client error 1110” and the desktop quit.

    My launch.ica contain the following setting
    HDXoverUDP=Preferred
    SSLenabled=ON
    SSLcipher=ALL
    SSLproxyhost=FQDN:443
    SecureChannelProtocol=Detect

    Are these setting the reason why?? how do i enable secure ICA on the gateway level?

    Reply

    1. Does the Citrix Gateway SNIP have connectivity to the VDA? Firewalls need to be opened.

      Does your Citrix Gateway have the correct STA servers configured?

      Reply

      1. Assumming Yes, because, i completed the enumeration process, Name resolution process and lanch process (meaning the desktop launched and failed with error 1110).

        I am testing from an internal workstation.

        Reply

        1. Launching an icon is completely separate from getting the list of icons. Launching an icon requires the Workspace app to create a separate connection to Citrix Gateway, which then verifies the STA ticket and forwards the traffic to the VDA. If you are internal, can your internal machine reach the Citrix Gateway FQDN?

          Reply

          1. yes i can reach my external FQDN. forgot to mention, it was failling after i enter my PIN (smart card Auth- I also follow you with nfactor for smart card auth. 🙂 nice direction.as well).

  11. Hi Carl

    On the setting page of StoreFront–Manage Citrix Gateways, it says “Remote access through a Citrix Gateway cannot be applied to unauthenticated stores”. Does it mean unauthencated is NOT supported for gateway connections? I configured ADC and StoreFront following your settings here. Citrix Workspace displays both unauthencated store and normal store when accessing the base URL. but access via Receiver for the Web leads to the expected store where “web interface address” is set. Thanks for the wonderful guide.

    Reply

    1. There are bugs in certain builds. Make sure HSTS is not configured in SSL Parameters. Edit your Session Policy/Profile, on the Client Experience tab, configure a timeout in both Session Timeout and Client Idle Timeout. Make sure your Responder policies have the correct expressions.

      Reply

  13. Hello Carl,

    Thanks for the great article. Wanted your advice regarding running app firewall on ADC to inspect the ssl component of the proxy. Is it worth the hassle, or will it break ica traffic? It is a policy requirement to have this.

    Appreciate your feedback.

    Reply

  14. Hi Carl, as of ADC firmware 13.0 76.29 the responder policy needs to change to /vpn/logout instead of /cgi/logout for the redirect back to the logon page to work.

    Reply

  16. Hi, Carl,
    I have configured the Citrix Gateway Virtual server VIP,
    and then NAT the firewall to the Gateway VIP.
    So there is an external IP ←→ internal IP set now.
    However the external users still can’t access the Gateway.
    Should I do any settings in the RNAT and INAT tab?

    Thank you.

    Reply

  17. Hey Carl,

    Has the storefront logout redirect mechanism changed with the recent versions of NS?

    I’ve noticed my logout redirects are no longer working via gateway but if I test the logout function from the storefront base URL or https://storefrontserver/Citrix/StoreWeb it works.

    At one time I accomplished this by using the responder policy to detect cgi logout then redirect to our intranet site. But that page is gone now. Any ideas?

    Also, I use SAML but don’t want to trigger a SAML logout if I can help it. I’ve got multipole gateways. I also see the same behavior if I use an ldap auth policy on the gateway.

    Reply

  19. Thanks Carl. Hadn’t come across the requirement for the Traffic Policy to implement SSO. Was a life saver when implementing a ‘NPS for Azure extension’ based multifactor setup.

    Reply

  20. Hey Carl,
    The traffic policy you use to enable SSO for StoreFront will break you TCP traffic if you are using full VPN (e.g. RDP, SMB, etc.). Remember this? https://citrixguyblog.com/2018/03/16/netscaler-otp-is-breaking-ssl-vpn/

    Same recipe to filter out the HTTP traffic only (GET/POST) works. Here is a quick reference:
    https://www.irangers.com/upgrading-citrix-adc-breaks-either-storefront-sso-or-ssl-vpn/

    Basically, use ‘HTTP.REQ.METHOD.EQ(“POST”) || HTTP.REQ.METHOD.EQ(“GET”) && false’ instead of just ‘true’

    Reply

  21. HI Carl

    thanks for this article, It had detailed explanation on storefront and ICA policy. Is there a way to include load balancing also.

    Our session policy is pointing only to a single store front server, how can we add redundant entries here.

    Reply

  22. Hi Carl,

    just configured remote access via Citrix ADC for one of our customers. Everything works fine, but sporadically connection doesn’t open with the first attempt. Sometimes, when I try to connect to the VDA, get the error message: “The Connection to desktops failed with status (0).” After trying a few more times, everything works as usual. This only appears with external clients. Really don’t know, where to have a look at it. Can’t find anything within the ADC logs or the verbose logs of the workspace app. Any idea about that?

    Reply

  23. Hi Carl,

    I just came across your article because the storefront logoff page looks quite simple over netscaler after upgrading to 1912 LTSR. Thank you very much for your detailed description on how to deal with this.

    As our company is used to get the somehow designed logoff page instead of just the logon page, I came up with a semi automatic approach.
    Noticing that just reloading this simple logoff page brings up the default CAG logoff page I adapted the responder action to
    the following:
    “https://” + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + “/cgi/logout”

    That basically reloads the page leading to the nice CAG Logout page.
    Is there an easier way to just reload a website using a responder policy?

    Best regards,
    Stefan

    Reply

  24. Dear Carl,

    Sorry for bothering you; I have tried to follow your guide to setup the ICA proxy and still not able to restrict the client go through the netscaler. What i can see is once the client auth with the citrix gateway, then the connection will be directly connected to the CAVD. I have no idea what went wrong, pleae kindly shield some light for me. Thanks.

    Reply

      1. Yes, i have enabled remote access.
        At the end i fixed part of the issue by remove and re-create the store(advised by some post) and now citrix for web is working as expected(go through the netscaler but citrix receive remain the same, no matter how i config it(ie. use netscaler’s fqdn), the store url would end up changed to storefront url….very weird….hope you have some idea.

        Reply

        1. Ah. That’s probably an issue with the Internal Beacon. Make sure the client cannot reach the Internal Beacon.

          Reply

          1. Hi Carl, you are genius. by using a unreachable beacon url, internal receiver client can go through the netscaler, but receiver for IOS is not the case, it still stick with the storefront.

          2. Confirm, both receiver and receiver for IOS is working now, million thx Carl.

  25. Hi Carl, first of all thank you for all of your documentation. It really helps to fill in the holes with other documentation out there.

    I have a basic question.

    Is there anything online, like a flowchart or something, or can you explain the flow of traffic from the onset of the client traffic hitting the gateway vip, then to the ldaps/radius auth process, then the behind the scenes traffic between the enumeration servers/sta servers, back to the netscaler etc?

    I am currently building a new netscaler pair to replace an old pair. We are currently not using Storefront, only using gateway for Receiver and Web Interface traffic.

    I don’t have access to any of the servers behind the scenes, only to the netscaler, so any traces I run don’t show anything going on behind the scenes.

    I would just like to understand the complete flow of data from when the client hits the vip, to the point where they receive their ica file and launch the application. Where it’s all flowing, what each server is doing, what the netscaler is doing etc.

    I have found a couple of Citrix docs that looked promising but didn’t explain the flow completely.

    Any help is appreciated, thanks!

    Reply

      2. Hello,

        i have a question about nstrace or nstcpdump. As far as I understand to have possibility to catch front-end and backend traffic i need to:

        Using a filter of the virtual server IP address and enabling the option “–link” in CLI or selecting the option “Trace filtered connection peer traffic” in GUI (available 10.1 and above), you can capture both the front-end and back-end traffic for the IP address.

        But this pose an issue when we have 500+ users connecting to NS. Will it work as well when i use source IP of a user?

        Reply

        1. It looks like Citrix removed that video. If you search YouTube for “citrix gateway traffic flow” you’ll find many more videos.

          Reply

  26. How can I prevent users from fiddeling with the Web Interface Address?
    Consider following example.
    1. User login to GW (ICA-Proxy) under citrix.corp.com
    2. Session-Policy takes over and redirects user to citrix.corp.com/Citrix/StoreWeb
    3. User knows about the store CoolStore, so he/she changes the URL to citrix.corp.com/Citrix/CoolStoreWeb

    One could say, that you can prevent users from accessing CoolStore by disabling Remote Access, but what about an admin store, which can be accessed from remote, too?

    So…

    1. User login to GW (ICA-Proxy) under citrix.corp.com
    2. Session-Policy takes over and redirects user to citrix.corp.com/Citrix/StoreWeb (Store has only limited settings allowed, e.g. no password change, HTML5 Workspace App etc.)
    3. User knows about the store AdminStore, so he/she changes the URL to citrix.corp.com/Citrix/AdminStoreWeb (this stores allows password change, native Workspace App etc.)

    How can one prevent this? Adding a content switch with URL checks and redirect the users to the content switch instead directly to the storefront? Are there any other possibilities?

    Reply

    1. I wonder if you can use Authorization Policies to block access.

      Or create a separate StoreFront server with just the Store you want reachable from the Internet.

      Reply

  27. Hello. I have one question about authentication. I have Nescaler 13 (auth forwarded to StoreFront, citrix xenapp 6.5). Is it use intergrated authentication from PC to login into Netscaler (from Citrix Receiver). All policies are set SSO Enabled. But everytime I restart PC, I have to authenticate user name and password to Netscaler. Single Sign ON feature is installed with citrix workspace app.

    Do you have any ideas ?
    Thanks !
    Piotr

    Reply

    1. The Citrix Workspace app GPO has a setting called Single Sign-on for NetScaler Gateway. Have you tried it?

      Reply

      1. Hi
        I tried to enabled that but without any results. How can I debug this process somehow ?
        Piotr

        Reply

  28. Hello Carl. I guess my question could by quite silly, but cannot find soluiton for it.
    I use Netscaler for ICAproxy only to internal XenDesktop/Storefront. I want to setup second Storefront for fault-tolerance. But using session profile I can configure only one Storefront (at Published application tab). So, is it possible to use more than 1 Storefront in case of ICAproxy?

    Reply

  29. Hi carl. Is there a way to have multiple Citrix gateway virtual servers (different hostnames) using a single external IP. I tried using SNI and content switching but that seems to require an advance license. I just need to implement multiple authentication methods (SAML, AD+Radius) to a single storefront.

    Reply

    1. If you have Advanced or higher, then you might be able to configure nFactor.

      Otherwise, Content Switching only supports a single Gateway. Sometimes you can use Hostname expressions on your Authentication policies and Session policies.

      Reply

  30. Its possible to use “Browser content redirection” from CWA to VDA 1912 through Netscaler Gateway?
    Or its possible to use “Optimization for Microsoft Teams” from CWA to VDA 1912 through Netscaler Gateway?

    Reply

    1. I’m not aware of any reason why it won’t work. In both cases, the client machine needs access to the source content. Or there’s a server fetch option for BCR.

      Reply

      1. My public CWA connects to the NetScaler (VIP) with SSL and then the NetScaler (SIP) connects to the internal VDA. Consequently, my client session terminates on the NetScaler. So does the optimization actually work through the SSL connection with the NetScaler?

        Reply

        1. BCR and Teams usually offload the content to the client device. The client device then needs to go to the source to get the content so it can play the content. E.g. if you’re offloading YouTube, then the client must be able to reach YouTube to get the video. Teams needs the client to be able to reach the Teams servers to access the audio/video. For client devices on the Internet, this means directly across the Internet to those resources. The endpoint devices do not tunnel those connections through your Citrix Gateway because your Gateway is not usually a VPN.

          Reply

  31. Can you post instruction on a possibility of a content switching LB infront of multiple non-addressable Citrix gateways? So that we can switch storefront as gateway.fqdn/storefront1 gateway.fqdn/storefront2. Or is it possible to use SNI to redirect to appropriate gateway? We have a challenge of a single external IP but multiple storefronts.

    Reply

    1. I don’t think Content Switching to point to more than one Gateway.

      On a single Gateway, you can bind multiple Session Policies and each with expressions based on Hostname. Then bind multiple SNI certificates (or wildcard) to your Gateway.

      Reply

  32. Just a random question.
    Currently our Internal clients are going through internal subnets (we have VPN tunnels between site, Citrix is hosted in Datacenter). What changes do I need to make in Netscaler and Citrix Virtual Apps 1903 or Storefront for all the connections to go out of WAN and use the WAN instead of going through internal subnet?

    Reply

    1. By WAN, do you mean Internet?

      If you implement Citrix Gateway, you can proxy your ICA connections through the Gateway. If you point your browsers to Gateway, then the ICA connection will go through Gateway. Whereas Receiver clients need a fake internal beacon (or HDX Optimal Routing) to force connections through Gateway.

      Reply

      1. Thanks for the reply Carl, Much appreciated.

        Yes, I meant with WAN as Internet.

        To give you a summary of my current setup:

        DC – Datacenter
        Retail A – Clients R (R as in Retail Clients)
        Site A – Clients S (S as in Sites Clients)
        Retail Firewall – VPN tunnel to DC Firewall
        Site Firewall – VPN tunnel to DC Firewall
        CTX-MGMT – Delivery Controller and StoreFront
        CTX NS – Netscaler
        CTX-APP0# – CTX APP Servers 01, 02, 03 (VDA)
        External Clients – No VPN tunnel or whatsoever

        When clients Access from web interface:
        Clients R or S, when they connect, the connection (CTX Website) is using public IP, but when they are connected the traffic I am noticing on the Firewall is shown as Internal. I am seeing on the Firewall logs as Clients R IP as source and Destination as VDA IPs. On the Netscaler I am seeing Retail A WAN IP as source and VDA IPs.

        When Clients Access from StoreFront:
        Same as web interface. Additional to that when I checked Workspace App registry, it shows CTX-MGMT as the storefront entries, whether clients are using VPN or not. The internal server is being exposed.

        In both of the above connections and traffic goes to VPN Tunnel, which is sort of bottleneck for bandwidth.

        What I would like is:
        1. Whether clients are using VPN tunnel or not, whether Sites/Retail have firewall with VPN tunnel to DC, the traffic to go out of the WAN, to give you better understanding: Clients R > Retail A > Firewall > WAN > Internet > WAN > DC > CTX NS
        2. One public IP to be exposed for clients (CTX-MGMT is an internal server) whether user connect on Web Interface or Storefront.

        I may be wrong above in trying to achieve something that is not doable. Citrix connection flow from my understanding is:
        Citrix web interface (public IP) > authentication page (CTX NS) > Storefront (Web Interface of CTX MGMT) > CTX-MGMT (Delivery Controller throws connection to VDA) > Connection to VDA.

        I hope I was able to understand 🙂 I will post the setup (as a diagram) on my twitter and tag you there 🙂

        Thank you in Advance!

        Reply

        1. For Browser clients, point the browser to a Citrix Gateway. ICA should automatically go through the same Citrix Gateway (assuming StoreFront has the Gateway configuration).

          For Receiver/Workspace clients, configure StoreFront with a fake Internal Beacon so Receiver/Workspace clients cannot reach the Internal Beacon and always think they are external. Or, configure HDX Optimal Routing so ICA traffic is always proxied through a Citrix Gateway.

          Reply

          1. For Browser clients. Did you mean “point the browser to a Citrix Gateway” to have citrix.abc.com to point to Public IP? Our firewall does the VIP of citrix.abc.com to NS Virtual Server IP.

            For Workspace clients, I have configured the fake Internal Beacon after your answer. For HDX Optimal Routing, I have, besides Direct HDX Connection (External N/A), citrix.abc.com (External, DC, Zones are empty). Under Gateway of the Store I have citrix.abc.com added with Role Authentication and HDX routing.

          2. To add, I have Citrix Netscaler VPX (NS12.0.57.24.nc) in place (not Citrix Access Gateway) does that makes a difference on what I am trying to achieve?

          3. Hi Carl, For internal DNS should i be pointing DNS to the Access gateway VIP IP or the Internal Load Balanced Storefront VIP. I’ve found that the HTML5 Client i get SSL errors if using load balanced VIP. Thanks

          4. HTML5 client should be going through Citrix Gateway VIP. If your Gateway FQDN and your StoreFront FQDN are different, then tell your HTML5 users to connect using the Gateway FQDN.

  33. Hi Carl,

    In the 2nd Session Profile ‘Receiver For Web’ you have selected “Java” as Plug-in Type. According to Citrix eDocs and my experience/understanding this should be “Windows/MAC OS X”.
    Can you please comment your setting?

    Thanks!
    Hong

    Reply

    1. It’s the setting I’ve used forever based on the original instructions and it hasn’t caused me any issues.

      Reply

      1. From Citrix ADC Cmd Reference:

        transparentInterception Allow access to network resources by using a single IP address and subnet mask or a range of IP addresses. The OFF setting sets the mode to proxy, in which you configure destination and source IP addresses and port numbers. If you are using the Citrix Gateway Plug-in for Windows, set this parameter to ON, in which the mode is set to transparent. If you are using the Citrix Gateway Plug-in for Java, set this parameter to OFF.

        Possible values: ON, OFF

        Reply

  34. Hi Carl, thank you very much for this and all your other blogs. They have helped me a great deal over the years. Hoping you can shed some light on an issue I am having with a current customer of mine.

    Environment is XA/XD 7.15 CU4, 2 SF and 2 DDC servers. In the DMZ there are 2 ADC 13 VPX appliances. We have a LB vServer for SF as well as a Gateway vServer both using DMZ IPs. SF has been configured with the LB FQDN and the Gateway URL and remote access enabled (different FQDN for internal and external). Internal beacon is the same as LB FQDN and is not accessible externally. External beacons are http://www.citrix.com and https://www.google.com. Gateway Session Profiles for ReceiverWeb and SelfServiceReceiver WI Address are configured to forward connection to the LB FQDN. Gateway vServer is using a public wildcard cert with 2 intermediate certs. Both intermediates are added to CA Certificates and linked together. Backend servers SF/DDC are using SAN certs created by an internal CA and the SF LB cert has been bound to the LB vServer. ADC appliances have been configured to seperate management and data traffic (https://www.carlstalhood.com/netscaler-11-1-system-configuration/#dedicatedmgmt) and (https://www.citrix.com/blogs/2018/07/23/separating-netscaler-management-and-data-traffic-for-disa-stigs/). The vServers must send traffic through a Palo Alto firewall to get to the SF servers. Customer has been through the Palo dozens of times and has opened all ports to/from and cannot see anymore traffic being denied. Note the NSIP on each ADC is on the management network and does not have to traverse the firewall. Also, this environment requires smart card authentication.

    Issue is we can connect through the Gateway via Receiver for Web and authenticate using smart card no issue but when trying to connect via Workspace/Receiver it looks like authentication works (smart card or username/pass) then once the account is added all that is displayed in the window is ‘Cannot connect to server’. The only way we can successfully connect using Workspace/Receiver is to change the Store URL to the first SF server FQDN and then add this URL as an account. No matter what we change/edit we have not been able to connect to the Store via Workspae/Reciever when going through the Gateway or LB vServer.

    I have been going banging my head on the desk for days with this issue and have searched through every blog, Citrix article, forum thread on the internet but just have not been able to figure this one out. Yesterday we started working with Citrix support on this but they have yet to find a solution as well. I would appreciate any ideas you may have about this.

    Thanks,
    Bryan

    Reply

    1. Are you referring to the first logon, which occurs during Discovery? CWA authenticates to Gateway, which then downloads the provisioning file from StoreFront. After discovery is complete, CWA then checks the Internal Beacon. If not reachable, then CWA connects to Gateway again using whatever authentication is configured on the Gateway object that is configured in the StoreFront Console, which should be set to Smart Card.

      If discovery is not working, then it could mean that your Account Services address is wrong, or the Internal Beacon is wrong.

      Reply

      1. Thank you for the response Carl. Yes the first logon. It looks as if discovery is working since the account is added to CWA. Smart card auth is configured on the Gateway using the CERT auth type (SubjectAltName:PrincipalName) because the smart cards are setup basically like CACs. The internal beacon is currently set to the https://FQDN-of-first-SF but has also been set to LB FQDN for SF. Both do not have public IPs so are not accessible externally. Citrix engineer is remoted in currently digging through the environment. He is also somewhat focused on the beacons but I’m just not sure how this could be the issue.

        Reply

          1. Currently Logon Type is set to Smart Card.and Smart card fallback is Domain (we disabled Domain pass-through earlier today so the fallback setting is probably grayed out now).

          2. Carl,

            Citrix support ended up recreating both the LB vServer for SF and the service group and using SSL_BRIDGE rather than SSL. This allowed smart card authentication to work properly via web and CWA. Will this have a negative affect on user sessions now that NS is not handling SSL communication and X-Forwarded-For is no longer in play?

  35. Hi Carl,

    I am somewhat confused with the terminology: You’re talking about Citrix Gateway, but is that different from Citrix Unified Gateway? So are your configurations based on a setup where there’s Citrix Unified Gateway with Content Switch Virtual Server in front of Gateway Virtual Server (like described in this photo: https://support.citrix.com/files/public/support/article/CTX220370/images/0EM60000000DiFp.png)? I am trying figure out what is the benefit of using Unified Gateway when it seems that you are doing many of the things without configuring the Content Switch and/or Unified Gateway (but then again some of your screenshots say Unified Gateway, like the Client Choices screen on SSL-VPN, so I am a little confused).

    I am currently using NetScaler ADC VPX with enterprise licenses as an ICA Proxy, but I would like to start using more of its features (Like provide users the possibility to use RDP Proxy and get Web and SaaS Apps). After reading your instructions for hours it seems that what I need to change in my ICA Proxy setup is: From Session Profile set Clientless Access to “ON” and ICA Proxy to “OFF”, from virtual server set ICA Only to “false” and enable RfWebUI theme. Of course I also need to configure the RDP Proxy and add the necessary bookmarks to Recourses -> Bookmarks. Am I close? 🙂

    Reply

    1. Unified Gateway runs in Gateway Clientless mode, which means internal URLs are rewritten to proxy through the Gateway URL. With the Content Switch, you can designate some URLs to not be rewritten by Gateway Clientless, which means that the Content Switch sends the traffic directly to the back-end servers instead of rewritten through Gateway Clientless.

      Many of the Gateway features require Clientless mode instead of ICA Proxy mode or VPN mode. Clientless mode has a built-in portal page that can show icons, including RDP icons.

      Reply

      1. Thanks for the reply Carl!

        Regarding the built-in portal page. I’ve “inherited” Netscaler that’s configured for ICA Proxy, but for some reason it doesn’t seem to be using the built-in portal. In Session Profile -> Client Experience the “Display Home Page” is selected and there’s the URL of “Receiver for Web sites” from StoreFront. So as I understand it, after logging in via browser, users are redirected to the StoreFront instead of using the NetScaler portal. I have a hard time understanding why it has been configured in such a way, but basically if I want to use the built-in portal and portal themes, I need to remove “Display Home Page” selection?

        I wonder – with current setup still in place – what has been the role of NetScaler? It has authenticated users, but how has the traffic flowed after login? Users have been basically using the StoreFront, but has this traffic still gone through NetScaler? Sorry if this is a stupid question…

        Reply

        1. Yes to removing Home Page to show built-in portal. Or better yet, create a new Gateway and experiment with clientless portal there instead of changing your current Gateway.

          For CVAD, there are two connections: HTTP, and ICA. HTTP is used for communicating with StoreFront, including authentication and icon enumeration. ICA is started after a user clicks an icon. Citrix Gateway proxies both HTTP and ICA. Without ICA Proxy, you’d have to expose every VDA machine to the Internet.

          Reply

          1. Thanks again for the help Carl!

            One more question: like I’ve described in another message, we for two AD domains in two forests, and there’s a one-way trust between these domains. Users are in domain corp.com and Citrix-servers are in lab.com domain. We also got two gateways, one is using lab.com LDAP-servers for authentication, and over there the built-in portal seems to work just fine (users login using lab.com credentials).

            On the second gateway vServer users authenticate using corp.com LDAP-credentials to Citrix-servers joined to lab.com domain. In the latter case the built-in portal shows no apps or desktops. If I forward the corp.com users to StoreFront after login (via session policies) it shows Apps and Desktops just fine, and everything works. I wonder what could be causing this? Could this be a firewall issue? Are there any documentation that would explain how the traffic goes in the portal scenario – especially how the Apps and Desktops are brought to the built-in portal?

  36. Thanks for this amazing and helpful website, which you maintain here 🙂

    I talked with our “NetScaler guy” about our sesision policy we had configured. He suggested instead of using “HTTP.REQ.HEADER(“User-Agent”).CONTAINS(“CitrixReceiver”).NOT” to append something and make it “HTTP.REQ.HEADER(“User-Agent”).CONTAINS(“CitrixReceiver”).NOT && HTTP.REQ.HEADER(“Referer”).EXISTS” instead.

    This would be helpful in case someone tries to connect using the Gateway plug-in – and could get too much information (I hope I’m repeating this correctly 🙈).
    Perhaps this could also be helpful for others?

    Reply

  37. Hi Carl, I am new to netscaler. I have installed self-signed certificate in my netscaler at home and it works fine and i can use my published application internally but when i user my external IP in virtual server and user url with ip address in my office https://99.234.134.x, I get directed to netscaler console not to storefront website not sure what i am doing wrong.

    my external ip: 99.234.134.x
    my internal IP for Delivery controller + storefront : 192.168.0.52
    my netscaler ip : 192.168.0.53

    i am not sure how to redirect the traffic so when i type my external ip at work, i can see my storefront website.
    I have added 192.168.0.53 in dmz on my router, forwarded ports 443 and 389 for 192.168.0.53.
    I have forwarded 1494 and 2598 for 192.168.0.52

    Please guide me.
    Thanks in advance

    Reply

    1. If there’s any NAT between the client machine and the VDA machine then you must use Citrix Gateway ICA Proxy. So you need to create a Citrix Gateway Virtual Server, assign an IP address to the Gateway, and then NAT your firewall to the Gateway VIP. The Gateway VIP is different than the NSIP, which is your appliance management IP.

      Reply

    1. It won’t be removed until ADC 13.1 so I’m not in any hurry.

      A big challenge is authentication policies since Advanced authentication policies can only be bound to AAA vServers and can’t be bound to Gateway vServers. Today, customers would need ADC Advanced Edition to use Advanced authentication policies. I’m hoping Citrix does something to fix the licensing problem.

      Reply

  39. Hi Carl,

    I need your urgent help to understand the following.

    We have single netscaler in that we have configured ICA proxy for Site A delivery Controller. now we recently built one more Citrix Site B Delivery controller which is totally separate.

    For this new site B we do not want to create separate URL with new Netscaler ICA proxy configuration.

    I want to know, can we access two different sites with single Netscaler external public URL over the network. so that users will authenticate netscaler and connection distribute on both Citrix Site A & B which will be isolate.

    If possible please let me know where do I need to change the configuration for Site B Delivery controller.

    Reply

  41. Hello,

    We had an issue where all our four Citrix StoreFront servers went offline (due to a network issue).
    The health monitor correctly detected this and the entire servicegroup was marked as down. This all worked as expected.
    However, users were still able to hit the Citrix Gateway virtual server and authenticate before being thrown an error.

    We run a GSLB set up with 6 data centres globally and GSLB continued to show the particular GSLB service as UP until I manually disabled it.

    Is there a way to have it mark the Citrix Gateway virtual server as down once all back-end Citrix StoreFront servers become down?

    Reply

    1. There is nothing built into Gateway to perform this health check (I asked Citrix). Another option is to configure your GSLB Services with monitors for both the Gateway and the StoreFront VIP. Or, you can configure your StoreFront VIP to failover to a different datacenter by configuring a Backup vServer.

      Reply

  42. Hi Carl. This is superb! Thank you. Do you kwno of an article that explains hot to add Netscaler running in ICA Proxy mode to the existing setup, in the way so it won’t interrupt the service ? Thank you.

    Reply

    1. What do you mean by “existing setup”? Are you asking how to add a secondary appliance to create an HA Pair? Or are you asking how to create a Gateway Virtual Server on an existing NetScaler?

      Reply

      1. Ohh sorry i should be more specific. I was wondering what would be the best way of enabeling ICA Proxy mode on the existing HA pair of the NetScaler Gateways. Whether enabeling the ICA Proxy feature on the existing NetScaler Gateways will do the trick or maybe it’s better to add another Netscaler VPX running in ICA Proxy mode and integrate it with also existing Storefront HA Pair, in this case NS Gateway will be used by another set of users for which proxing is necessary. The goal is to minimize downtime for the users.

        Reply

        1. It’s an “add”. You’re creating a new Gateway Virtual Server. Adding a Virtual Server won’t affect anything else on the appliance.

          However, who is going to manage it? If you have a team that manages load balancing which is different from the Citrix team, then you might want to create an instance that the Citrix team can own, and then put the ICA Proxy on the Citrix team’s instance.

          Reply

  43. hi Carl question if i follow that storefront authentication guide, where via the wizard i configure the gateway vip i add the certificate and the storefront authentication method , do i need to create manually session profiles and session policies or they are created via that wizard???? . I did that wizard and i also checked default ssl profile enabled and ica only since i dont want vpn sesions via netscaler

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *