Jump to content
Welcome to our new Citrix community!

Advice with Session policy expression for Full SSL VPN

Recommended Posts


was hoping for some guidance on any possible expression other than "true" or ns_true for setting up a session policy for Full VPN session, clients used are  Citrix SSO App for MAC and Gateway plugin for Windows


The Netscaler version used is


The ns_true expression works but want to explore if we could setup something specific as the ones available for Browser / Receiver


Thank you


Link to comment
Share on other sites

You can use advanced policy expressions with session policies depending on what criteria you are looking for.

client object can be used for ip/port filters among other network criteria.

http object can be used for web request filters. One method of browser filters is http.req.header("user-agent") .  The gateway wizard will create default policies to filter gateway session policies based on full vpn or receiver connections and examples of this can be found in the gateway admin guide.

Some filter examples are here:  https://support.citrix.com/article/CTX124937

And others here:  https://docs.citrix.com/en-us/citrix-gateway/current-release/storefront-integration/ng-clg-session-policies-overview-con.html


For EPA/OPSWAT scans, for the advanced policy engine as pre-authentication policies, you will need to incorporate AAA authentication vserver and advanced authentication policies.


If you need more specific details, feel free to clarify.


(These examples are in second link above)

If your gateway accepts both users who should connect with Full VPN and those who are doing ICA Proxy only, then you would need expressions like this:



Whereas receiver (services) or ica proxy users, typically look like this:

REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer EXISTS   #web client


REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver && REQ.HTTP.HEADER X-Citrix-Gateway EXISTS   # services client 


To filter on MAC specifically, using just the session policies, you would need to base it on a user-agent header.

Or to do an EPA/OPSWAT scan, will be more challenging at this point.


IF your question is about the session profile,

If your Published Apps tab:  ICA Proxy:ON and your storefront settings are defined, you will be mostly an ICA Proxy connection.

If you have ICA Proxy:OFF, and no storefront url defined, then you are mostly in VPN mode and the network connections tab and client settings tab will govern the vpn behavior, split tunnel, and sso behavior.  You may also need Traffic Policies for more in depth SSO configuration and/or appropriate AAA nfactor policies.






Link to comment
Share on other sites

Hi Rhonda,


Many thanks for the quick response


Yes, the gateway is configured for 

1)Full SSL VPN for accessing specific Intranet applications 

Expression: ns_true , 

Priority: 50

2) ICA proxy users (Web Client) accessing Storefront apps/Remote PC

Expression (REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer EXISTS)


3)  Mobile /Receiver users  

Expression: REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver && REQ.HTTP.HEADER X-Citrix-Gateway EXISTS



Ill test with the expression REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer NOTEXISTS for VPN users  and check , just need to ensure it doesnt conflict , the policy evaluation is based on AAA groups and there are users who could be in both groups


Link to comment
Share on other sites

Glad you can test and hope it works.

NOTE:  Based on your example above:

Because you are in the CLASSIC engine, the priorities trump bind points on precedence.

So based on your priorities, your policies evaluate from most important to least:

[3] mobile/receiver users (priority 40), then [1] ssl vpn policy (priority 50), then [2] ICA Proxy users (priority 60)


If a user fell into overlapping criteria.  Not sayin they would for proxy vs mobile, but your proxy users are being overridden by anything in the ssl vpn policy with these priorities.

Classic vs. Advanced engine deal with priorities and bind point precedence different from each other. And the classic always had some surprises (advanced makes more predictable sense).


Classic engine: (in brief for gateway)

- without priorities, bind point precedence is aaa user >> aaa group >> vpn vserver >> global  (most to leat important)

- with priorities, you ignore bind points and the priorities are the sole determining factor of importance as the priorities span bind points. You can basically, change the processing order by manipulating the policies (for a given category such as session policies) regardless of bind point.  If a user is in multiple groups (which are equivalent tiers), the priority resolves which group membership is most important.


Advanced engine (in brief for gateway)

- priorities work within the bind points; and bind point precedence is absolute aka doesn't change.

- When the gateway session policies moved to advanced engine, the predictable way is the result that aaa user >> aaa group >> vpn vserver >> vpn global (most important to least).  Priorities organize things within those bind points. If a user is in multiple groups (which are equivalent tiers), the priority resolves which group membership is most important.


Examples below to help.


Policy and Priority Notes follow:

If users appear in BOTH groups, then your priorities will determine which policy aka group membership is MOST important, otherwise the order AD returns the group enumeration would do this.


So if 

a user is in GROUPA and GROUPB

and you want to ensure the PolicyB setting always wins...


For classic engine, you would bind the session policies to the AAA Groups and use the priority to guarantee the conflict resolution AND (make sure goup priorities are more important than vpn vserver policy priorities to override). 

vpn vserver:  policy_vpn_baseline at priority 100 (example)

GroupA: policyA at priority 20

GroupB:  policyB at priority 10


This would mean, that either Group policies at priority 10 or 20 are more important than policy on vpn vserver at priority 100.

If a user is a member of both GroupA and GroupB, then the policyB is more important at priority 10, then the one on GroupA at priority 20.


(And you are using Classic engine above, so the above statements apply to you.)



If you were on the ADVANCED policy engine (for all session policies at vpn vserver AND group levels), 

- The difference is policies bound to AAA Group are automatically more important than session policies on vpn vserver (regardless of priority); but you would still need to make sure if a user had overlapping group memberships that the most important group had the higher priority.

- But to make your life easier, you can also bind the policies to the vpn vserver and use the group filter and just organize them on the vpn vserver... example:

vpn vserver:

session_pol_baseline: true:  Priority 100 # as baseline

session_pol_groupAstuff:  http.req.user.is_member_of("GroupA"):  Priority 20

session_pol_groupBstuff:  http.req.user.is_member_of("GroupB"):  Priority 10


Then all the policies would be bound on the vpn vserver, and much easier to filter policies by group AND set priorities without binding policies to the group separately.

above priorities would result in:

session_pol_groupBstuff overriding session_pol_GroupAStuff overriding session_pol_baseline (follow the priorities)

If a user was in all 3 categories.


On the most recent adc firmware, the expression may have changed from http.req.user to aaa.req.user, but same concept.













Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...