I'm curious, what are you trying to do for a use case, where this configuration is required?

---

Here we don't have many public IP's. So we point all the domains to one VM, on which we setup a reverse proxy (redirect request) to another VM which has only an internal IP.



I have a domain registered for prism console as well, so that we can accesss the domain rather than the IP as well as can be accessible outside out network as well, but the same configuration I followed for other sites didn't work with prism.



Attaching sample configuration below



server {

listen 80;

server_name example.com

location / {

proxy_set_header Host example.com;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-Proto http;

proxy_set_header X-Forwarded-For $remote_addr;

proxy_set_header X-Forwarded-Host $remote_addr;

proxy_pass https://172.x.x.x:9440/;

#proxy_connect_timeout 240;

#proxy_send_timeout 240;

#proxy_read_timeout 240;

/// Added this code to set the cookie, but didn't worked

if ($http_cookie ~* "jsessionid=([^;]+)(?:;|$)") {

set $co "jsessionid=$1";

}

proxy_set_header Cookie "$co";

/// Code END

}

}

---

Is that to say you are trying to use a Public IP to access Prism from the internet?

---

Yes

---

Hi Ravi,



Is the cookie not being set the main problem you are having, can you describe the issues you are having in details? A screenshot with the dev console from the browser would be also helpful.



Thanks,

- Ray

---

At first glance, two things worth trying:

1) Move the proxy_pass directive to the end of that section (after the set_cookie portion)

2) Rather than the cookie method you're looking at, maybe take a look at the following parameters proxy_cookie_domain:

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cookie_domain

---

Apologies for delayed response



I've tried the suggested steps but still the problem exists

---

Apologies for delayed response.



I think that the cookie is the problem.

Find the image of the network requests that are being made when setting the configuration

---

Ravi,I appreciate that this has been unresolved for almost a year so I'm assuming you found the answer(s) already. Just in case, and for the sake of documentaiton, here are two pointers. Full disclosure: I work for NGINX and am just starting to dig into the Nutanix platform, so YMMV. 1) To set a new cookie with NGINX, you need use the 'add_header Set-Cookie' directive instead of 'proxy_set_header'. The format using your example would be 'add_header Set-Cookie jsessionid=$co;' (note that in this case you would need to remove 'jsessionid' from your $co set). 2) NGINX Plus, the commercial version of NGINX, supports additional load balancing methods which can read and learn a jsessionid from the app. Being new to Nutanix I'm not sure this is what you're looking for, but simply based on your if statement where you're looking for a jsessionid I assume this is the same use case. You can find documentation on jsessionid learning on nginx.org. Hope that helps all these months later. ravismula wrote:Here we don't have many public IP's. So we point all the domains to one VM, on which we setup a reverse proxy (redirect request) to another VM which has only an internal IP.



I have a domain registered for prism console as well, so that we can accesss the domain rather than the IP as well as can be accessible outside out network as well, but the same configuration I followed for other sites didn't work with prism.



Attaching sample configuration below



server {

listen 80;

server_name example.com

location / {

proxy_set_header Host example.com;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-Proto http;

proxy_set_header X-Forwarded-For $remote_addr;

proxy_set_header X-Forwarded-Host $remote_addr;

proxy_pass https://172.x.x.x:9440/;

#proxy_connect_timeout 240;

#proxy_send_timeout 240;

#proxy_read_timeout 240;

/// Added this code to set the cookie, but didn't worked

if ($http_cookie ~* "jsessionid=([^;]+)(?:;|$)") {

set $co "jsessionid=$1";

}

proxy_set_header Cookie "$co";

/// Code END

}

}

---

@Jon  one possible answer to your curiosity about a reverse proxy in front of PC is for a better UX with Self-Service. For example, we’re using Prism Central Self-Service for our developers to provision VMs. We don’t want to give them a URL with port 9440 and we want to publish some FAQs. We tried to reverse proxy PC with nginx, but we had issues (path based reverse proxying and nginx caching). So, we ended up with a landing page with links to PC and FAQs. 

(1) Is this expected behavior with reverse proxying PC? Anybody has this working?

(2) Can PC be configured to listen on 443? The last I checked, the answer was “no”.

---

1 - I doubt that anyone actually tried it internally here, so I dont know one way or the other if reverse proxying would work well or not offhand

2 - No, Prism (element and central) is published on 9440 as a static thing. I think someone sufficiently crafty could hack it in, but it may blow up in fantastic ways since that is not something we support/qa (changing the prism port)

---

@Jon  Thank you for getting back. So, I tried reverse proxying the PC and after initial hiccups with nginx caching, path-based reverse proxying and web sockets reverse proxying causing login failures and VM console access issues, I’ve finally had it working with the following config:

 

        location / {
          proxy_pass https://cloudconsole;
          proxy_intercept_errors on;
          proxy_set_header        Host $host;
          proxy_set_header        X-Real-IP $remote_addr;
          proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header        X-Forwarded-Proto $scheme;
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "upgrade";
        }

 

cloudconsole refers to the upstream PC URL.

Didn’t find anything broken so far when accessing the PC via the reverse proxy.

 

---

cool, good work!

---