Jump to content
Welcome to our new Citrix community!

Citrix Netscaler Gateway plugin upgrade


Arne Van Deun

Recommended Posts

I am having the following issue:

 

When users try log on to the SSL VPN gateway plugin they get the "version upgrade" message. 

 

This behaviour is only happening when the user is not part of one of the preconfigured aaa groups on the ADC. The user is present in AD and is successfully authenticated.

 

I disabled the upgrade the "Windows Plugin Upgrade" setting in the session policy of the vserver.  Aswell as on the Global Citrix Gateway settings. 

 

I seems that when the group extraction is done (user is authenticated to AD) and no policy can be found for the groups where the user is part of a fallback is triggered ( global settings?) where this "upgrade version" is still configured. 

 

We don't want users to upgrade the plugin if they are for some reason not part of the correct aaa group however it is my understading of the Citrix Documentation that there are only 3 ways to configure this:

 

- On the session policy ( however the user is not referenced to any aaa group where a session policy is bound)

- On the global Citrix Gateway settings page

- On the virtual server settings page under " EPA plugin upgrade". 

 

We are running 13.0.58.32 on the ADC and 47.24 on the client.

 

Anyone any idea's? 

Thanks in advance.

 

 

Link to comment
Share on other sites

8 hours ago, Arne Van Deun said:

I seems that when the group extraction is done (user is authenticated to AD) and no policy can be found for the groups where the user is part of a fallback is triggered ( global settings?) where this "upgrade version" is still configured. 

 

For this first part, IF you have session policies bound to GroupA and GroupB that is preventing upgrades. But when the user is in a fallback scenario (or quarantine setting), and then upgrades are allowed, the issue is either your global default parameters allow upgrade OR the default session policy on the vpn vserver applies.

 

For example:  (Note are regarding the advanced policy engine; not classic policies as they are 1) deprecated and 2) deal with how priorities and bind points govern precedence differently.)

if the vpn vserver: default policy 100

and then GroupA policy1 10

and then GroupB policy2 20

 

If a GroupA  user logs on, and there is a conflict in GroupA vs. the default settings on the vpn vServer, GroupA wins where there is a conflict (in classic engine, the priority determines this; in advanced engine, group overrides vserver).

If A GroupB users logs on, then GroupB policy will override any settings inherited from vpn vserver.

 

But if a user in GroupC logs on and doesn't get any group level settings than the vpn Vserver policy would apply. If none, there, then the default parameter.

 

So if you have a fallback scenario involving a quarantine group, the user may be getting policies from the quarantine group at a higher priority than other groups (or the vpn vserver) and this policy doesn't match what you expect.

Or you have a scenario where a GroupC user gets no group level policies and gets the default vpn vserver or global settings.

 

Without more info on the policy settings, bindings that you are using it would be hard to clarify.

 

So, you need to think about what you want the default policy on the vpn vserver (or global parameters) to assert, for users who fall into no other scenario. OR we need to move users to a quarantine group in this scenario that gets its own settings.  Which policy config you need, depends on what different scenarios you need to accomodate (like when upgrades ARE allowed vs NOT) and then coming up with the correct policy expressions, bind points, and policies.  If you don't want anyone on this vpn vserver to  upgrade, then updating the default policy on the vpn vserver would take care of the exception cases.

 

(If the above doesn't make sense, I'll try to rewrite to clarify. Or share which filter/bind points you are currently using and when you want upgrades and when you don't for a more specific recommendation.)

 

 

Other notes on both preventing updates and other policy examples below (as more generic considerations). 

 

VPN Vserver and Firmware:

 

So, one of the issue might be if the version of the VPN client (which I think you said was 13.0.47.24) is required to upgrade to the gateway version you are on (13.0.58.32).

 

In the past, the vpn client had to exactly match the ns firmware in use. So if the vpn client and ns firmware were different you would have to upgrade (or downgrade) when versions differed.

The prevent upgrade option except for required upgrades, allow you to limit upgrades when the client and firmware HAVE to match, but allows some variance.  But, upgrades are still needed.

If no upgrade is enabled, then you might have a failed connection.

 

Because you are using the EPA plugin, the end point analysis is handled by the gateway vpn client OR by the standalone epa plugin. So you now have one more component that has to match.  Which likely means, that even if the vpn plugin didn't require an update to run on this firmware, the epa client does which is driving the update.

 

You would likely have to confirm with support which versions don't require updates (as I'm not sure that is actually documented in the gateway docs clearly).

 

But the EPA settings are probably driving this. If you don't require the epa settings, then you might have more tolerance.  But this might be a version combination where updates are required.    In this case, you probably can't get a policy to prevent the upgrade without resulting in a possible connection failure.

---

Regarding Policy config:

 

However, if the issue is that this client DOES NOT need to upgrade to match the firmware you are on (which you may need to do additional testing to confirm) and you want UPGRADES off for members of this AAA group but not others.

 

If using the ADVANCED session policies:

session_pol1_noupgrade:  Configure with the necessary OVERRIDE enabled and NO WINDOWS client upgrade and use the session policy expression http.user.is_member_of("<groupA>")

(or the aaa.user.is_member_of("<group>") expression)  And be sure this policy is higher priority than the other in case of overlapping group memberships.  So priority 10 and bind the the vpn vserver.

 

session_pol2_upgradeallowed:  Configure this policy  with the necessary OVERRIDE enabled and Windows Upgrade:allowed setting.  use expression true and bind this to the same vpn vserver at a lower priority 100.

 

vpn_vserver_demo

- session_pol1_noupgrade:  <group filter> and priority 10

- session_pol2_upgrade:  true and priority 100

 

If you are using the CLASSIC engine, then the session policy to prevent upgrades would be bound to the AAA Group (GroupA) AND it must have a higher importance (10) binding than the policy for upgrades allowed at the vserver level (vs 100).

 

In the classic engine, if policies are applied to AAA Group and vpn vserver, then the priority determines precedence (not the bind point).   (Short explanation).

 

Bottom line:

- If the prevention of the upgrade is solely based on policies, then getting the right expression, bind point, and priorities are required.

- If the upgrade is required because of the combination of vpn vserver/epa client, and firmware in use, the policy may not matter and you either upgrade and it works or you prevent upgrades and it may not function.

 

 

 

 

 

 

 

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...