Issue with Azure AD Authentication for Remote Access VPN after R81.10.15 Upgrade

[kristait]

Hello everyone,

I recently upgraded our Check Point SMB 1800 firewall to the latest firmware version, R81.10.15. One of the new features introduced in this release is the ability to authenticate VPN users via Azure AD (SAML), which I was excited to configure for our environment.

Steps Taken:

1. I followed the instructions provided in the Check Point documentation.
2. Created a new Enterprise Application on Azure AD to enable VPN authentication for users using their Azure AD accounts.
3. After configuration, I tested the application using the "Test Sign-in" feature on the Azure portal. The test was successful, and Microsoft Entra ID issued a SAML token to the service provider (Check Point firewall).

Issue:

However, when I attempt to connect to the VPN using Check Point Endpoint Security, the connection fails. Attached is a screenshot showing the error messages during the connection attempt.

• The VPN client hangs during the connection process, and I receive a "Can't reach this page" message for the authentication step.
• The logs indicate that the VPN client is trying to authenticate but does not seem to proceed beyond that.

What I've Verified:

• Azure AD SAML authentication appears to be configured correctly based on the successful test sign-in from the Azure portal.
• The firewall settings are configured as per the Check Point guide for SAML-based authentication.
• I can confirm that the firewall upgrade to R81.10.15 was successful, and all other firewall features seem to be working as expected.

Request for Assistance:

Has anyone else encountered this issue with Azure AD SAML authentication for remote access VPN after upgrading to R81.10.15? If so, could you share any insights or troubleshooting steps that might help resolve this problem?

Additionally, are there specific logs or debugging steps on the Check Point firewall side that could shed light on why the SAML authentication isn't proceeding during the VPN connection?

Any help would be greatly appreciated!

Thanks in advance for your assistance.

Environment:

• Check Point SMB 1800 firewall (R81.10.15)
• Azure AD for SAML authentication
• Check Point Endpoint Security VPN Client

[PhoneBoy]

Based on what I know about SAML, the client has to be able to reach a URL on the gateway to perform the authentication.
I assume this is in Step 7: the Unique identifier URL value from the Quantum Spark Gateway WebUI.
Does this URL reflect an FQDN, IP address, or?
Can you confirm in a web browser this loads any page?

[kristait]

@PhoneBoy :

• The Unique identifier URL is currently set to reflect my primary ISP’s public IP in the format https://xxx.xxx.xxx.xxx.
• When I attempt to load the URL in a web browser, I get the "Can't reach this page" error.
• We are not using DDNS on our appliance, so I assume this might be causing issues when the IP address is used instead of an FQDN. Would changing this to an FQDN (by setting up DDNS) help in this case?

[G_W_Albrecht]

Better open a SR# with CP TAC!

[Dafna]

Hi,

Could you please check if there are any relevant logs on the security logs page? Also, are you using an NTP server?

[kristait]

@Dafna :

• We're using the default Check Point NTP server settings, and the time is synced correctly on the gateway.
• I checked the security logs, and this is what I found:
  • "10.xx.0.xxx (local IP) xxx.xx.xx.xxx (public IP) CP_SmartPortal 2 Accepted on rule 2 (Incoming/Internal Default Policy)."
• It appears that something is being accepted via CP_SmartPortal, but I’m unsure if this is related to the SAML authentication process. Could this log entry indicate an incomplete or incorrect configuration?

[the_rock]

I totally see what Phoneboy is saying, but it might be worth to confirm with TAC if its related to the version you upgraded to. To me, logically, if this worked BEFORE the upgrade, and no config was changed, most likely may have to do with the upgrade...just my logical reasoning.

Andy

[Chris_Atkinson]

It was a new capability introduced with this GW version.

With that said it's also worth confirming the Endpoint client version used for correlation purposes?

[kristait]

1. @Chris_Atkinson :

   • We have downloaded and installed the latest version of the Endpoint client, which is E86.80_CheckPointVPN.

[Chris_Atkinson]

Actually the latest client version is E88.x

[kristait]

We have installed the latest version of the client, E88.40. I've now noticed that the page redirects through the browser (whereas earlier it would open in a small window), but I still receive the same error:

"Hmmm… can't reach this page. xxx.xxx.xxx.xxx refused to connect."

It seems that the firewall may be blocking the SAML VPN connection, though I’m unsure which specific service or rule needs to be enabled to resolve this issue.

[jurgenvrieze]

I had this issue with an EA version of R81.10.15. upload of the metadatafile seemed OK, but it wasn't. There is no real message something went wrong. 

Can you check if the metadata was imported and installed correctly? there should be a green mark (or 2)

[kristait]

@the_rock :

• Thanks for pointing that out! Just to clarify, we're using an SMB 1800 locally managed Firewall, and this is the first time we’re setting up the new SAML authentication capability introduced with R81.10.15.
• So this isn’t an issue with a pre-existing configuration breaking after the upgrade—it’s just that the feature isn’t fully working after the first-time setup.

[the_rock]

Got it. I would still open TAC case to investigate.

[kristait]

@the_rock, I have created a TAC case, and the number is SR# 6-0004074266.

[the_rock]

Sounds good, keep us posted.

Andy

[orion_son30]

Hi,

Did you had any reply from TAC to solve the issue?

I'm having the exact same problem with the same appliances, also centrally managed.

Thanks.

[kristait]

Hello @orion_son30, I just saw your comment. The solution provided by TAC is:

Solution Description: I checked internally and also as you suspected it is the port which is causing this issue. The entire SAML authentication flow uses port 443.

However, since I don’t want to lose UI control on my SMB device, I didn’t make any changes and instead switched to Pritunl VPN.

[skandshus]

isnt it much easier to just change the UI port on the smb device instead? 🙂

[PhoneBoy]

Not sure how you lose control of the SMB device as you can't use TCP port 443 to manage it at all, but you're directed to a different port (4434 usually, but you can change that).

[Dafna · Accepted solution]

AZURE AD for SAML is supported only on default port 443.

According to the screenshot you are using 4433

Thanks,

  Dafna