Troubleshooting guide

To properly troubleshoot Access Gateway, you must meet the following prerequisites:

  • Administrator access to your Okta org.

  • Access to the Access Gateway Management console.

  • Knowledge of how to retrieve and monitor logs from network appliances, application servers, and so on.

  • Knowledge of how to identify an HTTP status code that appears in a log statement.

What problem do you have?

Click the appropriate problem description from the following list that matches the error that you’ve received.

How to monitor logs

You can download logs or forward them to a logging server. See Administer logging for more information.

  1. Log in to the Access Gateway Management console. The default credentials are as follows:
    • Username: oag-mgmt
    • Password: OktaMgmt@123
  2. Select 4-Monitoring from the Access Gateway Management console menu.
  3. Select 1- Monitor Logs.

HTTP Status Codes

Access Gateway and other applications return the following status codes to the browser during any event. They're also captured in the access log for troubleshooting issues.

Status Code Description
200 Success
400 Access Gateway isn't serving the application being called by IP address or hostname
401 Session doesn't exist
403 Policy rule denied access to resource
404 Unknown page, content, or resource
405 Session integrity failure
500 Server-side error
502 Back-end application isn't available
503 Application is in maintenance, inactive, or offline mode
504 Request to back-end application timed out

How Do I Find My Status Code?

Access Gateway presents status codes as follows:

  • HTTP status codes visible in the browser could be returned from a back-end application, which could be misleading. All HTTP status codes returned by Access Gateway are displayed as user-friendly error messages on the page. The preceding image provides an example.

  • The following image is an example of a generic error message, not a message generated by the Access Gateway. This type of generic error message looks different for every application. Non-Access Gateway error pages indicate which HTTP status code the application protected by Access Gateway returns (see the following image for an example).

Some status codes occur due to back-end application errors and must be investigated on the application side.

Steps to capture an HTTP status code:

Sometimes, depending on the application or error, the end user may not see an Access Gateway error page, and a status code must be collected from the browser. Follow these steps to capture a status code using the browser developer tools.

  1. Open a new browser window.

  2. Right-click the page, and click Inspect to open Developer Tools.

  3. Click the Network tab.

  4. Enter the URL that you want to test.

  5. Complete the login process if required.

  6. Capture the status code of the page in question. See the following image.

The preceding steps to open Developer Tools are applicable to Google Chrome. In IE, Developer Tools can be opened by pressing F12.

Tracking ID

If there's an internal server error, Access Gateway generates a tracking ID that is displayed on the error page. This tracking ID can be used to identify the event and corresponding log messages from the log files while troubleshooting.

If the error page has a tracking ID, you can click Tracking ID to copy the tracking ID and the associated error message provided in the log. This message contains important information that can help you troubleshoot the issue.

Log StatementGateway host:[<host URL>]referrer:[<IDP SSO URL>]error:[Login Error] tracking ID:[6eff1f9ca3] details:[Requester/RequestDenied: Could not validate the following SAML AuthnRequest from partner Test App: ]

What problem do you have?

Status Code 400

Unknown Host Status

The requested host: <Requested Hostname> is not being served by this Access Gateway.

Possible cause

The DNS record resolves to the Access Gateway, and there's no service or application available on the Access Gateway with the corresponding host name.

Log statement

Mar 7 15:26:26 localhost.localdomain icsDefault443Access <host URL> <IP ADDRESS> - - [07/Mar/2018:15:26:26 -0600] "GET / HTTP/1.1" 400 1992 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36" "-" 0.035 0.035

Validation and mitigation steps

  1. Verify that you're using the correct URL.

  2. Verify that the Public Domain field in Access Gateway application is correct.

  3. Verify that your DNS or local hosts file correctly addresses the hostname and IP address.

  4. Verify that your application is configured properly with the relevant hostname.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Status Code 403

Access Denied to Resource

Access to resource <Requested Resource> in application “Requested Applications” has been denied.

Possible cause

The Access Gateway returns this status code when the policy engine denies access to a protected resource. You might receive this status code if there's a condition where certain access to a resource is intentionally prohibited.

Log statement

