Citrix HTML5 client does not work (CTX134123 error)
I’m struggling getting to connect our Citrix 7.13 XenApp and XenDesktop farm through the BIG-IP using Citrix’s HTML5 receiver I’m new to the F5 BIG-IP. I can connect to the virtual server on the BIG-IP from within our internal network just fine! I can log on, my desktop is opened and all applications are available and I can start them all. But whatever I do, when I start the session (HTML5 client) from the internet (home PC) I can log on but immediately get the message: ‘Citrix Receiver cannot create a secure connection in this browser. Please refer to Citrix Knowledge Center article CTX134123’. I do see all available applications, but when I try to start one of them I get the same error. The Citrix article does not offer help. I think some kind of network traffic isn’t working through the BIG-IP (because I don’t see this problem when I connect from the internal network) I’ve implemented the iApp using with most default settings, except: In general: No, do not proxy ICA traffic and authenticate users with the BIG-IP In Virtual Server for Web Interface or StoreFront servers: Terminate SSL for clients, re-encrypt to Citrix servers (SSL bridging) The ip address that clients will use is the external ip BIG-IP (virtual Server) address The Citrix environment uses StoreFront 3.0 BIG-IP virtual servers are on the same subnet as the StoreFront servers In Virtual Server for XML Broker or Desktop Delivery Controller (DDC) Servers: BIG-IP virtual server in relation to your XML Broker or DDC servers? Same subnet for the virtual server and the XML Broker In ICA Traffic: How will ICA traffic travel between the clients and the ICA servers? BIG-IP system acts as gateway (router) to the ICA server network Which VLANs should accept ICA traffic? ICA traffic is allowed from all VLANs I'v implemented the citrix html5 client bundle on the BIG-IP Any help you can offer will be greatly appreciated! Kind regards, Paul
Citrix Netscaler to F5 BIG-IP
Problem this snippet solves: This scripts is built to convert Citrix Netscaler text based configuration files to BIG-IP commands. This scripts aim to reduce the largest burden of entering object names, IP addresses and other parameters, as well as logically linking these objects to each other. This script is not meant to perform a totally automated and unattended migration. For the objects that the script migrates, not all parameters may be converted. For the parameters that are converted, some are mapped to the closest matching BIG-IP feature. If there are any non-ASCII characters or line-breaks in the source file, this will need to be manually fixed first (some screen captures may wrap lines so copying the file directly is preferred). All Netscaler commands are on a single line. Note that this script will produce a comprehensive list of errors, warnings, notes, etc, at the bottom of the output file. You should look through these first, starting with the errors and working your way down to less critical messages. You may need to correct problems in the input file or in the Perl script and re-run the conversion. Once you have reviewed the warnings and notes, you should look through the configuration that was generated. The original Netscaler commands are provided for each portion of the BIG-IP configuration and you should compare the "before and after" for each object. How to use this snippet: To get command line config execute the following command on Netscaler: more /nsconfig/ns.conf (Or you can secure copy it to your PC using something like winscp/pscp.) Input restrictions: Probably only supports Netscaler v7, v8, and v9 Output restrictions: Outputs BIG-IP 9.4.x format (which v10 appears to read fine) Output file contains warnings errors, base config, and main bigip.conf It is best to have Active Perl on you PC to perform the conversions. You can also use the Perl installation on the BIG-IP command line. Once the file is converted you can import the configuration into the BigIP using (b load, or b merge). You can also copy/paste into bpsh. Read the header of each of the scripts files, they have addition information on the usage of the scripts. Usage: perl nsv8_to_f5.pl netscalerconfigfile /var/tmp/bigipoutputfile
Citrix Federated Authentication Service Integration with APM
Introduction This guide will cover how to use APM as the access gateway in front of Storefront when using Citrix FAS. This will enable you to leverage authentication methods like SAML, Kerberos, or NTLM on the client side. Note that almost any auth method can be supported via Receiver for web, but Receiver self-service does not support some auth methods such as SAML. Deploy Citrix Federated Authentication Service Now you’ll need to deploy Citrix Federated Authentication Service (FAS). Deployment of FAS is out of scope for this article, but as there are many parts I found the following guide from Carl Stalhood very helpful: http://www.carlstalhood.com/citrix-federated-authentication-service-saml. Ignore the section “SAML on Netscaler Gateway” since you’re going to deploy APM instead, but don’t miss that last section “Configuring Storefront for SAML Gateway”. When configuring Storefront anywhere it requests the Netscaler Access Gateway address you’ll use the FQDN you intend to use for your virtual server on Big-IP (how users will access Storefront). Examples include the callback URL field when configuring the authentication and when configuring the Netscaler gateway. Before proceeding, you should be able to go direct to the Storefront server, log in, and be able to launch an application successfully. There can still be misconfigurations that prevent access through an access gateway, but you will have fewer areas left as problems. You must use an Enterprise CA, otherwise on the CA you will see pending certificates not getting approved automatically and you will be unable to launch apps. Also note that if you have previously made configuration modifications usually needed forearlier versions like Citrix 6.5, such as host file entries, those should be removed prior to proceeding. For correct operation of FAS, DNS needs to be setup properly which may include setting up PTR records. Create the SAML SP In the Big-IP GUI go to Access Policy -> SAML -> Big-IP as SP and click create. You’ll create an SP config and for the entity ID in the format https://my-vs-fqdn.domain.com. All the rest can be left default. Now you’ll need to setup your IdP Connector. This could be another Big-IP APM, ADFS, Okta, or any other IdP service. You can import the metadata if available or you can manually configure it. Configuring the IdP connector is out of scope for this article, but after configuring it, you’ll select your SP and click the “Bind/Unbind IdP Connectors” button, “Add New Row”, select it from the drop down as the SAML IdP Connector, then click Update, OK. Note that you can bind multiple IdP connectors here if there are multiple IdPs. You need to set a matching source (variable) and the matching value that should cause use of that IdP. A common solution might be %{session.server.landinguri} for the source and /customer1 for the matching value to go to customer 1’s IdP. Now you’ll see this on the SP configuration page. Your IdP should be setup to send either the user’s userPrincipalName or sAMAccountName as the NameID. This should match either the userPrincipalName or sAMAccountName of the user account in the AD domain used by Citrix that you want the user logged in as. Carl Stalhood’s guide linked above provides an example configuring the ADFS IdP and he is using userPrincipalName. Note that if you decide to use alternate UPNs (not matching your AD domain name) for your users you will also need to enable those domains in “Trusted Domains” on your Storefront server. Deploy the iApp Now we can move on to deploying APM as your access gateway. First, deploy the latest iApp. At the time of writing this article, that’s version 2.4.0. When deploying the iApp you’ll need to answer the following questions as shown: You’ll need to specify your STA servers: Finally, pay special attention to the DNS name you’re going to have clients use. This should be the same as you used in the Citrix Storefront configuration earlier and the SAML configuration later. This is how users are going to access the deployment. Now you have the iApp for Citrix deployed, but it’s using the default forms based authentication. You need to customize the authentication method. This guide will help you deploy SAML authentication, but as mentioned you could use NTLM, Kerberos, or another authentication method. Before proceeding you need to verify that the certificate you’ve selected is valid. If it is not, SSO will fail when Storefront tries to callback to the virtual server and the user will get the error “Cannot Complete Your Request”. You can browse to the FQDN you entered from the Storefront server to make sure you don’t get certificate errors. Normally you would use a publicly signed certificate and that will work fine (but don’t forget the chain). If it’s an internally signed certificate, your Storefront server needs to trust it as well. Modify the iApp’s APM Policy By default the policy looks like this: We need to modify it to look like this: To modify the policy you will need to turn off “strict updates” on the iApp: Note that in this case we aren’t modifying the Receiver branch because Receiver doesn’t support SAML authentication. You could just change it to deny receiver clients if desired. First remove the Logon Page, AD Authentication, and SSO Credential Mapping objects from the Browser branch. Next add a SAML Auth object right before the Session Variable Assign object (plus sign, Authentication tab, SAML Auth). Select the SP you configured earlier. Next, open the Session Variable Assign. You need to add a new entry, and set session.logon.last.username to equal the session variable session.saml.last.nameIDValue. Notice that the domain and sta_servers variables were set here already, those were done by the iApp. Here is what creating that looks like: Now your policy should look like the one above. Be sure to click Apply Policy in the top left. Test And finally you should be able to browse to the FQDN of your new virtual server, be redirected to your SAML IdP for authentication, then get redirected back and SSO’ed in to your Citrix environment. You should be able to see the Storefront catalog and launch an application Updates 12/21/2016 - Removed an iRule that is not needed for SSO to function properly in a complete deploymentCitrix ICA proxy session disconnect controll problem
Hi Everyone, Quick overview of what I am trying to accomplish. To start, I have very limited experience with ICA proxy and just getting more familiar with it now. So, we have Citrix XenApp environment used for desktop application delivery for remote client. We do have a working environment(Big-IP 10.2.4 LTM, APM), however, client requested a change in application delivery configuration. Now client requested that in the event of dropped internet connection Citrix Receiver session to be disconnected on XenApp end after 60 seconds of idle time. So, I have reconfigured the timeout on backend and tested everything locally, where I was able to achieve desired result. I would launch the application and then disconnect network cable from the desktop running Citrix Receiver. As expected, the session would get dropped in XenApp console after 60 seconds exactly. Again, all of that works connecting everything directly, bypassing the Load balancer. However, when going through ICA proxy, when I pull the network cable the session does not die for 7 and a half minutes. I have tried to make changes to the TCP WaN and Lan profiles utilized by ICA proxy by changing idle timeout values to 60 seconds but all without any success. Session, would not get disconnected for 7,5 minutes no matter what I do. Please, help me to understand why I am not able to control session timeout and what I am doing wrong. I have a suspicion that when I pull the cable, client side connection does indeed die and gets dropped, but on server side it stays alive. If that is the case I might need an iRule to kill the server side connection once client side connection dies. Please, help me to understand...
Solution for Citrix Optimal Gateway Routing
Introduction On the heels of a very well written DevCentral article by Steve Lyons, Smart Card Authentication to Citrix StoreFront Using F5 Access Policy Manager, where he documented how to configure F5 BIG-IP APM to provide SSO Smart Card Authentication to Citrix StoreFront I figured it was time to publish another APM/Citrix related article for the community. A customer of mine was going to be replacing Citrix ADCs (NetScalers) with F5 APM throughout their enterprise to provide SSO SmartCard authentication to StoreFront along with ICA traffic proxying. There is a freely available iApp available for your APM that will help with this configuration. However, this iApp solution is only appliable if you are authenticating to StoreFront AND proxying your ICA traffic through the same F5 APM. And of course, this was not the configuration my customer was looking to implement. The existing Citrix ADC based implementation was configured to take advantage of something Citrix calls Optimal Gateway Routing (OGR); sometimes referred to as Optimal HDX Routing. Table of Contents What is OGR The F5 Problem The F5 Solution Configuration Steps F5 APM SF-GW Configuration iRule - Create STA Resolution Halt iRule - Create Citrix Logged Out F5 APM ICA-GW Configuration iRule - ExtractCitrix STA iRule - Resolve Citrix STA What is OGR? OGR for Citrix Storefront is a design whereby a Citrix web client is directed to an ICA Proxy Gateway (ICA-GW) anywhere in the world that is closest to the app/desktop hosting environment (XenApp and XenDesktop servers) which may not be on the same Citrix StoreFront ADC (NetScaler) Gateway (SF-GW) which has authenticated the user. This is in contrast to being directed to a single ADC Gateway device that hosts SF-GW and ICA-GW. In a Citrix ADC deployment, the ICA-GW (not the SF-GW) is responsible for validating/resolving the STA ticket provided by a Secure Ticket Authority (STA) server. Since the ICA-GW is responsible for this validation, it allows OGR to function and send ICA traffic to a different ICA-GW than what was used to download the ICA file from StoreFront. Figure 1: Suboptimal Gateway Routing Figure 2: Optimal Gateway Routing The F5 Problem(link back to Top of page) The F5 Access Policy Manager (APM) can be used to simultaneously replace a Citrix ADC for both the StoreFront Authentication process as well as the ICA Proxy process. In contrast to how Citrix ADC processes a downloaded ICA file, the F5 APM Citrix VDI plugin is designed to validate/resolve the STA ticket with the STA server upon download of the ICA proxy file from the StoreFront server.The validation details are stored locally in the APM SF-GW access session table. This session table is not shared amongst APM devices in the enterprise. So, if the ICA file then directs the client to a different APM device (ICA-GW) by virtue of the ICA file entry: SSLProxyHost=[ICA-Proxy-FQDN]:443 than what was used to download the ICA file (APM SF-GW), the APM ICA-GW will NOT have knowledge of the already validated/resolved STA ticket. The APM Citrix VDI plugin does not perform validation/resolution of the STA ticket upon launching the ICA file. The APM ICA-GW will then terminate the app/desktop session. The F5 Solution(link back to Top of page) In order to support Citrix Optimal Gateway Routing in a distributed gateway environment, the following configuration can be used. The APM SF-GW is responsible for authentication, proxying StoreFront application/desktop enumeration, and app/desktop ICA file retrieval. When a client requests an app, StoreFront will create an ICA file based on information it has retrieved from the DDCs and STA servers, send it to the APM SF-GW, which will then send the ICA file to the client. An iRule attached to the virtual server on the APM SF-GW will prevent STA validation upon download. The client can then launch the ICA file which contains a line: SSLProxyHost=[ICA-Proxy-FQDN]:443 directing the connection to an APM ICA-GW. The APM reads the ICA request, pulls out the STA server shortname referenced in the payload: Address=;40;STA12345678;0123456789ABCDEF0123456789ABCD which is the same STA server that StoreFront connected to, and matches that to a URL for the STA server using a pre-configured datagroup. Then APM ICA-GW connects to the STA server in order to validate the STA ticket included in the ICA payload. STA validation variables are stored in an APM access session table. Now that the STA ticket has been validated, the APM will proxy the ICA traffic to the app server. Configuration Steps(link back to Top of page) Assumptions: 1.Citrix StoreFront and DDCs are configured for external client access utilizing HDX routing which requires the configuration of Secure Ticket Authority (STA) servers similar to the following: Figure 3: StoreFront server, “Citrix StoreFront” applet -> Stores -> “Manage Netscaler Gateways” -> Edit Figure 4: StoreFront server, “Citrix StoreFront” -> “Configure Store Settings” -> “Optimal HDX routing” F5 APM SF-GW Configuration(link back to Top of page) Creating a StoreFront AD Authentication Access Policy Navigate to Access››Profiles / Policies : Access Profiles (Per-Session Policies) and click Create General Properties Name: sta_resolver_ap Profile Type: All Customization Type: Modern Configurations Logout URI Include: /Citrix/UDF_storeWeb/Authentication/Logoff Note: replace UDF_storeWeb with the appropriate StoreFront related Store name for your Storefront environment Language Settings Configure your desired Language settings and click Finished When you are returned to the previous page displaying all access profiles, select Edit from the newly created policy to open the Visual Policy Editor (VPE) Between Start and Deny, select the + From the Logon tab, click the “Logon Page” radio button and click Add Item. Accept the Logon Page Agent default settings. Click Save Click the “+” (plus sign) to the right of the Logon Page object From the Authentication tab, select your preferred method of authentication. This should match up with the authentication method the StoreFront is expecting to consume.For the purpose of this article, we are using “AD Auth”. The configuration of the AD server is beyond the scope of this article. Click Add Item. Complete the Authentication configuration per AAA guidelines. Click Save. Click the “+” (plus sign) to the right of the Authentication object Select the Assignment tab. Select the SSO Credential Mapping radio button and click Add Item. Leave the defaults and click Save Change the ending for the SSO Credential Mapping fallback to Allow Click Apply Access Policy at the top left Once complete select Apply Access Policy and your VPE should look like the screenshot below Creating a VDI Profile Navigate to Access››Connectivity / VPN : VDI / RDP : VDI Profiles and click Create New Profile Profile name: citrix_vdi Parent Profile: /Common/vdi Click OK Create STA Resolution Halt iRule Navigate to Local Traffic››iRules : iRule Listand click Create Name: STA_STOP Definition: when RULE_INIT { set static::debug_sta_fwd 0 } when HTTP_RESPONSE { if { [HTTP::has_responded] } { log local0. "http has responded" return } if { $tmm_apm_client_type != "citrix-launch" } { #log local0. "apm client type is NOT citrix launch" return } set content_type [string tolower [HTTP::header Content-Type]] if { $content_type contains "application/x-ica" || $content_type contains "application/vnd.citrix.launchdata+xml" } { log local0. "content type is ica or citrix" set ica_file_response 1 set contentLength [HTTP::header "Content-Length"] HTTP::collect [HTTP::header Content-Length] } else { log local0. "content is not citrix" } } when HTTP_RESPONSE_DATA { if { [info exists ica_file_response] } { log local0. "ica_file_response exists" # set session.user.access_mode to local ACCESS::session data set "session.user.access_mode" "local" if { ![info exists target_apm] } { return } } } Create Citrix Logged Out iRule Navigate to Local Traffic››iRules : iRule Listand click Create Name: storefront_logged_out Definition: when CLIENT_ACCEPTED { set citrix_logout 0 } when ACCESS_ACL_ALLOWED { set type [ACCESS::session data get session.client.type] if { !($type starts_with "citrix") } { set storeWebName "/Citrix/UDF_storeWeb/" set http_uri [HTTP::uri] if { $http_uri == "/" || ($citrix_logout eq 0 && $http_uri ends_with "login.aspx") } { # log local0. "For [HTTP::uri] Redirecting to $storeWebName" ACCESS::respond 302 Location "https://[HTTP::host]$storeWebName" } elseif { $http_uri contains "Logoff" } { set citrix_logout 1 } elseif { $citrix_logout eq 1 && $http_uri ends_with "login.aspx" } { set citrix_logout 0 ACCESS::respond 200 content "Logged out\r\n" Connection close ACCESS::session remove } } } Note: The storeWebName variable value in the iRule must be changed to match your Citrix store name Configuring an HTTP Profile Navigate to Local Traffic››Profiles : Services : HTTP and click Create Name: storefront_http Parent Profile: http Request Header Erase: Accept-Encoding Request Header Insert: X-Citrix-Via:storefront.itc.demo Note: X-Citrix-Via is the header name and storefront.itc.demo is the value. The value must match the external FQDN in your environment. Redirect Rewrite: All Insert X-Forwarded-For: Enabled Click Finished Creating a VDI Profile Navigate to Access››Connectivity / VPN : VDI / RDP : VDI Profiles and click Create New Profile Profile name: citrix_vdi Parent Profile: /Common/vdi Click OK Creating a Client SSL Profile for Storefront Client Access Navigate to Local Traffic››Profiles : SSL : Client and click Create Name: storefront_clientssl Parent Profile: clientssl Certificate Key Chain: Select the External Cert and Key that will be used for this website Configuring a Storefront Pool Navigate to Local Traffic››Pools : Pool List Name: storefront_pool Health Monitors: tcp Load Balancing Method: Least Connections (member) Address: 10.1.20.6 Service Port 443 Click Add and Finished NOTE: add as many StoreFront servers in your environment to the pool member list Creating a Virtual Server for Storefront Access Navigate to Local Traffic››Virtual Servers : Virtual Server Listand click Create Name: storefront_vs Type: Standard Destination Address/Mask: 10.1.10.101 Service Port: 443 Protocol Profile: tcp HTTP Profile (Client): storefront_http SSL Profile (Client): storefront_clientssl SSL Profile (Server): serverssl Source Address Translation: Auto Map (or whatever is appropriate for your environment) Access Profile: storefront_ap Click the + next to Connectivity Profile to create a new profile. Profile Name: proxy_conn Parent Profile: /Common/connectivity Click Ok VDI Profile: citrix_vdi iRules Highlight “STA_STOP” and “storefront_logged_out” and click the double left arrow button to move the iRule to the Enabled box Default Pool: storefront_pool Default Persistence Profile: cookie Fallback Persistence Profile: dest_addr Click Finished This concludes the configuration of the F5 APM SF-GW There is a minimum requirement of 2 virtual servers on the ICA-GW. The first VS (proxy-vs) will be the listener that client ICA proxy requests are sent to. An iRule attached to this VS will pull out the payload of the ICA proxy request and make a sideband call to another VS (sta-resolver-vs) on the same APM. The sta-resolver-vs VS, via an iRule, will take the payload sent by the proxy-vs sideband call and use the STA server “shortname” in the payload to reference a Datagroup to find the STA server URL. This URL is then populated in the APM session table. The VDI profile will use this URL to contact the STA server to validate the STA ticket. Information received back from the STA server populates the session table. The ICA-GW now has the information it needs to proxy the ICA traffic. F5 APM ICA-GW Configuration(link back to Top of page) Creating a STA Ticket Resolver Access Policy Navigate to Access››Profiles / Policies : Access Profiles (Per-Session Policies) and click Create General Properties Name: sta_resolver_ap Profile Type: All Customization Type: Modern Configure your desired Language settings and click Finished When returned to the previous page displaying all access profiles, select Edit from the newly created policy Between Start and Deny, select the + and then the “General Purpose” tab Select “Empty” and click Add Item Name: sessionexternal_sta_ticket Click the Branch Rulestab Click the Add Branch Rulebutton Name: External STA Ticket Click changenext to Expression: Empty Click the Advancedtab In the advanced field enter: expr {[mcget {session.external_sta_ticket}] == 1} Click Finished Click Save Click Apply Access Policy at the top left Once complete select Apply Access Policy and your VPE should look like the screenshot below Create a client SSL profile that contains the appropriate certificate, key, and chain. This configuration is beyond the scope of this article. A server SSL profile is not required as traffic between the ICA-GW and DDC does not use TLS. Creating a VDI Profile Navigate to Access››Connectivity / VPN : VDI / RDP : VDI Profiles and click Create New Profile Profile name: citrix_vdi Parent Profile: /Common/vdi Click OK Create STA ticket Extractor iRule Navigate to Local Traffic››iRules : iRule Listand click Create Name: StaTicketExtractor Definition: See iRule here: https://devcentral.f5.com/s/articles/Extract-Citrix-Secure-Ticket-Authority-STA Note: A Virtual Server name (sta-resolver-vs) is referenced in the command ‘set conn [connect "sta-resolver-vs"]’.This VS will be created further in the article. If the VS is created with another name, then the command in this iRule must be changed to match the name of the VS. Creating a Virtual Server for ICA Proxy Navigate to Local Traffic››Virtual Servers : Virtual Server Listand click Create Name: proxy-vs Type: Standard Destination Address/Mask: 10.1.10.115 Note: This will be the IP address available to external users attempting to access Citrix resources Service Port: 443 Protocol Profile: tcp HTTP Profile (Client): http SSL Profile (Client): citrix_client_ssl SSL Profile (Server): leave blank Source Address Translation: Auto Map Access Profile: sta_resolv_ap Click the + next to Connectivity Profile to create a new profile. Profile Name: proxy_conn Parent Profile: /Common/connectivity Click Ok VDI Profile:citrix_vdi iRules Highlight “StaTicketExtractor” and click the double left arrow button to move the iRule to the Enabled box Do not select a Default Pool or Persistence Profile Click Finished Create STA Ticket Resolver iRule Navigate to Local Traffic››iRules : iRule Listand click Create Name: StaTicketResolver Definition: See iRule here: https://devcentral.f5.com/s/articles/Resolve-Citrix-Secure-Ticket-Authority-STA Create a DataGroup to map STA server shortnames to the URL of the STA server Navigate to Local Traffic››iRules : Data Group Listand click Create Name: sta_dg Type: string Enter as many pairs of String:Value necessary for your environment. The String will be the STA server shortname; typically in the STA12345678 format although this is customizable in the Windows registry. The value is the URL of the STA server in the format: https://[FQDN]/scripts/ctxsta.dll. Check with the Citrix system administrator if the STA servers should be contacted via http or https. This guide was written for HTTPS Click Finished Creating a Virtual Server for STA ticket Resolution Navigate to Local Traffic››Virtual Servers : Virtual Server Listand click Create Name: sta-resolver-vs Note: This name must match the name referenced in the ‘set conn [connect "sta-resolver-vs"]’ command in the previously created “StaTicketExtractor” iRule Type: Standard Destination Address/Mask: 1.2.3.4 Note: This can be any dummy IP address Service Port: 80 Protocol Profile: tcp HTTP Profile (Client): http SSL Profile (Client): leave blank SSL Profile (Server): serverssl Source Address Translation: Auto Map Access Profile: sta_resolv_ap Connectivity Profile: proxy_conn VDI Profile:citrix_vdi iRules Highlight “StaTicketResolver” and click the double left arrow button to move the iRule to the Enabled box Do not select a Default Pool or Persistence Profile Click Finished This concludes the configuration of the F5 APM SF-GW Conclusion(link back to Top of page) And that’s it. When you connect to your StoreFront virtual server on the F5 APM SF-GW, you will be presented with an F5 APM login screen.Login with your AD (or other) credentials.This should SSO you into Storefront where you will be presented with applications assigned to your AD account or groups. When you click on an app or desktop, an ICA file is downloaded and automatically launched by the Citrix Connection Manager (Receiver).The SSLProxyHost line in the ICA file directs your client to the F5 APM ICA-GW defined in the StoreFront configuration. The ICA-GW reads the payload in the request and contacts the STA server for validation, and then your app/desktop should load.
Receiving error when connecting to Citrix Receiver for external use.
I am more of Citrix person, than F5, but we are trying to deploy Citrix Receiver to all domain based endpoints. We are using Xendesktop 7.6 and StoreFront 2.6.0.5031 with a single FQDN Certificate. Internally works fine using Receiver for Web and Citrix Receiver GUI - SSO. However externally won't work correctly with Citrix Receiver, but works fine with Receiver for the Web with Pass-through. We have an F5 and are using the latest iApp. We are using the icaclient ADM Template for all domain based machines and have setup Storefront Account to https://storefront.company.com/Citrix/Store/discovery;on;Description (example). We enabled pass-through authentication = Enabled, Allow pass-through authentication for all ICA connections = Enabled in the GPO. The error we receive in Citrix Receiver when trying to refresh apps externally is "Your apps are not available at this time. Please try again in a few minutes or contact your help desk with this information. Cannot contact (store). It appears its not communicating back to the F5 at all. Citrix mentions its something not configured correctly on the F5 and they can't support it. I am curious if anyone else has run into the issue and how to fix? Let me know if you need more information. Thanks!Two-factor authentication for Citrix Receiver for Windows
I have deployed F5 APM with two-factor authentication. APM is currently replacing the Web Interface / Storefront servers. Two-factor authentication is confirmed working for the Webtop, Citrix Receiver for Mac, Citrix Receiver for iOS and Citrix Receiver for Android. My issue is that Citrix Receiver for Windows doesn't appear to have the necessary options to select the Logon type of "Security token only" or "Domain and security token" like the Receiver for other OS's do. I suspect that Citrix Receiver for Windows requires some kind of configuration push from the server (which in my case is APM). Has anyone else experienced this issue or have any ideas?Resolve Citrix Secure Ticket Authority (STA)
Problem this snippet solves: Optimal Gateway Routing (OGR)for Citrix Storefront is a design whereby a Citrix web client is directed to an ICA Proxy Gateway (ICA-GW) anywhere in the world that is closest to the app/desktop hosting environment (XenApp and XenDesktop servers) which may not be on the same Citrix StoreFront ADC (NetScaler) Gateway (SF-GW) which has authenticated the user. This is in contrast to being directed to a single ADC Gateway device that hosts SF-GW and ICA-GW. In a Citrix ADC deployment, the ICA-GW (not the SF-GW) is responsible for validating/resolving the STA ticket provided by a Secure Ticket Authority (STA) server. Since the ICA-GW is responsible for this validation, it allows OGR to function and send ICA traffic to a different ICA-GW than what was used to download the ICA file from StoreFront. This iRule will be used to resolve/validate the STA ticket which has already been extracted from the client's ICA proxy request. How to use this snippet: See DC Article "Solution for Citrix Optimal Gateway Routing" for implementation. Code : ## ## Resolver iRule ## To enable detailed iRule debugging, set the static::debug_sta_rslv variable in the RULE_INIT event to 1 ## Updated July 14, 2021 by b.otlin@f5.com ## when RULE_INIT { set static::debug_sta_rslv 0 } when HTTP_REQUEST { if { [HTTP::has_responded] } { if { $static::debug_sta_rslv } { log local0. "HTTP::has_responded" } return } else { if { $static::debug_sta_rslv } { log local0. "HTTP::has NOT responded" } } set sta_request [expr {[HTTP::path] == "/f5apm/ctx-sta"}] if { $static::debug_sta_rslv } { log local0. "req is [HTTP::uri]" } if { $static::debug_sta_rslv } { log local0. "sta req is $sta_request" } if {!$sta_request} { # exit event if the request was not a STA request if { $static::debug_sta_rslv } { log local0. "sta_request does NOT exist, exit event" } return } else { if { $static::debug_sta_rslv } { log local0. "sta_request does exist, continue" } } sharedvar internal_ica_file_request if { [info exists internal_ica_file_request] } { if { $static::debug_sta_rslv } { log local0. "internal_ica_file_request exists...return 200 ok to SF APM with mod ICA info" } HTTP::respond 200 content \ "\[ApplicationServers\]\nApp=\n\[App\]\nAddress=;[HTTP::query]" \ "Content-Type" "application/x-ica" if { $static::debug_sta_rslv } { log local0. "unset internal_ica_file_request and exit event" } unset internal_ica_file_request return } else { if { $static::debug_sta_rslv } { log local0. "internal_ica_file_request does NOT exist, continue" } } if { [info exists sta_request_sid] } { if { $static::debug_sta_rslv } { log local0. "sta_request_sid is $sta_request_sid" } if { $static::debug_sta_rslv } { log local0. "insert MRHSession cookie = $sta_request_sid and X-F5-Client header" } HTTP::header insert \ "Cookie" "MRHSession=$sta_request_sid" \ "X-F5-Client" "citrix-launch" VDI::enable if { $static::debug_sta_rslv } { log local0. "enable VDI" } set internal_ica_file_request 1 if { $static::debug_sta_rslv } { log local0. "internal_ica_file_request set to 1" } SSL::disable serverside if { $static::debug_sta_rslv } { log local0. "disable SSL serverside" } virtual [virtual name] if { $static::debug_sta_rslv } { log local0. "go back to same VS" } } else { if { $static::debug_sta_rslv } { log local0. "sta_request_sid does NOT exist" } HTTP::header insert "clientless-mode" "1" if { $static::debug_sta_rslv } { log local0. "insert clientless-mode header" } } } when HTTP_RESPONSE { if { [HTTP::payload] contains "Address=;" } { if { $static::debug_sta_rslv } { log local0. "Response payload contains Address=; which denotes an ICA File" } set sta_address [HTTP::payload] regexp -line {^(?:[^;]*;){2}([^;]*)} $sta_address -> sta1 regexp -line {^(?:[^;]*;){4}([^;]*)} $sta_address -> sta2 set STA1 [class match -value -- $sta1 equals sta_dg] if { [info exists sta2] } { set STA2 [class match -value -- $sta2 equals sta_dg] ACCESS::session data set session.citrix.sta_servers "$STA1;$STA2" if { $static::debug_sta_rslv } { log local0. "STA from SF is $sta1 and $sta2 resolved to FQDN: $STA1 and $STA2 and adding to access session table" } } else { if { $static::debug_sta_rslv } { log local0. "STA from SF is $sta1 resolved to FQDN: $STA1 and adding to access session table" } ACCESS::session data set session.citrix.sta_servers "$STA1" } } else { if { $static::debug_sta_rslv } { log local0. "not an ICA" } } } when HTTP_RESPONSE_RELEASE { if { [HTTP::has_responded] } { if { $static::debug_sta_rslv } { log local0. "HTTP has_responded...exit event" } return } if {!$sta_request} { if { $static::debug_sta_rslv } { log local0. "sta_request does NOT exist...exit event" } return } if { [HTTP::status] == 200 } { if { $static::debug_sta_rslv } { log local0. "HTTP status is 200, remove Set-Cookie header" } # There is no need to expose this SID HTTP::header remove Set-Cookie } else { if { $static::debug_sta_rslv } { log local0. " HTTP status is NOT 200, remove access session" } # Remove session on failed STA resolution ACCESS::session remove } } when ACCESS_SESSION_STARTED { if { !$sta_request } { if { $static::debug_sta_rslv } { log local0. "sta_request does NOT exist...exit event" } return } else { if { $static::debug_sta_rslv } { log local0. "sta_request exists...continue" } } if { $static::debug_sta_rslv } { log local0. "sta_request exists so set 'session.external_sta_ticket' to 1" } ACCESS::session data set "session.external_sta_ticket" "1" } when ACCESS_POLICY_COMPLETED { if { !$sta_request } { if { $static::debug_sta_rslv } { log local0. "sta_request does NOT exist...exit event" } return } else { if { $static::debug_sta_rslv } { log local0. "sta_request exists...continue" } } set sta_request_sid [ACCESS::session sid] if { $static::debug_sta_rslv } { log local0. "sta_request_sid is $sta_request_sid" } } Tested this on version: 15.1Citrix ADC to F5 BIG-IP migration
You can use the free Citrix course eCNS-2017 under the training citrix site to do the reverse migration. They also have many CTX articles for irule to policy migration that can also be used for the reverse policy to irule/Local Traffic Policy. It will be nice if F5 also makes a migration tool as there is an unofficial script that is old https://devcentral.f5.com/s/articles/citrix-netscaler-to-f5-big-ip , so some official migration tool will be nice.
