Script Errors when using SSO on VPN (Google)

[nzmatto1]

I have recently set up Google SSO authentication for the Checkpoint Client VPN (Endpoint and Mobile). On first connection from a new client we are getting 4 script errors, which ask if we want to continue to run scripts on the page. I can click yes to them all and the VPN establishes, and from then on the VPN works fine. I would like to fix these prior to rolling it out to my end user community. Has anyone else faced these or does anyone know the resolution?

I get error 1 and error 2 prior to the username being requested, error 3 after the username and before the password, and error 4 after the password and before the Google 2-Step Verification. 

I suspect I need to log a TAC case for this, but thought I'd check if others have also seen these errors. 

[PhoneBoy]

What is the default browser used by your clients?
Looks like the IDP login is using Internet Explorer which probably worm’s work.
In trac.defaults on the client, you can specify idp_browser_mode to use the default browser.
It’s mentioned in a different context here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
You can even preconfigured it as part of the install: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[nzmatto1]

The default browser is Google Chrome. 
I'll follow the instructions provided and see if I can build a package to sort it and will post details back here. Thanks. 

[nzmatto1]

I built a new package, which is excellent as it means I can include my VPN site and connection preferences in the configuration. I changed the IDP_Browser_Mode from embedded to default_browser, which resulted in google chrome opening when attempting to connect to the VPN. This is not the desired behavior, and it errored out too due to popups being blocked. I reverted that back to embedded. 
one of the instructions said to Edit the Trac.defaults file and set the parameter predefined_sites_only to the value true. This worked pretty good but we have users who connect to several different VPN's and need to be able to add their own, so I reverted that change too. 
The net of this is I have a great installation package which is very simple for my userbase, however it does have the annoying script errors on first connection still. 

[PhoneBoy]

At least according to another thread, the "idp_browser_mode" setting is not yet supported (planned for 2023).

[nzmatto1]

Nice....well...it works, and it sure changes stuff. I suspect the 2023 update will permit different source browsers to be used inside the client window at logon time. That kind of makes sense, and it's probably the ''embedded browser'' (probably an IE window) which is generating the script errors. 
I think I'll talk with the powers that be about just accepting them for now as this one is only for a small number of users. Here's hoping I don't come across issues like this with the seemingly more advanced Azure AD one. I'll be building that for a much larger group of users at another site very shortly.
Thanks for your help and comments @PhoneBoy  

[nzmatto1]

As a follow up to this, The solution is using SAML via Google Cloud. The embedded browser makes calls to IE on Windows based machines and this is the only place the script errors happen (IE DUH!). When using Apple, it makes calls to Safari. 
For us changing the idp_broser_mode from embedded to default_browser has worked almost perfectly. It's working great for Chrome, Firefox and Edge. Those options along with Safari for Mac users cover the vast majority of our userbase. 
Of note, and slightly weird, the Chromium based Brave browser goes through the login process, but never actually connects. This is not an issue to me as I have simply told my one Brave user not to be so brave. 🙂 
I do still have a TAC case open for the calls being made to IE, but they are not achieving anything yet as it seems they are still focused on this being a configuration issue at the client end as opposed to there being any possible issue with the dumb fact that it's making script calls to a 20+ year old browser engine that doesn't support the script calls being made. 
I have now also deployed a similar solution on another major site using the Azure SSO connection. This works perfectly within the embedded window, so there is something quite different between the way the embedded window is working to Azure compared to GCP. 
All in all, I'm pretty happy with the deployments, and the enhanced security being offered through MFA is great.  

[PhoneBoy · Accepted solution]

idp_browser_mode is supported on Windows from E87.30 client version.
See: https://support.checkpoint.com/results/sk/sk180726