When attempting to access an Okta Access Gateway (OAG) application, the access fails with OAG logs showing the following example 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 OAG should be proxying to)
• The policy applied to this access request includes a custom directive with proxy_pass
• At the time of the error, DNS resolution to the Protected Resource (and/or any additional URL's set in proxy_pass) is successful, but there may have been a DNS resolution issue in the past

• Okta Access Gateway (OAG)

When NGINX applies a policy that includes "proxy_pass" directive where the value of "proxy_pass" is a hard set URL, NGINX only queries DNS for that URL at the time of NGINX reload (or restart). At that point, it will use that DNS resolution indefinitely.

So this issue usually indicates that at the time of the last NGINX reload, OAG was unable to query DNS for the proxy_pass URL's. Therefore OAG has indefinitely cached and continues to try to use the "spoof" IP address 0.0.0.2 which unbound service assigns to a FQDN that it can not resolve in DNS.

1. For an immediate solution, verify that DNS resolution for all proxy_pass URLs and Protected Resources is successful and then reload or restart NGINX.
2. To check DNS resolution, please refer to this DNS Lookup.
3. To reload NGINX, simply update/save any existing OAG application.
4. To restart NGINX, please refer to this NGINX Service.
   • NOTE: If the NGINX configuration is not in good status, restarting NGINX can prevent it from properly starting back up. Therefore, please carefully check the status of the NGINX service before restarting.
5. To avoid issues in the long term, 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:

proxy_pass https://<testapplication.url> ;

To:

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

This should prevent the issue going forward because, when proxy_pass URL is set as a variable, NGINX will dynamically query the FQDN using the resolver directive (in the above example, DNS will be queried every 30 seconds; this can be adjusted as desired) instead of indefinitely caching the DNS resolution at the time of NGINX reload.

Related References

• Management Console Command Line Reference - Services
• DNS Lookup