Users accessing certain Web applications via Cloud SWG repeatedly asked to login
Article ID: 370397
Updated On:
Products
Issue/Introduction
Users accessing Web Applications via Cloud SWG using Proxy Forwarding access method.
Certain Applications repeatedly asking users to login when clicking application links, after initially providing valid credentials and getting successfully logged in.
HAR files from the user agent seeing the issue show that a session cookie is set after the initial login, but subsequent requests with the newly set session cookie trigger responses from the Application where the session cookie is expired (expiration time set to January 1 1970).
Some of these users, running the WSS Agent from remote locations, never see the symptoms when accessing the same application remotely.
Environment
F5 load balancer fronting multiple on premise Proxy servers.
Proxy servers configured to forward traffic into Cloud SWG passing in user, group and IP address information.
Cause
Application performing check on cookie and IP address associated with cookie.
Lack of persistence on the F5 load balancer causing egress IP address in path to change.
Resolution
Enable client IP persistence from the F5 load balancer so that all user request end up on the same on premise proxy server; also make sure that the on-premise proxy server forwarding configuration has persistence enabled per the documented best practices.
In the above scenario, the F5 load balancer had no persistence enabled. Requests from a specific host could then be sent to a number of different on prem proxy servers, each forwarding into Cloud SWG from a different egress IP address. Each Cloud SWG Proxy in turn would send the request to the OCS, but from a different egress IP address.
The back end Application would see a valid session cookie, but the IP address it had stored (at authentication time) did not match the egress IP address of the current request and the session would be invalidated.
Certain applications can disable IP address validation within the session which could also be a potential workaround, but ideally the user should always hit the same on premise proxy to avoid doing this.
Additional Information
Main reason the client IP persistence was disabled on the F5 originally was due to the fact that shared VDI environments existed
Analysing these shared VDI environments, they each handled a certain number of users per IP address reducing concerns over unbalanced traffic.
After enabling client IP persistence, the F5 team monitored the load balancing across the proxy servers and found that it was well balanced. It was possible to manually balance the user traffic from the F5 if needed by manually removing entries from the persistence table.
Feedback
