I administer 2 environments that have multiple PCS appliance in each. One has three and the other four.I've been observing the following message in abundance:
Connection from IP XXX.XXX.XXX.XXX not authenticated yet (URL=/dana/js?prot=1&svc=4)
Upon investigation, I've discovered that these are user sessions that have tried to continue on an appliance that the sesssion was not initiated on. This is because, for one reason or another, the user's source IP changed. Since I use source IP affinity persistence, the session is considered new on the load balancers and sent to the next available PCS.
Has anyone else noticed this? If so, is there a better load balancing strategy than source IP persistence? I've looked at everything else but am very limited due to the IPSec traffic.
Hi nolanr, IP-based session persistance is very common and a recommended method. Can you share what you're using for load-balancing? Also, do you have any connection sets and session migration configured?
Also, you may want to ensure that you have session sync enabled in the Cluster Properties - see https://docs.pulsesecure.net/WebHelp/Content/PCS/PCS_AdminGuide_8.2/Configuring%20an%20Active%20Acti...
I'm sorry. I wasn't very clear at all. I am using the Network Connect client and all PCS are stand alone.
I forgot to mention we're using F5 load balancers.
After looking into this some more, it seems that the message is when a user tries to do something or click on a bookmark after the session is already gone. Say they've logged into a browser portal session, leave it there, the session is gone on the server, but they try to click on a link anyway. On first click, it tries to go to the server, then it redirects to the signed out screen. Can you check with one of the users? Or, you can also check that specific users log in time and compare it with the time you see the message - it may be way passed the session time you have configured.
That may be one way to generate this message but it is not in this case. I can track a user's session moving from one appliance to another when their source IP changes without the user logging off the original session. There is ultimately a session timeout message on the orignal appliance once the timer runs out.
I've been looking at a Citrix solution that addresses this problem. Radius load balancing with persistence. Unfortunately, the Radius, Load Balance, and VPN termination are all Citrix. I'm trying to use the concepts in my lab with Windows Radius, F5, and Pulse Secure. So far, no luck.
Hi - Nice troubleshooting and finding the actual root cause for your end-user symptom :-)
Some options to run past the LB vendor (sorry not a LB expert)
1. Does your LB offer any form of GSLB capability in addition to the source-ip persistence? i.e. Redirect users to the same PCS gateway not just based on source-ip but based on the geo location of their source IP? That way even if source IP changes it still detecting that the user is from a specific location is sending them to the same gateway.
If that is not an option you may consider creating multiple connections so end-users are directly hitting individual PCS devices. https://gateway1.domain.com, https://gateway2.domain.com
Its not ideal from usability however if the issue is occuring frequently and breaking access for your end users then it may be acceptable to degrade usability slighlty in favour of availability.