Mar 7 15:36:22 localhost ACCESS_GATEWAY ACCESS AUTHZ POLICY INFO USER_AUTHZ [SESSION_id="aa3b92617708c430ad74acbd6b1cf23f4809b48141"SUBJECT="<User login ID>" RESOURCE="/test" METHOD="GET" POLICY="test" POLICY_TYPE="PROTECTED_REGEX" DURATION="0" APP="<Application name/ description>" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>" RESULT="DENY" REASON="Groups=(?!.*Everyone:) -SESSIONID=_aa3b92617708c430ad74acbd6b1cf23f4809b48141 RelayDomain=<Relay domain URL> static1=static1 secret=secretvalue spgw_username=<User ID> UserName=<User ID> spgw_username=<User ID> cloud:identity:domain=<IDP tenant subdomain> workEmail=<User work email attribute>cloud:identity:tenant=<IDP tenant subdomain> givenName=<User first name> familyName=<User last name> email=<User email> SourceAuthNType=urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport RemoteIP=192.168.1.4 USER_AGENT=Mozilla/5.0 (WindowsNT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 creationTime=1520458088124 maxInactiveInterval=3600000 maxActiveInterval=28800000 lastAccessedTime=1520458092027 " REMOTE_IP="<IP Address>" USER_AGENT="Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36"] deny access to resource

Validation and mitigation steps

  1. Verify this is an error and not an intentional denied resource.

  2. Verify and fix the defined policy in the Access Gateway application.

  3. Verify that the user is allowed access by the policy.

  4. Contact Support if the application resource is still inaccessible.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Status Code 404

Resource Not Found

The page you are trying to access does not exist.

Possible cause

The Access Gateway returns this status code when the requested resource is unavailable.

Log statement

Apr 5 03:59:57 oag01 icsIcsgwAccess <Gateway domain> <Gateway IP address> - - [05/Apr/2018:03:59:57 -0500] "GET / HTTP/1.1" 404 1922"-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "<Gateway IP address>" 0.019 0.019

Validation and mitigation steps

  1. Verify the URL to make sure it's correct, and ensure that the resource still exists and is pointed toward the correct location.
  2. If the resource is inaccessible, contact Okta Support.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Status Code 405

Access Denied

The Access Gateway has detected an anomaly in user access to the <Requested Application>.

Possible cause

The Access Gateway returns this status code when it detects a possible issue with session integrity to prevent sessions from being hijacked. This can also happen when a user switches networks with an active session in place.

Log statement

Apr 2 15:19:32 ACCESS AUTHZ SESSION WARN USER_SESSION [SESSION_id="0e53b206b5aa2d8b93cdf7f48c4c5ca51e2eeff494" SUBJECT="<User ID>" APP="IDP Sample Header App 1" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>"RESULT="DENY" REASON="SESSION_INTEGRITY_REMOTEIP_MISMATCH" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"] SRF Request RemoteIP(http_x_real_ip): <User IP address> failed to match session RemoteIP: <Remote IP address> Apr 2 15:19:32 IDPsampleheaderapp1 <App domain URL> <User IP address> - - [02/Apr/2018:15:19:32 -0500] "GET / HTTP/1.1" 405 2050 "<IDP SSO URL>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "<User IP address>" 0.010 0.010.

Validation and mitigation steps

  1. Verify with the user if they changed networks during an active session with Access Gateway.
  2. If step 1 is confirmed, the user must restart the browser and log in again to start a new session.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Status Code 413

Request Entity Too Large Code

The Access Gateway displays error 413 if the file being uploaded is larger than 1 MB.

Possible causes

By default, the Access Gateway is set to allow file uploads that are less than 1 MB in size.

Validation and mitigation steps

  1. Use the developer tools to confirm that the HTTP status code returned by the Access Gateway is 413.

  2. To increase the file upload limit, click the Applications tab.

  3. Click the Edit App icon for the corresponding application.

  4. Open the Advanced dropdown menu within the application.

  5. Slide the Maximum File Upload Size Adjuster to an appropriate size.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Status Code 500

Internal Server Error

An unexpected server error has occurred. The error has been logged. Contact your support service if you face this error message.

Possible cause

Error in an Access Gateway component.

Log statement

Apr 2 22:53:10 IDPsampleheaderapp1 2018/04/02 22:53:10 [info] 26875#0: *3909 client closed connection while waiting for request, client: 192.168.10.20, server: 0.0.0.0:443Apr 2 22:53:10 IDPsampleheaderapp1 <App domain URL> <IP address> - - [02/Apr/2018:22:53:10 -0500] "GET /GOPYX48z5/module.php/icsgw/as_login.php?AuthId=k3x6WX20E&ReturnTo=https://<App domain URL> HTTP/1.1" 302 2707 "<Gateway domain URL>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "-" 0.006 0.006

Validation and mitigation steps

Contact Support to investigate the issue.

What problem do you have?

Status Code 502

Application is Not Responding

The backend web application <Requested Application> is not receiving user requests from the Access Gateway and not available for usage.

Possible cause

Access Gateway returns this error when it fails to connect to the back-end application it's protecting.

Log statement

Apr 5 04:01:38 oag01 icsadmin <Gateway domain URL> <IP address> - - [05/Apr/2018:04:01:38 -0500] "GET / HTTP/1.1" 502 2130 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "-" 0.006 0.000, 0.000 : 0.005

Validation and mitigation steps

  1. Ensure that the app is working and the protected URL specified in Access Gateway is reachable.

  2. Ensure that the DNS record is resolvable.

  3. Ensure that the backend application is reachable from the server that hosts the Access Gateway appliance. See the cURL connectivity test section in Manage network interfaces.

  4. If using a load-balancing solution, individually verify whether any of the Access Gateway appliances are causing the issue.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Status Code 503

Application Not Activated

Application <Requested Application> has been disabled and is not available for usage.

These 503 status codes can occur when an administrator has temporarily removed access to an application. In these cases, the application is also disabled in the IdP. Before editing any settings in the Access Gateway Admin UI console, confirm the application status with the application owner or appropriate manager.

Possible cause

The Access Gateway shows this warning page when an application has been marked as inactive.

Log statement

Mar 7 16:56:39 localhost ACCESS_GATEWAY ACCESS AUTHZ POLICY INFO USER_AUTHZ [SESSION_ID="N/A" SUBJECT="" RESOURCE="/" METHOD="GET" POLICY="INACTIVE" POLICY_TYPE="NO_AUTH" DURATION="0" APP="IDP Sample Header App" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>" RESULT="ALLOW" REASON=" - N/A" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36"] allow access to resource.

Validation and mitigation steps

  1. Open the Access Gateway Admin UI console.

  2. Go to the Applications tab.

  3. Verify that the status of your application is set to Inactive.

  4. Edit the Application.

  5. Change the application status to Application is Active.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Application is in Maintenance

The application <Requested Application> is temporarily not available for usage.

Possible cause

The Access Gateway shows this warning page when an application status has been changed to maintenance mode for any maintenance activity.

Log statement

Mar 7 16:58:23 localhost ACCESS AUTHZ POLICY INFO USER_AUTHZ [SESSION_ID="N/A" SUBJECT="" RESOURCE="/" METHOD="GET" POLICY="ACTIVE_MAINT" POLICY_TYPE="NO_AUTH" DURATION="0" APP="IDP Sample Header App" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>" RESULT="ALLOW" REASON=" - N/A" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36"] allow access to resource

Validation and mitigation steps

  1. Open the Access Gateway Admin UI console.

  2. Go to the Applications tab.

  3. Verify that the status of your application is set to Maintenance.

  4. Ensure that maintenance on the application is complete and the back-end application is available.

  5. Edit the application.

  6. Change the application status to Application is Active when the application maintenance is complete.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Application is Offline

The application <Requested Application> is not functioning correctly and has been taken offline. This outage has been logged.

Possible cause

The Access Gateway shows this warning when it detects potential errors with an application configuration and marks it offline.

Log statement

Apr 2 15:02:33 ACCESS_GATEWAY ACCESS AUTHZ POLICY INFO USER_AUTHZ [SESSION_ID="N/A" SUBJECT="" RESOURCE="/favicon.ico" METHOD="GET" POLICY="ACTIVE_OFFLINE" POLICY_TYPE="NO_AUTH" DURATION="0" APP="IDP Sample Header App 1" APP_TYPE="SAMPLEIDPHEADER2015_APP" APP_DOMAIN="<App domain URL>" RESULT="ALLOW" REASON=" - N/A" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0"] allow access to resource Apr 2 15:02:33 IDPsampleheaderapp1 <App domain URL> <IP address> - - [02/Apr/2018:15:02:33 -0500] "GET /favicon.ico HTTP/1.1" 503 2063 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0" "-" 0.011 0.011

Validation and mitigation steps

  1. Open the Access Gateway Admin UI console.

  2. Go to the Applications tab.

  3. Verify that the status of your application is set to Offline.

  4. Edit the application.

  5. Change the application status to Application is Active after fixing the application configuration error.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Status Code 504

Access Gateway Timeout

The 504 Gateway Timeout error message is an Oracle EBS Integration timeout error.

Possible cause

The EBS registration isn't working or has been erased from the instance. The application won't provide the GUID and the USER_ORCLGUID header won't appear in the Access Gateway logs when debug is enabled.

Log statement

Apr 2 15:49:53 oracleaccessgatetest1 <App domain URL> <App IP address> - - [02/Apr/2018:15:49:53 -0500] "GET /accessgate/ssologin HTTP/1.1" 504 2050 "<IDP federation response>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" "-" 1.017 1.002 : 0.008

Validation and mitigation steps

  1. If EBS is expected to take longer than 60 seconds, increase the Backend Timeout duration in the Advanced dropdown menu in Application Settings.
  2. Troubleshoot and fix the EBS application instance.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Application Timeout - Backend App

The backend web application <Requested Application> is not responding in a timely manner to user requests from the Access Gateway and/or isn't available for usage.

Possible cause

The Access Gateway returns this error when it times out when trying to connect to an internal application it's protecting.

Log statement

Mar 7 17:47:32 localhost.localdomain headerssoapp11 2018/03/07 17:47:32 [error] 6703#0: *4793 upstream timed out (110: Connection timed out) while connecting to upstream, client: <Client IP address>, server: <Server domain URL>, request: "GET / HTTP/1.1", upstream: "http://1.1.1.1:80/", host: "<Host URL>", referrer: "<Access Gateway Admin UI URL>"

Validation and mitigation steps

  1. Ensure that the application is responding.

  2. Ensure that the application URL is reachable from the Access Gateway.

  3. Ensure that the connection isn't being blocked at any stage.

  4. Test the connectivity to the back-end application from the Access Gateway.

  5. If the application is expected to take longer than 60 seconds, increase the Backend Timeout duration in the Advanced dropdown menu in Application Settings.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Application Render Failure

The application doesn't render if the back-end application takes longer than 60 seconds to respond.

Possible cause

Access Gateway is set to time out after 60 seconds when waiting for a response from the back-end application.

Log statement

Mar 7 17:47:32 localhost.localdomain headerssoapp11 2018/03/07 17:47:32 [error] 6703#0: *4793 upstream timed out (110: Connection timed out) while connecting to upstream, client: <Client IP address>, server: <Server domain URL>, request: "GET / HTTP/1.1", upstream: "http://1.1.1.1:80/", host: "<Host domain URL>", referrer: "<Access Gateway Admin UI URL>"

Validation and mitigation steps

  1. Ensure that the application is responding.

  2. Ensure that the application URL is reachable from the Access Gateway.

  3. Ensure that the connection isn't being blocked at any stage.

  4. Test the connectivity to the back-end application from the Access Gateway.

  5. If the application is expected to take longer than 60 seconds, increase the Backend Timeout duration in the Advanced dropdown menu in Application Settings.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Application Timeout - Internal App

The backend web application <Requested Application> is not receiving user requests from the Access Gateway and not available for usage.

Possible cause

The Access Gateway returns this error when it times out while trying to connect to an internal application it's protecting.

Log statement

Mar 7 17:47:32 localhost.localdomain headerssoapp11 2018/03/07 17:47:32 [error] 6703#0: *4793 upstream timed out (110: Connection timed out) while connecting to upstream, client: <Client IP address>, server: <Server domain URL>, request: "GET / HTTP/1.1", upstream: "http://1.1.1.1:80/", host: "<Server domain URL>", referrer: "<Access Gateway Admin UI URL>"

Validation and mitigation steps

  1. Ensure that the application is responding.

  2. Ensure that the application URL is reachable from the Access Gateway.

  3. Ensure that the connection isn't being blocked at any stage.

  4. Test the connectivity to the back-end application from the Access Gateway.

  5. If the application is expected to take longer than 60 seconds, increase the Backend Timeout duration in the Advanced dropdown menu in Application Settings.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Error using SSH to connect to Access Gateway

When using SSH to connect to the command-line console, an error is generated similar to:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

For example:

username$ ssh 100.25.225.222 username@100.25.225.222:Permission denied (publickey, gssapi-keyex,gssapi-with-mic). username $

Problem:

Didn't specify the required oag-mgmt username when attempting to connect to the Access Gateway command line.

Solution:

Specify the oag-mgmt user when connecting to an Access Gateway instance. For example

username$ ssh oag-mgmt@100.25.225.222 Access Gateway Administration . . . 1 - Network 2 - Services . . .

What problem do you have?

Login Error

Error being generated while logging in to an application.

For login errors, a TRACKER_ID is assigned to each issue.

What problem do you have?

Time isn't in sync

Log statement 1

Apr 3 14:20:18 accessgw01 ACCESS AUTHN SAML ERROR USER_AUTHN [TYPE="SAML_2_0" TRACKER_ID="882d8b2faf" SOURCE="<IDP SSO URL>" RESULT="FAIL" REASON="Invalid SAML Assertion" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"] Requester/RequestDenied: Could not validate the following SAML AuthnRequest from partner <Access Gateway Application Name>:

Validation and mitigation steps 1

  1. Log in to the Access Gateway Admin UI console.

  2. Select the Settings tab.

  3. Select Advanced.

  4. Verify that the time is correct.

  5. If the time isn't correct, click Resync.

  6. Click the refresh button to refresh system time and verify that it's current.

  7. Test the application to determine if time is synchronized correctly.

Log statement 2

Apr 3 14:20:09 oag01 ACCESS_GATEWAY ACCESS AUTHN SAML ERROR USER_AUTHN [TYPE="SAML_2_0" TRACKER_ID="882d8b2faf"SOURCE="<IDP SSO URL>" RESULT="FAIL" REASON="Invalid SAML Assertion" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"] Received an assertion that is valid in the future. Check clock synchronization on IdP and SP.

Validation and mitigation steps 2

  1. Log in to the Access Gateway Management console

  2. Select the Service option, and then select the NTP option.

  3. Choose the option to restart the NTP service.

  4. Verify the time in the Access Gateway Access Gateway Admin UI console console.

  5. Test the application.

Log statement 3

Apr 4 16:20:11 oag01 ACCESS_GATEWAY ACCESS AUTHN SAML ERROR USER_AUTHN [TYPE="SAML_2_0" TRACKER_ID="d7703c136c" SOURCE="<IDP SSO URL>" RESULT="FAIL" REASON="Invalid SAML Assertion" REMOTE_IP="<Remote IP address>" USER_AGENT="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"] Received an assertion that has expired. Check clock

Validation and mitigation steps 3

  1. Log in to the Access Gateway Management console.

  2. Select the Service option, and then select the NTP option.

  3. Select the Set System Time option.

  4. Enter the time in MON DD YYYY HH:MI:SS AM/PM format.

  5. Verify the time in the Access Gateway Admin UI console and ensure it matches.

  6. Test the application.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Browser doesn't trust the domain and doesn't post SAML request

This error can occur if a user keeps reposting SAML assertions or if an error occurs in the process of accepting a self-signed SSL certificate.

Log statement

Apr 04 14:19:44 ACCESS ERROR [3137b1cb3f] Caused by: Exception: Unable to find the current binding.

Validation and mitigation steps 1

  1. Open the returned certificate.

  2. Verify the validity of the certificate.

  3. If the certificate isn't valid, request a new certificate and update it in Access Gateway Management console.

  4. Test the application.

Validation and mitigation steps 2

  1. Verify whether the browser trusts the URL of the application.

  2. Add the URL of the application and all other Access Gateway endpoints under the trusted zone settings in the browser.

  3. Restart the browser.

  4. Test the application.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Unexpected Appliance Behavior

Possible cause

The browser cache can cause unexpected behaviors to occur in applications or the Access Gateway.

Validation and mitigation steps

  1. Clear the browser cache and retest.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Multiple Application Certificate Errors

  1. When accessing an application, the browser is showing a certificate warning and takes the user to the application once the user clicks the proceed link.

  2. The application fails to open and the user receives an Access Gateway error page.

  3. The application works normally if it's opened in the same browser session as used previously.

    Possible cause

    • This can happen when a browser doesn't trust the certificate. When the user clicks the proceed link, the browser doesn't post data to the SAML endpoint and the SAML assertion ends up failing.

    • When the application is opened again in the same browser session, the browser trusts the URL the next time because it has permission from the user to trust the URL, so it posts the correct data to the SAML endpoint.

Validation and mitigation steps

Temporary fix - local system only

Add the Access Gateway client certificate to the browser’s trust store. Here's an example for Internet Explorer:

  1. From the application page, open the certificate in the browser and export it to the local machine.
  2. Open Internet Options.
  3. Go to the Content tab.
  4. Click Certificates.
  5. In the pop up window, go to Trusted Root Certification Authorities.
  6. Click Import**.
  7. Click Next > Next > Finish*.
  8. Click Yes in the security warning window to proceed with the installation.
  9. Click OK and close all open windows.
  10. Restart the machine if it still doesn't work.
  11. Retest the login

Permanent fix - for all systems

  1. Procure a valid certificate.

  2. Update the certificate on the Access Gateway appliance.

  3. Update the certificate on the load balancer if it's the load balancer that presents the certificate.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Redirect Looping

Internet Explorer can experience opening/closing of tabs or redirecting in a loop.

Possible cause 1

The browser doesn't trust the application or the Access Gateway endpoints.

Validation and mitigation steps 1

  1. Add the Access Gateway hostname endpoint and application endpoint URLs to the Trusted Zone settings in IE settings.

Possible cause 2

If you're using a load-balanced solution, the browser resolves the Access Gateway hostname to one node and the application public domain to another node.

Validation and mitigation steps 2

  1. Verify that the load balancer enforces sticky sessions.

  2. Ping the Access Gateway hostname and the application public domain to verify that they're resolving to different IP Addresses.

  3. Update the local hosts file or DNS entry to match the correct IP Addresses.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Invalid IdP API Key

Possible cause

The IdP API token has been deleted from the IdP.

Validation and mitigation steps

  1. Create a new IdP API token in the IdP under Security > API Menu.
  2. Update the API Key in the Access Gateway under Setting > Identity Providers.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

App Name is Out of Sync

<App Name> is out of sync with IdP. Would you like to recreate this application is <IDP Org name>?

Possible cause

The application has been deleted from IdP.

Validation and mitigation steps

  1. Ensure that the API key used to configure the Access Gateway is still active. If not, continue with the following steps.

  2. Delete the existing application from Access Gateway.

  3. Confirm that the application is deleted from the IdP before re-creating the app.

  4. Add the application again in the Access Gateway.

  5. Ensure that the application has been created in the IdP.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Site can't be reached or displayed

Possible cause

The browser is unable to reach the site. The root cause could be that the application or Access Gateway services aren't running or the DNS entry is missing.

Validation and mitigation steps

  1. Restart the Access Gateway service or the back-end app if it isn't responding.
  2. Add the required DNS entry in the DNS or local hosts file.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

Setup/app creation becomes unresponsive

The progress indicator keeps spinning during initial setup or while creating an application in the Access Gateway.

Possible cause

This happens when the Access Gateway fails to reach the designated IdP.

Log statement

Mar 7 17:19:43 localhost.localdomain WEB_CONSOLE IOException occurred validating IDP host :IDP login URL

Validation and mitigation steps

  1. Verify that the Access Gateway appliance is able to connect to the IdP.

  2. Look for the component that is blocking the connection and allow the connection to the IdP.

  3. Verify the connectivity to the IdP from the Access Gateway appliance.

  4. Ensure that the Client ID and Client Secret values are correct.

  5. Validate the IdP configuration in Access Gateway and save the settings.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?

TLS page doesn't appear

Possible cause

This happens when a browser’s TLS security settings don't properly authenticate a secure connection with Access Gateway.

Log statement

Apr 16 10:55:41 test-oag icsDefault443Error 2018/04/16 10:55:41 [crit] 18480#0: *3047 SSL_shutdown() failed (SSL: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init) while SSL handshaking, client: Client IP address, server:0.0.0.0:443 Apr 16 10:55:41 test-oag icsDefault443Error 2018/04/16 10:55:41 [crit] 18480#0: *3047 SSL_shutdown() failed (SSL: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init) while SSL handshaking, client: Client IP address, server:0.0.0.0:443

Validation and mitigation steps

  1. In Internet Explorer, click the Settings menu.

  2. Select Internet Options.

  3. Click the Advanced tab.

  4. Scroll to the SSL/TLS settings under the Security section.

  5. Ensure that IE uses: TLS 1.1, 1.2, and 1.3.

  6. Click Apply.

  7. Click OK.

Did the preceding steps solve your problem? If not, submit a support ticket for assistance.

What problem do you have?