01-11-2022 11:12 AM - edited 01-11-2022 11:23 AM
The client always seems to try the cookie first if it exists (at least in my testing, not sure if there is an GP client auth flowchart around). So if you have cookie gen in Gateway, then whenever the GP client successfully auths to the gateway it will get a new cookie. When the GP client tries to reconnect to the gateway either because of network disconnect, timeout, or VPN expiration, the client will try to reconnect to the gateway using the cookie. If that succeeds it gets a new cookie generated. If that fails it will try other auth methods. When the client tries to reconnect to the portal (every 24 hours by default I believe), it will also try to use the same cookie from the gateway for auth. Since you don't have accept cookie on the portal, that will always fail.
From the System logs, you should be able to see where the portal and gateway are specifically generating/allowing/denying the cookie. Pay close attention to the Event field, it may be globalprotectportal-... or globalprotectgateway-..., but it all seems to blur together when I quickly look at it.
( subtype eq globalprotect ) and ( description contains 'cookie' )
There is a cookie lifetime on the portal and gateway auth override, but that seems to apply to the portal/gateway acceptance, the cookie seems to have an infinite lifetime on the client. Once given a cookie, the client will always try to use it until rebooted (I haven't found documentation or fully tested this, but it seems like what is happening).
