R81.20 JHF99 - Radius VPN Issues

[CaseyB]

I have an open TAC case, but I figured I would do some crowd sourcing while I wait.

Upgraded from R81.20 JHF 89 -> 99 (Recommended). Users can no longer connect using the Check Point Mobile VPN. I am testing with version E88.62 on Windows 11 23H2. Our users authenticate against our internal Imprivata server for MFA. I get prompted to "Accept" MFA 3 times before it stops and Check Point says, "invalid username or password".

When I perform "tcpdump -nni any port 1812", I am seeing good traffic.

I see some stuff addressed for the BLAST CVE and that is where I thought my issue was, but it doesn't appear to be.

I am NOT ignoring Radius attribute 80. sk42184 

I applied the Remote Access VPN regedit as well. sk182516 

• ckp_regedit -a SOFTWARE/CheckPoint/VPN1 require_message_authenticator -n 1

I do see the Message Authenticator field in the replies.

Thoughts? Anyone else seeing this?

[the_rock]

Saw someone else post about this too...affecting every user I assume?

Andy

[CaseyB]

Yeah it's for all users.

[the_rock]

So tcpdump just shows auth error? What did TAC say?

[CaseyB]

I see valid accept / pass messages in the tcpdump, I am gathering debugs for TAC.

[the_rock]

Sounds good, let us know how it gets solved.

Andy

[CaseyB]

I was hoping for a better answer, but here is what is going on. This is Blast-RADIUS related. sk183244 

Basically, our RADIUS server, Imprivata, is not sending the AVP Message-Authenticator back first. Check Point is requiring that the Message-Authenticator AVP is listed first in the response, since it is not first, we get the failure. We have a ticket open with Imprivata, and they are investigating the issue, so it sounds like we are not the first ticket on this.

Here are pictures explaining the issue. You can see in the Access-Request, Message-Authenticator is AVP #1, in Access-Accept it is AVP #3, which to Check Point is bad.

Per the SK I linked, it sounds like there is a patch that changes the behavior, but that hotfix is currently only available for JHF-96,98. Nothing for JHF-99 yet.

So, it seems like I am still stuck running JHF-89 for the foreseeable future.

[the_rock]

da*n..nothing in 101?

[the_rock]

Hey mate,

Any news from TAC?

Andy

[CaseyB]

We are still discussing with them, nothing concrete yet other than read these SKs.

• sk183244 
• sk182516 
• sk42184 

[VIKAS1]

Hey,

any news from TAC, bcz we are planning to upgrade our JHF 92 to 99, and our more users are connecting through VPN, so if we face this issue then big challenges for us.

[CaseyB]

If you are on JHF-92, you should be fine. I am running JHF-89 which never included the fixed for CVE-2024-3596, it was added in JHF-90.

You can validate your current setup, just do a packet capture of a authentication on the gateway and look at the RADIUS packets:

• tcpdump -nni any port 1812 -w radiuscap.pcap

Open the .pcap in wireshark and look at the "Access-Accept" packet, under the RADIUS protocol in the Attribute Value Pairs section, as long as the Message-Authenticator is #1 you are in the clear. I reference this in a screenshot above.

[CaseyB · Accepted solution]

The fix is:

• sk183244 - Get the hotfix mentioned at the bottom of this SK. The hotfix allows the Message-Authenticator to be anywhere in the list of Attribute Value Pairs. This is working in our environment.

The other solution would be to get your RADIUS vendor to send back the Message-Authenticator as AVP #1. I am still trying to get this accomplished with Imprivata, but no updates yet. I do not wish to manage this hotfix for the rest of my life.

I am under the impression that Microsoft NPS and some Linux flavors send Message-Authenticator as AVP #1, so I'm not sure if Imprivata is the only vendor not doing this. The fix for BLAST has been publicly available since November from Check Point, and we have been the only ticket our engineer has delt with where the RADIUS vendor is not sending the Message-Authenticator as AVP #1, but if you are using Imprivata, be aware of this. Based on that, it seems unlikely Check Point is going to change the behavior, but you never know.

[the_rock]

Tx for letting us know!

Andy

[CaseyB]

Update from TAC:

• Just got a message from internal team, and the hotfix from SK183244 will be integrated in the next upcoming Jumbo or the one after that.

I guess they are going to change the behavior, nice.

[the_rock]

So probably take that comes after 101?

[ShemHunter]

Hi!

I would like to add that my client has a problem on take 105, and we see other data.

Not all users have this problem, but only some. At the same time, the problem is if you connect using an ISP, if you distribute the Internet from your phone, there are no problems.

I solved this problem using radius_ignore 80, so I think each take will have its own fix, or as indicated in the article, switch to take 111.

I have an example in attachments.

So far, I think if you upgrade to 111 and remove radius_ignore 80, the problem will disappear or not..

Or I thought about changing the registry setting as mentioned in the article. https://support.checkpoint.com/results/sk/sk182516 and remove the 80 parameter.

I will add: we have a factor 1 error in Logs and Monitor, in the iked1.elg file - RADIUS Servers Cannot Be Reached. Dropping Request

Also, the client connects and the download freezes by 47%..

[ShemHunter]

I upgraded one of my clients to take 111, made radius_ignore 80, and it also freezes at 47%. I have returned radius_ignore 80 back and still get 47%.