oauth url does not work with OCI LB reverse proxying in front of OCI LB for OSO

[sonykphilip]

We are trying to put one more OCI LB with SSL termination + WAF in front of the OCI LB for an OSO cluster for console-openshift-console.apps and oauth-openshift.apps, but the oauth URL fails with "Application is not available".

Very similar to the case when reverse proxying using NGINX, which has a fix by using proxy_ssl_name:

Resolution
Your Nginx reverse proxy template must also include the following parameter:

proxy_ssl_name $host


location / {
    proxy_pass https://server2.example.com;
    proxy_set_header Host $host;
    proxy_ssl_name $host;
    proxy_ssl_server_name on;
    proxy_ssl_session_reuse off;
    ...
}
Add proxy_ssl_name in order to make sure that nginx knows what name to pass to the route address.

Root Cause
See: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_name
This proxy configuration line allows overriding the server name used to verify the certificate of the proxied HTTPS server and to be passed through SNI when establishing a connection with the proxied HTTPS server. This is necessary when handling auth calls to the Oauth route in an indirect manner.
Diagnostic Steps
Observe that calls to console and other applications are forwarded correctly through your reverse-proxy, but oauth calls fail out or are met with 503 service unavailable errors.

Do you know how something similar can be done when using an OCI LB? Oracle support hasnt been of ANY help.
TIA.

[dfoster-oracle]

I took a stab at this yesterday, changed the listener and health checker for the apps LB from TCP to HTTP, but I didn't have much luck reproducing the scenario. I still need to configure an SSL certificate for the domain I use for testing.

Our team is strapped for resources for the moment, but this should change within a reasonable amount of time. Thank you for creating this issue and for your patience. If you have any other information that you can share, please do.

[sonykphilip]

Thanks for taking the time out to look at this, @dfoster-oracle.
Let me break it down even further. The "OSO" LB is left untouched and still using TCP, but placing an additional OCI LB (HTTP with SSL termination) in front of this is what breaks the oauth route, but it seems to work for regular deployments on other *.apps routes.

Client -> OCI HTTP LB (443) -> OSO TCP LB (443) --> OCP

Using the example from my original post, it would be:
Client -> NGINX (443) -> TCP LB -> OCP