3 min read
Most legacy VPNs have a global timeout setting that requires end users to log in every X hours or resets VPN profiles at a certain frequency. By doing continuous identity evaluation, a Zero Trust security model eliminates the need for most of the user-interrupting workflows triggered by session timeouts. However, there can still be valid reasons to want users to reauthenticate, either on a recurring basis or to access specific, highly-sensitive or regulated internal services.
To enforce WARP client reauthentication, you can configure WARP session timeouts on a per-application basis in your Gateway network policies. When a user goes to a protected application or website, Cloudflare checks their WARP session duration against the configured session timeout. If the session has expired, the user will be prompted to re-authenticate with the identity provider (IdP) used to enroll in the WARP client. A user’s WARP session duration resets to zero whenever they log in to the IdP, regardless of what triggered the authentication event.
Configure WARP session timeout
You can enforce WARP session timeouts on any Gateway Network and HTTP policy that has an Allow action. If you do not specify a session timeout, the WARP session will be unlimited by default.
To configure a session timeout for a Gateway policy:
- In , go to either Gateway > Firewall Policies > Network or Gateway > Firewall Policies > HTTP.
- Add a policy and select the Allow action. Alternatively, choose any existing Allow policy.
- Under Step 4 - Configure policy settings, select Edit next to Enforce WARP client session duration.
- Enter a session expiration time in
1h30m0sformat and save.
- Save the policy.
Session checks are now enabled for the application protected by this policy. Users can continue to reach applications outside of the policy definition.
To set a global reauthentication event, similar to a global timeout on a traditional VPN, we recommend setting all of your Gateway Network Allow policies to the same baseline WARP session duration (typically between 3-7 days). This will ensure that whenever your user tries to access any application on the private network within that window, they will be forced to reauthenticate with your identity provider when they have not logged in for your chosen number of days.
If a specific application requires a more stringent reauthentication timeline, users accessing that application will not have to complete the baseline reauthentication event because they are already in compliance with the baseline policy.
When configuring a global WARP session duration, a common mistake is to build a single policy that covers your entire private network range. An example would be an Allow policy that requires reauthentication every 7 days for all users with traffic to a destination IP in
10.0.0.0/8. This type of global policy may result in a suboptimal user experience because an expired session blocks the user from the entire internal network (including private DNS functionality) instead of specific applications. If a user misses the one-time reauth notification, they may not know that they need to manually go into their WARP client settings to reauthenticate.