Listen Policy

Contributed by Magnus Esse

Overview

Listen policies were initially a way of simulating multi-tenancy using "shadow vservers." If the requirement is to isolate different network paths from each other, the recommended way of doing that now is to use Admin Partitions.

There are other situations when the usage of listen policies can be helpful, and some examples of when it might be worth considering using them will be covered here.

Listen policies are configured on a virtual server level. Load Balanced (LB) vserver, Content Switched (CS) vserver, and Gateway vserver are where I have seen them used. When configuring a listen policy for a virtual server, it can use the same IP, port and protocol as another virtual server. It is possible to have several virtual servers sharing the same IP with different listen policies, the listen priority will tell in which order the policies should be evaluated, and the listen policy getting hit first will decide which virtual server should be used. If there is one virtual server without any listen policy, it will be used for all traffic not evaluated true in any of the listen policies.

Example 1:

In this scenario, you have a service that should only be accessible from certain clients. If a client that is not allowed tries to connect to the virtual server, the ADC will not answer the client connecting at all, and thus the connection will fail.

Example 2:

In this scenario, you have a service that is using a AAA vserver for authentication, but there are some specified IP addresses that are to be excempted from the authentication. You can set this up with the help of a content switch if you want, however, you can also use listen policies.

Use Case Example:

In this scenario, third-party users are allowed to connect through Citrix Gateway to be able to work remotely. If a user leaves the other company, it might not be communicated quickly that the user has left. In this case, that user will still be able to connect through the Citrix Gateway service and still have access. One solution to minimize the risk is to enforce all access by third-party contractors from the same source IP within a specified range that corresponds to the expected IP for the third-party company. The reasoning is that the third-party company will revoke access to their company network even though they might forget to inform their customers that the user has left their company. By forcing all third-party contractors to access from known addresses, the risk can be minimized considerably.