Context-based app routing and resource locations selection

When an app is configured, the app URL and related domains are assigned to a routing type and resource location. This is done during app configuration. This configuration for app routing and resource location then applies to all users who have access to the app. But there might be scenarios such as the following:

• An admin wants to route the same app differently for different users. For example, an internal app URL must be routed externally for a few users to prevent traffic from being routed to the Secure Private Access service.

• There is a need to use different resource locations for different users to route requests to the optimal data center to improve performance.

This can now be done within Access Policies using the Routing Exceptions feature. The routing exceptions configuration in the access policy allows admins to edit the internal routing type per URL or resource location based on the user context. Because this setting is within the access policies, it applies only to the users that are part of that access policy only.

You can also dynamically route entire sessions using session policies. For details, see Route internal corporate users directly to back-end applications.

Note:

If there is a routing and resource location configuration within an access policy, then it overrides the app configurations.

The following examples demonstrate the routing exception use cases.

• Context-based routing
• User context-based resource location selection
• Route internal corporate users directly to back-end applications

Use case: Context-based routing

Scenario:

• Group A users: Employees of company ABC who access the Outlook app and Microsoft Teams app through Secure Private Access that is routed internally.
• Group B users: Employees of a third-party company working with ABC. They access certain applications (excluding Outlook) through Secure Private Access. They also have their own Outlook application accessed over the internet and do not want to route their Outlook traffic through Secure Private Access.

Problem:

• Group B users log in to the Secure Access Agent to access ABC apps.
• Their requests to access Outlook through their native browser are routed through Secure Private Access, resulting in access denial.
• The destination domain for the Outlook application is the same for both Group A and Group B users.
• The access policy allows access only for Group A users, causing access denial for Group B users when they try to launch Microsoft Teams or Outlook.
• Group B users cannot access their company Outlook because of this routing issue.

Solution:

The ABC company admin can make the following configuration changes to resolve this issue:

1. Define a new access policy specifically for Group B users accessing the Office 365 app.

2. In the access policy, enable the Routing exceptions option.

   The admin can view the list of all URLs and related domains of all internal apps associated with the access policy.

3. For all Office365 app URLs, configure the routing to happen externally.

   This ensures that Group B users’ requests to access their Outlook application are routed over the internet, bypassing Secure Private Access.

   By implementing these changes, Group B users can access their company Outlook application over the internet without being routed through Secure Private Access, while still maintaining access to other ABC applications as needed.

Use Case: User context-based resource location selection

Scenarios:

• Company XYZ: It has two sets of users located in the US East Coast and the US West Coast.
• Data centers: Two data centers, one on the East Coast and one on the West Coast, both hosting the same Jira application.
• Objective: The admin wants to route the access requests of end users to the selected resource locations based on user context (geo location, network location, user name, and user group) to ensure optimal performance and routing.

Solution:

1. Edit the access policy associated with the Jira application to accommodate the new routing requirements.
2. Within the access policy, enable the Routing exceptions option.
3. Modify the resource locations per user context.

The admin can ensure that user requests are routed to the optimal data center based on their context, thereby improving performance and managing routing effectively for all users in the company.

Steps to change the routing type or resource location

1. Create or edit an access policy. For details, see Create access policies.

2. In Step 3: Action page, enable the contextual routing domain configuration by sliding the Routing exceptions toggle switch. The Routing exceptions toggle allows you to edit the resource locations and routing information for domains of the applications added in the access policy.

   • When the toggle is ON: A list of all the apps’ URLs and related domains is displayed in a tabular format along with their global routing and resource location configuration. This list contains the URLs and related domains of all the applications added in the access policy. You can click the edit icon next to a domain to modify its resource location and routing type. This routing exception is applicable to all the users in the access policy only.
   • When the toggle is OFF: Existing routing exceptions for the domains are removed and are not applicable. End users are routed based on the global configuration set during the application setup only.

   

3. Click the edit icon next to the domain for which you want to modify the routing type.

4. In Routing type, modify the routing type:

   • Internal: The traffic flows via the Connector Appliance.
     • For a web app, the traffic flows within the data center.
     • For a SaaS app, the traffic is routed outside the network through the Connector Appliance.
   • Internal – Bypass Proxy: The domain traffic is routed through Citrix Cloud Connector appliances, bypassing the customer’s web proxy configured on the Connector Appliance.
   • External: The traffic flows directly to the internet.

