NGINX reverse proxy

[iamsam]

Hello

I need help configure Nginx reverse proxy to Solidfire(Element 12.7) like this :

This is the Nginx config :
server {
listen 10443 ssl;
ssl_certificate /etc/ssl/proxy/server.crt;
ssl_certificate_key /etc/ssl/proxy/server.key;
location / {
proxy_pass https://192.168.1.22:443;
proxy_set_header Host $host;
}
}

On the client machine(10.0.0.22 does not have route to Solidfire MVIP 192.168.1.22) when I browse https://10.0.0.11:10443
The browser stops at URL below, showing ERR_CONNECTION_REFUSED
https://10.0.0.11/auth/connect/authorize?client_id=element-ui&redirect_uri=https://10.0.0.11:10443/cluster/#/auth-callback&response_type=code&scope=op... profile element_api&state=49d0b7181d9e474cbd06af68a927d26b&code_challenge=Hq462Eln6PjwBkjYZb9I0ZgJDD87-CCTcaPga4LgBtk&code_challenge_method=S256&response_mode=query

[elementx]

Obviously you also need to redirect the port 10443.

[iamsam]

Do you mean on Nginx I need to redirect 443/tcp to 10443/tcp ?
I tried :
# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 10443
Now the page stops at
https://10.0.0.11/login/error?ErrorCode=unauthorized_client&RequestId=0HMQPLPOG9AJN:00000001&ErrorDescription=

[elementx]

I don't think you need iptables, NGINX should be enough.

I didn't see at first you used 10443 on NGINX. Can you use 443 and see if any changes are required?

I may give this a try later this week (a bit busy until Thursday).

[iamsam]

I have another cluster (Element 11.7), I can access it using Nginx settings in the first post. And I found this settings also works fine with Element 12.7 API. The problem shows only with 12.7 Web UI. Looks like this is due to the session-based Authentication introduced in Element "12.0" https://library.netapp.com/ecm/ecm_download_file/ECMLP2865022
I still don't know what Nginx options I need to set for Element 12.7 Web UI.

[elementx]

Right, you may need a few additional rows in the NGINX proxy config file.

It shouldn't require any external changes (iptables or such).

[elementx · Accepted solution]

I spent some time trying to get this to work, but without success.

I did get a bit farther by using additional `location` directives, but that wasn't enough.

Normally reverse proxy hits /auth/api/2/account/login which generates a 302 redirect to /auth/connect/authorize/callback. I managed to get redirect_uri to my NGINX public URI, but that was not enough:

https://s137.datafabric.lan:11443/auth/api/2/account/login?returnUrl=%2Fauth%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3Delement-ui%26redirect_uri%...

I think there's another 302 redirect, maybe after successful authentication.

I'm not sure if this can or can't be fixed on a reverse proxy. It would be better if API endpoint redirected to public IP (so, to SolidFire MVIP without NGINX reverse proxy, and to NGINX reverse proxy with NGINX reverse proxy), but it seems hardcoded to use MVIP.

I can't think of other proxy-related workarounds than use a proxy server for the Web UI.

I tried with Squid on Linux, it works fine (client--(http)---> Squid ---> (https) --> SolidFire).

For a more secure approach, a commercial TLS-terminating proxy would be better.

[iamsam]

Can you please share squid.conf you used for web UI ?

[elementx]

I didn't change anything - it's a transparent proxy so it's supposed to work without much per-target tuning.

sudo yum install squid -y

sudo vim /etc/squid/squid.conf

In there, I changed:

acl localnet src 192.168.0.0/16 # RFC 1918 local private network (LAN)

to:

acl localnet src 192.168.1.0/24 # RFC 1918 local private network (LAN)

Then I removed other Class A and B LANs (172.16.*, 10.*) so that only 192.168.1.0/24 is allowed to access Squid (IP:3128). There are additional security features in Squid, but I didn't try them out for this purpose.

Further below I left SSL ports as-is, although you could add 10443, for example

acl SSL_ports port 443

# acl SSL_ports port 443 10443

Then restart Squid service, open firewall port TCP/3128, and on the browser you can add a setting to use Squid (IP:3128) for both HTTP and HTTPS.

That means you now trust network between you and Squid (as you go via non-encrypted TCP/3128 to Squid, and from Squid to SolidFire via HTTPS).

You could set up authentication to Squid, or even - if you have the freedom to do that - setup VPN or use SSH tunnel from your client to Squid 3128, if you needed more security. You could also use firewall settings on the Squid box to limit access to TC/3128 to your (team) workstation(s) IPs on 192.168.1.0/24.

That's all generic Linux/Squid stuff so it should work based on general instructions.