Clientless Access Stopped Working After IDP Switch "Application is unreachable" Error

EDIT
Here to help

Clientless Access Stopped Working After IDP Switch "Application is unreachable" Error

After switching from Azure IDP to Duo IDP and got error "HTTP Error 404. The requested resource is not found." or "Application is unreachable Please contact your Administrator" upstream connect error or disconnect/reset before headers. reset reason: connection timeout"

This was working previously with the following setup:

Azure IDP with Azure SCIM Import to Umbrella

2 Private Apps, 2 Groups with each app a member of one groups

What changed?

Deployed Client Based Access and switched IDP to Duo to test on prem identities. Removed users from Azure SCIM and then enabled Umbrella on prem AD connector. Able to pass authentication and get the error after passing MFA. 

IDP logs or Secure Connect logs both show success and no blocks.

Troubleshooting steps taken (Incognito browser mode):

Removed Duo IDP (AD as the underlying identity store), and added back Azure as my IDP.

Disabled on prem Umbrella connector and added users back to Azure SCIM and confirmed users groups appear in Secure Connect. Tested app access and get the same error or application not available.

Removed/re-added private applications, app groups, Browser Access Rules, same error. 

Can confirm private apps reachable on internal network and private hostname resolvable with no issues.

Removed/re-deployed site tunnels using Auto VPN from Secure Connect to Umbrella twice and tried different regions same error.

Configured ZTNA for same apps using a different ZTN solution to isolate between ZTN solution, (Azure App Proxy) and worked with no error then removed it to avoid conflict on Secure Connect Clientless Access but same error in Secure Connect

Validate Application Certificate Disabled (Enabled did not work previously but also not needed just wanted to note it here)

 

Protocol same https Server Name Indication

Logs have not been helpful because error is not related to authC or authZ.

3 Replies 3
alemabrahao
Kind of a big deal
Kind of a big deal

I suggest you open a support case.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Eric-Eddy
Meraki Employee
Meraki Employee

This can be a detailed issue so I agree a case is probably best.

 

Other things you can try yourself.

This error is typically from a network reachability issue. I suggest checking the reachability of private apps on your network. Browser-based Access uses Carrier-grade NAT (GCNAT) space 100.64.0.0/10 as a source IP, and the route for that network should be visible in the MX routing table as shown below. 

How is your private app connected to the Secure Connect fabric? MX tunnel? IPSec? If you are using an MX you can perform a packet capture on the MX to see that the GCNAT traffic is making it to the MX. You could also do a packet capture on the private app also looking for that GCNAT space. 

EricEddy_0-1715007220154.png

 

Eric Eddy
CCIE #47300
Sr. Technical Marketing Engineer
Meraki - Secure Connect
EDIT
Here to help

Thanks @Eric-Eddy @alemabrahao  I deployed tunnel using Meraki AutoVPN feature. I am able to reach the private apps both internally and through a different ZTN solution.

 

Will run pcaps and open ticket thanks again

Get notified when there are additional replies to this discussion.