5. In Resource location, modify the resource location, if necessary. This option is applicable only for the internally routed domains.

   Note:

   If an app is created using an IP address, you cannot modify the routing type to External as only the Internal via Connector option is displayed in the Routing type list. You can only modify the resource location. However, this restriction does not apply to apps created using an FQDN.

   

6. Click Save.

Note:

• You can only change the routing and resource location, but cannot add or delete routing domain in the routing table.
• If you delete a domain that has contextual routing enabled from the main routing table, the domain is not deleted from the Routing exceptions table within the access policy. This means that the contextual routing configuration for that domain remains intact in the access policy.
• If you delete an app that has contextual routing enabled, then the domain is deleted from the Routing exceptions table within the access policy. This means that all contextual routing configurations associated with that app are removed from the access policy.
• The selected related domain overwrites the default setting when the condition meets for the users that are part of this access policy. Otherwise the default routing is applied.
• If the routing is not modified or if the Routing exceptions feature is not enabled, the routing happens based on the default settings in the main routing table (Settings > Application domain).

Use case: Route internal corporate users directly to back-end applications

Admins can configure session policies to route internal corporate users directly to back-end apps without tunneling traffic through Secure Private Access. Session policies offer dynamic routing based on factors, such as network location and device posture.

Note:

• Session policy settings are applied at the session level to all applications rather than being tied to specific applications.
• Session policies can be assigned to all users or a subset of users.

Routing precedence

Session policies work alongside access policies, with access policies taking precedence if there is a conflict. In such scenarios, access policy routing exceptions override session policies. If neither an access policy nor a session policy is configured, global routing settings (Settings > Application Domain) apply.

Supported Citrix Secure Access clients

The following versions of Citrix Secure Access client support routing of users directly to back-end applications.

• macOS - 24.11.1 and later
• Windows - 24.11.1.17 and later. Also, the EnableContextualAccess VPN client registry must be enabled. For more information, see NetScaler Gateway Windows VPN client registry keys.

Example use case

Scenario:

In an organization, when users are connected to the corporate network “corporate_network1”, then traffic from apps must flow directly to the back-end apps, as these apps are directly reachable on the corporate network. If the users are outside the corporate network, then the app traffic must be tunneled.

Solution:

1. Add app1, app2 with routing set to Internal via Connector.
2. Add an access policy for the apps (app1, app2) to grant access.
3. Add a session policy to configure conditions to specify the user group and network locations that must be considered when granting access.
4. Select the User condition and set it to All users.
5. Add a Network Location condition. Set it to Matches any of and specify the network location “corporate_network1”. This ensures that traffic coming from “corporate_network1” flows directly to the back-end apps.

You can also enable routing exceptions for this scenario. For example, if app1 must always be tunneled even on the corporate network, then routing exceptions can be configured for domains of app1 in the access policy. When this is done, the routing exception takes precedence over the session policy.

Configure direct routing within the corporate network using session policies

You must create a session policy to enable users to directly access the back-end applications bypassing the Secure Private Access tunneling. To do this, first, you select the users to which this policy must apply. Second, under ‘Network Location’ select the name of your corporate network. This is an important step to make sure that Direct Routing is only enabled when the user is inside your company’s corporate network.

1. Navigate to Policies > Session Policies and click Create Session Policy.

   

2. Enter a name for the policy and a description of the policy.
3. Select the users and the conditions for which you want to apply these settings.
4. You can select the condition to apply to all users or specify a subset of users.

5. (Optional) Click + to add multiple conditions based on the context.

6. Define the Network Location condition to enable dynamic routing for the entire session. This confirms that direct routing is enabled only when users are inside the company’s corporate network.

   When you add conditions based on a context, an AND operation is applied on the conditions wherein the policy is evaluated only if both the users and the optional contextual-based conditions are met. For details on the conditions, see Configure an access policy.

7. Select Direct routing to route all users externally to the back-end applications.
8. Select Enable policy after creation. If you do not select this option, the policy is only created and not enforced on the applications. Alternatively, you can also enable the policy from the Session Policies page by using the toggle switch in the Status column.
9. Click Save.

Note:

Network location changes trigger session policy refreshes and this might impact the end clients as follows:

• Citrix Secure Access agent: Policy refreshes might alter routing configurations and hence impact application access.
• Citrix Enterprise Browser: Policy refreshes occur every 30 minutes. Users must restart the browser or wait for the refresh to access applications.