Okta Access Gateway (OAG) caches a failed Domain Name System (DNS) resolution indefinitely when a proxy pass directive uses a hard-set URL, causing application access to fail. Verify the DNS resolution and reload the NGINX service to resolve the error. When attempting to access an Okta Access Gateway application, the access fails, and Okta Access Gateway logs display the following error:

*2024-02-20T11:34:40.000-08:00 oagworker.test.com oagworker.test.com xkK43azm1: 2024/02/20 11:34:40 [crit] 3814255#0: 6252803 connect() to 0.0.0.2:35490 failed (22: Invalid argument) while connecting to upstream, client: 192.168.2.2, server: public.test.com, request: "GET /resource HTTP/1.1", upstream: "https://0.0.0.2:35490/resource", host: "public.test.com"

The error refers to a connection attempt to 0.0.0.2, which is not the actual IP address of the protected resource that Okta Access Gateway proxies. The policy for this access request includes a custom directive with a proxy pass. At the time of the error, DNS resolution to the protected resource or any additional URLs present in the proxy pass succeeds, but a DNS resolution issue occurred previously.

• Okta Classic Engine
• Okta Identity Engine (OIE)
• Okta Access Gateway (OAG)

When NGINX applies a policy that includes a proxy pass directive where the value is a hard-set URL, NGINX only queries the Domain Name System (DNS) for that URL at the time of an NGINX reload or restart. NGINX uses that DNS resolution indefinitely. This issue indicates that at the time of the last NGINX reload, Okta Access Gateway was unable to query the DNS for the proxy pass URLs. Okta Access Gateway indefinitely caches and continues to use the spoof IP address 0.0.0.2, which the unbound service assigns to a Fully Qualified Domain Name (FQDN) that it cannot resolve in the DNS.

How is the invalid argument error resolved?

Verify the Domain Name System (DNS) resolution for all proxy pass URLs and protected resources, reload or restart NGINX, and reconfigure custom policies to use variables instead of hard-set URLs by following these steps.

1. Verify that the DNS resolution for all proxy pass URLs and protected resources succeeds. Refer to DNS Lookup for instructions on checking the DNS resolution.
2. Reload NGINX by updating and saving any existing Okta Access Gateway application. Alternatively, restart NGINX by following the instructions in Management Console Command Line Reference - Services.
   NOTE: If the NGINX configuration lacks a good status, restarting NGINX prevents it from properly starting back up. Check the status of the NGINX service before restarting.
3. Ensure that the DNS environment is reliable and reconfigure any custom policies so that they include resolver directives and that any proxy pass directives use a variable instead of a hard-set URL. For example, update the following configuration:

proxy_pass https://<testapplication.url> ;

To the following configuration:

resolver 127.0.0.1 valid=30s ;
set $<set_variable_name> https://<testapplication.url>  ;
proxy_pass $<set_variable_name> ;

When the proxy pass directive uses a variable, NGINX dynamically queries the Fully Qualified Domain Name (FQDN) using the resolver directive instead of indefinitely caching the DNS resolution at the time of the NGINX reload.

Related References

• Management Console Command Line Reference - Services
• DNS Lookup
• How to Test Okta Access Gateway DNS and Understanding the Unbound Service