- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Announcing Quantum R82.10!
Learn MoreOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hello everyone,
I have a Remote Access VPN implementation configured with MFA authentication. The issue I’m facing is that the authentication fails when I connect using my home Internet Service Provider’s network.
The error message shows an App registration that doesn’t exist in my Azure tenant and isn’t linked to any Identity Provider configured in my Management Server.
However, when I connect using my mobile hotspot, the authentication works perfectly, and the URLs correspond to the current Identity Provider configured on the gateway.
Could this behavior be related to how the ISP handles IP assignment (NAT, CGNAT, etc.)?
Is there any known limitation or recommendation regarding authentication flows behind carrier-grade NAT or similar configurations?
Thanks in advance for any insight or suggestions.
Definitely could be related to that. Do you have any relevant logs/errors that could help us?
I'm not sure about the root cause, but what puzzles me is the different behavior between the two connectivity methods. When I connect through my ISP, the authentication flow seems to reference information that no longer exists, which is why the login fails.
When I use my mobile hotspot, the authentication works correctly and points to the current Identity Provider configuration.
As an additional note, my environment is running R81.20 with JHF Take 119.
That got me thinking...so, if it references something that does NOT exist any longer, can you check Guidbedit and see if you can find it there? If so, just delete it and install policy, test again.
I also wanted to ask another question additional to what @the_rock asked. Does a policy installation without any changes have any kind of effect when the authentication doesn't work, i.e when on ISP network?
I also installed the policy both with and without acceleration, and I couldn’t find any trace of the old object.
What I don’t understand is: if the issue were related to that old reference, what connection would it have with using one Internet service versus the other?
Some of the connections in the connections table can get deleted and recreated upon policy installation, which may help if any connection gets 'stuck' in the table. Just wanted to check 🙂
Do you know whether the EntryID and Replay URLs are being called by the client or by the Gateway?
Is there any cache-related file or something similar that can be cleared?
Thank you very much for your comments.
I could be mistaken, but I believe entryID is called by the client and reply URL by the gateway.
Does the host part of the URLs for the Identity Provider configuration contain an IP or an FQDN?
If an IP, perhaps there's a routing issue upstream.
If it's an FQDN, ensure DNS resolves the same in both places.
As @PhoneBoy noted, when you're on your home network, check the URLs and the hostnames used for the SAML connection. Do 'nslookup' locally on your PC/Mac to verify if the names are resolving to the correct locations. Do the same when you're connected to your mobile hotspot. Compare the differences and that might give you some insight. CGNAT can play weird tricks, for sure. You might even be having DNS re-write taking place by your ISP, such as if you subscribe to some ISP-managed "security filtering" service or whatever. Likewise, are you using some other "VPN" service like Nord, etc.? These things can get in the way, too (and they aren't really doing what you think they are).
Be sure to check your Identity Provider object to make sure it's configured as you expect, including the XML metadata from the SAML provider. If you have a cluster, or multiple Remote Access VPN gateways in the community, then check each of them to be sure they are configured the same.
If all else fails, and you have access to the gateway, you can run a VPN debug to see what's happening under the surface.
I'm using a non-FQDN IP address. Will the client have any logs that could help me understand what's happening?
It works with the same IP address using the username and password method.
So your SAML VPN portal URL (in gateway properties -> VPN clients -> SAML) is an IP address (https://192.0.2.1/saml-vpn) ?
Are you able to post a screenshot of what happens in your client, or browser, after the SAML connection happens and redirects to your Identity Provider? Feel free to scrub any specific identifying info if you must.
Do you know if your home ISP has a content filtering service they are using for your web traffic?
I don't know, I don't think so
Go to http://mysignins.microsoft.com and make sure you aren't accidentally logged into another Azure tenant (or Office365 account, or Azure Portal... whichever is relevant for you). I see this often myself when I have a browser tab logged into some other customer's account. I have to logout of all those first to make sure the cookies and sessions are removed.
That ID belongs to an identity provider that was created at some point but is no longer in AZR and also not in the Gateway
If I use that ID for the URLs in Azure, I get a 500 error.
Then its definitely wrong, but Im wondering if there is a way to confirm 199% it works on CP side...let me check.
Jhf 118 sorry
same PC and same client
Are you able to send what smart console config looks like? Just blur out any sentisive data.
Which part would you need to see?
Preferably all that is relevant.
Preferably part for identity source.
I presume you are installing the security policy after you make any changes?
You may need to check GUIDBedit (or the management API) for any SAML VPN configurations. With the API, on the management server, you can use show-objects with a filter:
[Expert@mgmt01:0]# mgmt_cli -r true -f json show-objects filter saml-vpn
{
"from" : 1,
"to" : 1,
"total" : 1,
"objects" : [ {
"uid" : "b92e489c-31d1-4702-91c3-d268cdf0a074",
"name" : "SAML_VPN",
"type" : "CpmiIdentityProvider",
"domain" : {
"uid" : "41e821a0-3720-11e3-aa6e-0800200c9fde",
"name" : "SMC User",
"domain-type" : "domain"
},
"icon" : "Objects/AuthenticationServer",
"color" : "black"
} ]
}
You can then use show-generic-object with that UID value and review the output for "loginUrl" and "providerID":
[Expert@mgmt01:0]# mgmt_cli -r true -f json show-generic-object uid b92e489c-31d1-4702-91c3-d268cdf0a074 |jq -r '.name, (.services[] |.loginUrl,.providerID)'
SAML_VPN
https://login.microsoftonline.com/81e...986b/saml2
https://sts.windows.net/81e...986b/
If you have more than one entry here, that means you have the SAML portal configured on multiple gateways. You may need to verify your VPN domains are configured correctly to make sure your client's IP is not anywhere in the group you have defined.
Maybe this output will give you some indication if you have a duplicate entry. No guarantees, however.
I'm still not sure why this would work while on your mobile hotspot versus your home ISP. This still indicates there's a possible DNS re-write issue, or your ISP could be filtering web traffic in some way, or perhaps your home router/NAT gateway is configured to do the same.
Looks right to me. So reply URL fails on Azure end?
this one works
this doesn't work
It doesn't exist in Azure nor in Smartconsole
Hm...then it truly begs the question where it came from? Can you confirm 100% you dont see it anywhere in Azure?
I don't know if 100%, but I deleted everything and generated it again, that's why I was also asking who was making the query to "https://IP/saml-vpn/spPortal/ACS/ID/............. and https://IP/saml-vpn/spPortal/ACS/Login/............."
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY