404 error when using Azure AD login / SSO for only some users in some locations

[nzmatto1]

Here we go for something really odd. 
We have set up SSO login for our VPN using Azure AD. For some users this works absolutely perfectly, including me. For some other users when they attempt to connect they are getting a 404 site not found error before they even get as far as entering a username.

There is no configuration differences with the users all installing from the same client, and though we have multiple gateways / VPNs we've found if a user gets a 404 error from one of them, they'll get it from all of them. If it works on one, it'll work on all. 

I'm seriously confused as this is all configured on a per gateway basis and there is nothing configurable at a per user level, and again this is even before a username is entered in the connection process. 

Has anyone come across this before?  Any ideas on where I can go to troubleshoot?

Thanks Matt

[PhoneBoy]

What is the difference in URL between "working" and "not working" (if any)?
Version/JHF level of the gateways and versions of the clients would also be helpful.

This might require TAC assistance and recommend opening a case in parallel to this thread (if you haven't already).

[nzmatto1]

A bit more on this. We're using R81.1, but to be honest I doubt this version has anything to do with it. We have also bypassed the Checkpoint Client. 
We have 4 gateways configured for use. Each one of them has their own URL for reaching Azure. Using any browser we can initiate a session to the firewall using the URL, and this attempts to open a connection through to Azure. For some people this works, others get a 404 error. This is not user account related as no user details have been entered at this point, and the URL being used is the same between our testers.  
Some testers have found it'll work from one location, but not from another, on the same device. 
So far we have been unable to find any useful logs on the Checkpoint end. I have only been able to see the expected traffic on port 443 for the connection from the client, which is the same irrespective of it working, or not. 
My working theory at the moment is there may be something specific to the way the network sessions are being set up and some peoples routers or ISPs may be blocking some of the traffic. I know an HTTPS session is initiated to the firewall and we see that traffic. The firewall is then routing that traffic somehow to the Azure destination. I am wondering if this is the same IP session being forwarded and perhaps some local firewall is detecting the forwarding and dropping the session or something like that. 
At the moment I don't really have enough detail to log a ticket either to Checkpoint or Microsoft, which is why I have put this up here to understand if perhaps others have come across this. 

[PhoneBoy]

One of the easiest ways to rule out something "in the network" that might be causing this is taking some tcpdumps from the relevant gateway when a user is experiencing this problem.
This way, you can see if the traffic is even making it to the gateway or not.
TAC may have some other suggestions on how to troubleshoot this.

[nzmatto1]

Another update, 

We've had a bunch more testing done and have found there are some users on the same site where some users can reach the login page and others are getting a 404 error. This is following the same URL (outside of the VPN client) via the same gateway, to the same firewall, with the same SSO login destination. It seemingly makes no sense now. 
I now have enough information to go ahead and log a TAC case, so I will get that done.  

[mappel]

Hi,

have you had any success with TAC?

We have the same exact error, when we switched to SAML authentication.

I hope you can provide some insight.

Thank you very much.

[nzmatto1]

It seems this was related to a couple of the domain controller servers were were authorizing against being shut down. We were only a supplier of the Checkpoint product suite in this instance and we'd not been advised of the servers being removed from the network, so the 404 was literally the destination servers (2 from a pool of 😎 not being reachable.
Once they were removed from the pool, the problems disappeared. During the investigations we also found out that a number of users were being randomly disconnected from their VPN from time to time. It was actually diagnosing that which led to the discovery of the removed servers, and the 404's went away at the same time. 
I hope that helps you.