Issues with Web Authentication, when switched from LAN to WLAN
book
Article ID: 380111
calendar_today
Updated On:
Products
ISG Proxy
Issue/Introduction
Using proxy authentication in explicit mode for the network users. Users are facing issues with web authentication, whenever they switch from LAN to WLAN. The devices' network disconnects.
Device OS: Windows10 & 11
Environment
SG/ASG/ISG-Proxy
Resolution
The issue describing, where network users face authentication problems when switching from LAN to WLAN, can be linked to the behavior of the "Proxy" and "Proxy-IP" authentication modes on the Edge SWG (ProxySG). Here's how each mode might contribute to this issue:
1. Proxy Authentication Mode:
In this mode, the ProxySG authenticates users based on their session (browser or application) rather than their IP address. The user's authentication credentials are presented through the browser, and the session is typically maintained until the browser is closed or the session times out.
Issue on LAN to WLAN Switch: When users switch from LAN to WLAN, their IP address changes, which can disrupt the session-based authentication. The ProxySG may require re-authentication because it no longer associates the current session with the new IP address. Additionally, some browsers or applications might interpret this network change as a session termination, causing users to lose connectivity.
Potential Fix: You could try extending the session timeout settings for users in "Proxy" authentication mode or enable session persistence across IP changes. This ensures the user remains authenticated across minor network changes (LAN to WLAN).
2. Proxy-IP Authentication Mode:
In Proxy-IP mode, the ProxySG associates the authenticated user with their IP address. This is useful in environments where the same IP address remains consistent throughout a session, such as in a stable wired connection.
Issue on LAN to WLAN Switch: When a user switches from LAN to WLAN, their IP address changes, and the ProxySG no longer recognizes the user as authenticated since the IP binding is lost. This forces re-authentication and potentially drops the user’s session, resulting in network disconnection.
Potential Fix: The key issue here is the IP address change, which is inherent to the Proxy-IP authentication mode. A possible fix is to move away from Proxy-IP mode and use a session-based authentication method (like "Proxy" mode) that isn't tied to the user’s IP address. Alternatively, you can configure shorter re-authentication intervals or use transparent authentication methods like Kerberos to minimize the disruption caused by an IP address change.
General Solutions:
Persistent Sessions: If the network allows, consider configuring persistent sessions or "sticky sessions" across both LAN and WLAN networks. This ensures users maintain a stable session regardless of which network they are on.
Kerberos SSO: If possible, enabling Kerberos Single Sign-On (SSO) can help because it authenticates users based on their identity rather than their IP address. This method is less susceptible to network changes.
Fallback Authentication: If authentication fails due to a network switch, you can configure the ProxySG to automatically prompt users for credentials again, minimizing the impact of disconnections.
Investigating logs for more detailed failures on the ProxySG can also help clarify how the device handles the switch from LAN to WLAN in terms of authentication.
