SAML authentication stops working after FW Upgrade / Fresh Install

[Thomas_Eichelbu]

Hello Check Mates, 

we have seen on three occasions that the SAML authentication method fails for Client VPN after upgrading to a new Jumbo or reinstalling the gateway from scratch (fresh install).
Reason for our fresh install was to get rid of the ext3 filesystem which we have on very old and long running firewalls.

since we rely on special custom hotfixes we are stuck to run at R81.10 HFA 110

we get this error message:

x

The error lookalike depends on how the embedded browser is built into the VPN Client, sometimes its the full browser which shows and error, sometimes the browser is embedded into the VPN client itself.

It is very hard to restore the SAML login option.
Its more like a guessing game to remove the SAML authentication from the gateway, push policy again and adding SAML again. or do many reboot or fail overs. I cannot really say what brings it back ... its more a random success to have the SAML portal working again.

anyone from the audience has seen this before?
since it struck us 3 times now, i think there is indeed a systemic reason behind it.

after some discoveries i found some interessting hints:
i see way too little Multiportals running ???

active member with broken SAML portal	working member set to standby to check behavior
[Expert@XXXY1:0:ACTIVE]# mpclient list DLPSenderPortal SecurePlatform UserCheck nac nac_transparent_auth saml-vpn	[Expert@XXXZ2:0:STANDBY]# mpclient list DLPSenderPortal ExchangeRegistration ReverseProxyClear ReverseProxySSL SecurePlatform UserCheck nac nac_transparent_auth saml-vpn sslvpn

when i check if the paths for the SAML portal do exist ... i get disappointed on the newly installed active member they missing, also some directories are not there.

path is: 
https://XXXXX.ZZZZ.com/saml-vpn/spPortal/ServiceProviderTabs?realm=vpn_XXXXX_SAML&session=6i7hz9koxb...



[Expert@XXXY1:0:ACTIVE]# find / -name ServiceProvider\*
/opt/CPSamlPortal/htdocs/spPortal/ServiceProvider
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/htdocs/spPortal/ServiceProvider
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php

[Expert@XXXZ2:0:STANDBY]# find / -name ServiceProvider\*
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php
/opt/CPSamlPortal/htdocs/spPortal/ServiceProvider
/opt/CPSamlPortal/htdocs/spPortal/ServiceProviderTabs
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/htdocs/spPortal/ServiceProvider
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/htdocs/spPortal/ServiceProviderTabs

so it seems the directories and files to run the SAML portal where just not created ... how come?
TAC has to be involved ... 

best regards

[NiladriSarkar]

We have experienced the same issue with after we upgraded a AWS GEO cluster from r80.40 to r81. We have a case open with TAC.

The second scenario is for Maestros.. initially it was running on r81.10 take 95 + custom fix for SAML.

After upgrade to take 132 ( which required the custom fix to be uninstalled ) SAML is broken/firewall cannot be accessed using GUI,  and there are issues with IPsec tunnel rekey.  case is open with TAC for this as well. 

[Thomas_Eichelbu]

Hello yes understood.
well TAC is already working on it ... iam confident they will find it 🙂

also check this SK sk181971 but its for Error 400 and not Error 404.
i suspect i could easily transfer the folders from the working FW to the broken FW. but i want a solid hotfixes and explanation.

[alannnnnnn]

Same "Not Found" issue after upgrading to 81.10.

I noticed ServiceProvider changed to ServiceProviderTabs in the URL.

[CheckPointerXL]

I had same problem after fresh install + take 130

The fix is: uninstall JHF, install an intermediate JHF (in my case #78), then upgrade to latest JHF

[Thomas_Eichelbu]

Hello, 

TAC mentioned, this issue is known as : PRHF-33044.
if required they will build a custom fix for you.
if it affects a R81.20 fresh install is still under investigation!

best regards

[Thomas_Eichelbu · Accepted solution]

Hello, 

TAC finally solved it ...
PRHF-33044  is the Bug ID
the issue seemed to start with HFA113, which breaks some files in /opt/CPSaml file structure.

Fresh install with R81.10
install HFA in HFA 129 in my case
Install custom fix provided by TAC for HFA129
SIC + Policy Push
and SAML is working again ...

i hope they integrate it into the next GA HFA ... 
otherwise you can do it manually:

backup of both directories
and copy the good files to the affected FW.
scp -rp /opt/CPSamlPortal/* admin@XXXXX:/opt/CPSamlPortal

[TWESTELYNCK]

Hello Thomas,

It seems that we encounter the same issue as yours with the broken SAML Portal (404 on connection attempts).

Our SG cluster is in R81.10 with Hotfix 139.

The current CPSamlPortal structure is as follows:

[Expert@PROXIMA:0]# find / -name ServiceProvider\*
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/htdocs/spPortal/ServiceProvider
/opt/CPSamlPortal/htdocs/spPortal/ServiceProvider

As we only have one cluster with the same broken SAML structure, we don't have the possibility to copy the original files to /opt/CPSamlPortal.

Would you (or any generous soul) be willing to send us these files in order to fix the VPN SAML connection?

Thanks 🙂

[I_Santos]

Yes, I did use "Fresh Install and Upgrade feature" to upgrade from R81.10 take 130 to R81.20 and I got the same issue. I had to rollback the upgrade.

[CheckPointerXL]

For anyone interested to fix the issue without the custom fix, i suggest the previous workaround:

-clean install 81.10

-install JHF 78

-Install latest JHF

[Thomas_Eichelbu]

Hello Team, 

better use a BLINK image and go to R81.20 directly!
then you should have NO issues!
or downgrade to a hotfix around ~R81.10 HFA 110 and upgrade to to HFA 150 ... then SAML should stay.

also there is a hotfix for this issue!
PRHF-33044
fw1_wrapper_HOTFIX_R81_10_JHF_T129_937_MAIN_GA_FULL.tar
but its R81.10  HFA120
-> reach out to TAC, they shall give you a portfix for your version!

i have no more customer running on R81.10, believe or not .. so i cannot send any files.
what u can also do is to install a GW in a VMware and copy the files as well!

[SenpaiNoticed_U]

This is the SK in reference for fw1_wrapper_HOTFIX_R81_10_JHF_T129_937_MAIN_GA_FULL.tar

Documented to be fixed R81.10 jhf 152

https://support.checkpoint.com/results/sk/sk182128

[Daniel_Kavan]

Thanks, I had SAML working with R81.20 JHF84 and it's not in JHF89.   We aren't even getting to the provider link now from the portal.   There were some new changes to SAML and also, The Security Gateway may fail to resolve external Network Feeds whose URL contains a port number (such as "https://example.com:8080/feed.csv". Refer to sk182684.  maybe it fixed 8080 and broke 8443

This page isn’t working

portal.ssl.somedomain.com is currently unable to handle this request.

HTTP ERROR 500