Context-based app routing and resource location 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 the access policies using routing exceptions. 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:
- Define a new access policy specifically for Group B users accessing the Office 365 app.
-
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.
-
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:
- Edit the access policy associated with the Jira application to accommodate the new routing requirements.
- Within the access policy, enable the Routing exceptions option.
- 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
- Create or edit an access policy. For details, see Create access policies.
-
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.
- Click the edit icon next to the domain for which you want to modify the routing type.
-
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.
- External via Google Secure Gateway: The traffic flows to the internet through the Google Secure Gateway.
Note:
This routing type applies only to SaaS apps for customers integrated with Google Chrome Enterprise Premium in Secure Private Access cloud and hybrid deployments.
-
Internal: The traffic flows via the Connector Appliance.
-
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.
- 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. For details, see Session policies.
Contextual routing insights in Monitor
Contextual routing can lead to dynamic changes in application routes. For instance, an application might be routed through the Secure Private Access service when the user is outside the corporate network, but directly to the app when the user is internal. Providing administrators with visibility into these routing decisions is crucial for troubleshooting routing issues.
The Application Topology page in DaaS Monitor provides comprehensive insights into routing decisions and policy details of the Secure Private Access applications accessed through the Citrix Secure Access client. These insights enable the administrators to troubleshoot routing issues efficiently and thus enhance the user experience.
The following details related to application routing are captured in the Application Topology page:
-
Routing context: The Routing context field in the About section specifies the policy type (access policy, session policy, or application domain) applied during routing. The routing context helps identify the precedence hierarchy (access policy > session policy > default application configuration) influencing routing decisions.
For session policy, the View details link provides additional details about the session policy.
-
Action-routing: The Action-routing field in the Policy Evaluation section displays the routing path (Direct, Internal via connector, Internal via gateway) that a user’s request takes through the Secure Private Access service.
Note:
When the default application domain (application configuration) routing is applied, the Policy Evaluation section displays the policy details but the Action-routing field displays the value n/a as no policy is enforced in this scenario.
The following figure displays a topology diagram of an application whose routing type is defined as direct and hence the traffic does not pass through the Secure Private Access service.
Note:
For the Web apps tunneled through the Citrix Secure Access client, the topology diagram displays the resource location name and the connector name.
The following figure displays a topology diagram of an application whose routing type is defined to be internal through the Secure Private Access service using a connector.
For more information, see Integration with DaaS monitor.