Checkpoint VPN MFA with Okta SAML

[seanmc12]

I have a very strange issue regarding our Checkpoint VPN utilizing Okta SAML Authentication for MFA. In most cases, it works fine but we are seeing some very odd issues.

1. Username/Password Auth - User signs in, Identity Collector verifies user with AD and allows a connection.

2. On the Client Endpoint, Users selects Okta SAML VPN, which was setup, with exact instructions from Checkpoint ADM.

3. When user launches client, it pops up the Okta screen, the user enters in ID/PW, selects SMS, Push, Email and etc.

4. Okta screen spins and then the Checkpoint Client will USUALLY complete the connection.

5. Randomly, the user will do step 3, the Okta screen spins a bit, as normal, but then the "Checkpoint VPN Client" will come throw back and error stating "Invalid User/Bad Password" and will never let them in.

6. If the user changes Authentication, on the client, back to Username/Password, then enters the same ID/PW used in step3 and 5, Checkpoint will successfully complete the connection.

7. Sometimes, the user, utilizing Okta SAML VPN, will successfully connect with no issues at all ...AND importantly, NO CHANGES at all on the Checkpoint VPN client side.

Our company is mandating MFA on our VPN connections so it is vital to have this working. The main ISP we see this happen with is TMobile 5g Wireless but in the last couple of days, I have seen this on an Indian ISP Railware or something and then this morning, A carrier in PA. Checkpoint TAC did some debugs and in the debugs...weirdly, they are seeing the request come in on 1 external IP, but Checkpoint TAC is saying that in the middle of the process or something, the IP is changing to a different external IP which Checkpoint is not recognizing and then denying the connection. This is being seen on T-Mobile mostly. But again...with no changes to Okta or Checkpoint, sometimes it will work.

AND...Our Checkpoint ADM says he has a couple other customers who are seeing this same behavior

Any thoughts....this is so HIGH Priority and doesn't appear to be any assistance on this anywhere.

[the_rock]

Is there isp redundancy configured on CP or no?

Andy

[seanmc12]

Going to say no to this as I've not set that up and don't recall that ever being mentioned in all the work we have done.

[the_rock]

Just to be 100% sure, you can verify as per below.

Andy

 

[seanmc12]

Confirmed No

[seanmc12]

Confirmed No

[the_rock]

Would you mind send what you have configured under vpn clients -> auth?

Just blur out any sensitive info.

Andy

[seanmc12]

VPN Client Auth

[the_rock]

That looks right if you want them to have 2nd option to use username/pass, which it sounds like you do. Just curious, have you ever tried using ONLY okta IP method? if yes, what was the result?

Andy

[seanmc12]

We are set to remove the Username/Password option this friday and ONLY the Okta SAMP VPN option will be available. As stated in my initial post, most of the time, the Okta SAML VPN Auth works but there are random times when it doesn't.

[the_rock]

I carefully read your post again and here is what I logically "draw" from it, specially from below part:

Checkpoint TAC did some debugs and in the debugs...weirdly, they are seeing the request come in on 1 external IP, but Checkpoint TAC is saying that in the middle of the process or something, the IP is changing to a different external IP which Checkpoint is not recognizing and then denying the connection. This is being seen on T-Mobile mostly. But again...with no changes to Okta or Checkpoint, sometimes it will work.

If I were you, just my personal opinion, I would check with TAC what exactly it could be thats causing this? If there is no ISPR configured, which you verified already, then this is happening due to another reason...can you confirm how VPN link selection is configured as per below?

Andy

 

[seanmc12]

See attached

[the_rock]

That looks right to me.

[PhoneBoy]

Sounds like a CGNAT issue inside the mobile network.
Which might explain why it works "sometimes" and when it fails, it fails only for people on some providers.
I assume TAC is involved here?

[seanmc12]

I do have a ticket open, but TAC just said...We don't support that. I'm having our ADM escalate the ticket for some additional support.

[_Val_]

Hi @seanmc12 

The correct way here is to open a TAC case and work through there. I am also not sure how you can get a TAC "not supported" reply if you do not have a case. Or did I misunderstand, and you have one, just not having the ID handy? Could you please elaborate on that?

[AndreiR]

Hi @seanmc12 ,

@_Val_ is correct: this is rather specific case, it requires analysis of logs and traffic, and you should work with TAC. They will investigate the issue, and if they state, this is not supported, you may approach Solution Center and open RFE. 

[seanmc12]

I do have a ticket open with TAC and have been working it through them. We have been looking at the ticket for about a week and a half and have not gotten anywhere. Typically, if I have an issue and am not getting anywhere with TAC, I will post it here as there is hardly ever an issue which hasn't been seen by anyone. Usually, the group will offer up suggestions and leads which I also provide to and ask TAC about and sometimes those leads get TAC looking at the right root cause or help to brainstorm a solution. I did not mention the ticket number because I don't want anyone here, if they can, looking at the ticket and then trying to do trouble shooting that we have already done. The behavior we were seeing in the VPN Debugs, I was told, is not supported, which is why I posted it here for suggestions. The CGNAT may be a valid root cause and I got it from this forum so I know the process works. I have provide the case ID as well as some notes to Val and the case is being escalated to or within R&D.

[PhoneBoy]

Something to try: our EA for Remote Access with IPv6.
Even in it's current state (requires NAT64 to be implemented in the operator network), it might side-step this CGNAT issue.
It only requires a different client to be deployed.
See: https://community.checkpoint.com/t5/Remote-Access-VPN/Support-IPv6-in-Remote-Access-VPN/m-p/211585#M... 
If you're interested in trying this, let me know and I can connect the dots on the back end.

[seanmc12]

I will forward this to our Checkpoint ADM and get his input. We've built a lab and he may be able to test something like this.

[PhoneBoy]

If you're already working with your account team, they should be able to get this as well.

[PhoneBoy]

I got reached out to by your ADM on the back channel 🙂
For others reading along here, this might also sidestep the apparent CGNAT issue (use of Visitor Mode): https://support.checkpoint.com/results/sk/sk107433 

[Sbolton]

I have a similar incident with two different customer's using two different MFA's. Just started on the 25th of last week for both customers. Customer's are in different states. Only affects certain of their employees on the VPN. One of said customers has this occurring on peoples at home internet while if they switch to their mobile hotspot it will work fine. Trying to find out poeple's current ISP's and see if this is something similar accross the board. Both customers are on R81.20 Take 53, just upgraded them a couple of weeks ago too. Very interesting.