search

NginxProxyManager / nginx-proxy-manager

Docker container for managing Nginx proxy hosts with a simple, powerful interface
https://nginxproxymanager.com
MIT License
21.91k stars 2.53k forks source link

Question: Forward to two Ports for the same Hostname? #484

Open redtripleAAA opened 4 years ago

redtripleAAA commented 4 years ago

What is troubling you? Is it possible to forward to two Ports for the same Hostname?

Screenshot: One port - one hostname

I am trying to use the proxy in front of ESXI server. It works fine when uses (443) as the screenshot above, however when I connect to a virtual machine, it fails, which I assume because it's looking for the second port (902)

KB from VMWare: https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.upgrade.doc/GUID-5071C86E-FF1E-4E54-A424-A20917401160.html

error missing port 902

Note: everything works fine when I bypass the Proxy Manager, and connect directly to the internet or locally.

Please advise.

ajagnanan commented 3 years ago

would like to know this too

sysadmininator commented 3 years ago

I have the web console and vmrc working through a different nginx reverse proxy container/project (which I believe is a little more vanilla) using some config files I found on a vmware forum a while back. The important bits seem to be adding the below code to your nginx.conf file:

#vmrc passthru

stream {

        upstream bninetwo {
                server sub.yourdomain.com:902;
        }

        upstream bninethree {
                server sub.yourdomain.com:903;
        }

        #upstream bfourtwoseven {
        #       server [internal IP of your ESXi host]:427;
        #}

        server {
                listen 902;
                proxy_pass bninetwo;
        }

        server {
                listen 902 udp;
                proxy_pass bninetwo;
        }

        server {
                listen 903;
                proxy_pass bninethree;
        }
        #server {
        #       listen 427 udp;
        #       proxy_pass bfourtwoseven;
        #}
}

As you can see I have things for 427 commented out. I wish I could tell you why exactly. Perhaps I was never able to get it to work, or it's not important to my setup, or both.

A couple of things about my environment: 1) I'm connecting to a vCenter server, not an individual host, and 2) I installed my vCenter deployment to use an IP address and not an fqdn internally.

I've only recently started to poke at this project and move my sites over, so I'm not exactly sure where this custom config would go (in the UI, obviously it can go into the nginx.conf file... I'm just not sure if that messes with any automations/checks this project employs). I assumed it would fall under the Advanced > Custom Nginx Configuration section for your host. However in my quick testing, it looks like applying the snippet above causes a failure where the "'stream' directive is not allowed here". I'm sure there's a proper method of modifying the nginx.conf file within the confines of this project, but I haven't gone searching for that quite yet. Regardless, I hope the configs above help!

binarymime commented 3 years ago

Any further updates on this. Thsi also affects uploading files to the esxi data store. Pasting the above code into the Advanced page of the Proxy host services puts the server offline. Is there a way to add the custom config via the GUI.

Thanks

binarymime commented 3 years ago

Quick update. I was able to get the above working by adding the following code snippet, add this to the Custom Nginx Configuration code window in the Advanced tab of the Proxy Host:

I'm sure this goes without saying but replace <HostIP> with the IP of your Proxy Host

location /sdk/ {
     proxy_pass https://<HostIP>/sdk/;
     proxy_redirect default;
}

location /ticket/ {
     proxy_pass https://<HostIP>/ticket/;
     proxy_redirect default;
     proxy_http_version 1.1;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header Upgrade $http_upgrade;
     proxy_set_header Connection $http_connection;
}

location /screen {
    proxy_pass https://<HostIP>/screen;
    proxy_redirect default;
sysadmininator commented 3 years ago

Can confirm that the configs from @binarymime do the trick.

If anyone else continues to have issues with their setup, I will note that these settings didn't initially work for me. My vCenter appliance (v6.7) had been deployed with a static IP and the hostname was left at the default photon-machine. I had to change hostname in the VAMI console to use the fqdn (same as the proxy host/cert address). I had even tried adding some other locations such as /ui, /websso, but no matter what I would get redirected to the internal IP address somewhere between /ui and /websso (which would break completely externally and cause an incorrect redirect internally). Anyway, once the hostname was updated it was pretty smooth sailing from there. Thanks again to @binarymime !

Oninaig commented 1 year ago

I have the web console and vmrc working through a different nginx reverse proxy container/project (which I believe is a little more vanilla) using some config files I found on a vmware forum a while back. The important bits seem to be adding the below code to your nginx.conf file:

#vmrc passthru

stream {

        upstream bninetwo {
                server sub.yourdomain.com:902;
        }

        upstream bninethree {
                server sub.yourdomain.com:903;
        }

        #upstream bfourtwoseven {
        #       server [internal IP of your ESXi host]:427;
        #}

        server {
                listen 902;
                proxy_pass bninetwo;
        }

        server {
                listen 902 udp;
                proxy_pass bninetwo;
        }

        server {
                listen 903;
                proxy_pass bninethree;
        }
        #server {
        #       listen 427 udp;
        #       proxy_pass bfourtwoseven;
        #}
}

As you can see I have things for 427 commented out. I wish I could tell you why exactly. Perhaps I was never able to get it to work, or it's not important to my setup, or both.

A couple of things about my environment: 1) I'm connecting to a vCenter server, not an individual host, and 2) I installed my vCenter deployment to use an IP address and not an fqdn internally.

I've only recently started to poke at this project and move my sites over, so I'm not exactly sure where this custom config would go (in the UI, obviously it can go into the nginx.conf file... I'm just not sure if that messes with any automations/checks this project employs). I assumed it would fall under the Advanced > Custom Nginx Configuration section for your host. However in my quick testing, it looks like applying the snippet above causes a failure where the "'stream' directive is not allowed here". I'm sure there's a proper method of modifying the nginx.conf file within the confines of this project, but I haven't gone searching for that quite yet. Regardless, I hope the configs above help!

I know this is SUPER old but I am running into the same issue where I can view the web console just fine in ESXI and I have the exact config that you posted in my nginx.conf but if I try to run VMRC I get "could not negotiate SSL" and the VMRC logs contain:

2023-03-13T16:50:09.725Z| mks| W003: SSL: Unknown SSL Error
2023-03-13T16:50:09.725Z| mks| I005: SSL Error: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2023-03-13T16:50:09.725Z| mks| W003: SOCKET 2 (1756) Could not negotiate SSL
2023-03-13T16:50:09.725Z| mks| W003+ The remote host certificate has these problems:
2023-03-13T16:50:09.725Z| mks| W003+ 
2023-03-13T16:50:09.725Z| mks| W003+ * unable to get local issuer certificate
2023-03-13T16:50:09.725Z| mks| W003: SOCKET 2 (1756) Expected thumbprint doesn't match actual thumbprint.
2023-03-13T16:50:09.725Z| mks| W003: Expected thumbprint is: FA:D6:05:91:B8:C6:F5:98:9D:73:27:89:A9:0B:70:B3:FF:A3:BC:7B
2023-03-13T16:50:09.725Z| mks| W003+   Actual thumbprint is: A1:3B:BD:54:2C:9A:92:42:E3:CF:B1:5B:48:C7:D4:86:D4:9E:BC:B3
2023-03-13T16:50:09.725Z| mks| W003: SOCKET 2 (1756) Cannot verify target host.
2023-03-13T16:50:09.725Z| mks| W003: MVNCClient: received socket error 13: Connection error: could not negotiate SSL
2023-03-13T16:50:09.725Z| mks| I005: MVNCClient: Setting vncClient.mksConnectionError, previous error is 0, new error is 1
2023-03-13T16:50:09.725Z| mks| I005: MVNCClient: Destroying VNC Client socket.

Meanwhile the access error logs for the proxy don't report anything wrong other than some caching warnings:

2023/03/13 16:46:55 [warn] 342#342: *50264 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/5/01/0000000015 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /ui/bower_components/vui-bootstrap/css/vui-bootstrap.min.css HTTP/2.0", upstream: "https://192.168.1.41:443/ui/bower_components/vui-bootstrap/css/vui-bootstrap.min.css", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:46:55 [warn] 342#342: *50264 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/6/01/0000000016 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /ui/styles/main.css HTTP/2.0", upstream: "https://192.168.1.41:443/ui/styles/main.css", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:46:55 [warn] 342#342: *50264 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/7/01/0000000017 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /ui/bower_components/es6-shim/es6-shim.min.js HTTP/2.0", upstream: "https://192.168.1.41:443/ui/bower_components/es6-shim/es6-shim.min.js", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:46:55 [warn] 342#342: *50264 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/8/01/0000000018 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /ui/bower_components/requirejs/require.js HTTP/2.0", upstream: "https://192.168.1.41:443/ui/bower_components/requirejs/require.js", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:46:55 [warn] 342#342: *50264 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/9/01/0000000019 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /ui/scripts/main.js HTTP/2.0", upstream: "https://192.168.1.41:443/ui/scripts/main.js", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:49:23 [warn] 328#328: *8 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/1/00/0000000001 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /ui/bower_components/vui-bootstrap/css/vui-bootstrap.min.css HTTP/2.0", upstream: "https://192.168.1.41:443/ui/bower_components/vui-bootstrap/css/vui-bootstrap.min.css", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:49:23 [warn] 328#328: *8 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/2/00/0000000002 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /ui/bower_components/requirejs/require.js HTTP/2.0", upstream: "https://192.168.1.41:443/ui/bower_components/requirejs/require.js", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:49:23 [warn] 328#328: *8 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/3/00/0000000003 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /ui/scripts/main.js HTTP/2.0", upstream: "https://192.168.1.41:443/ui/scripts/main.js", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:49:25 [warn] 328#328: *109 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/4/00/0000000004 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /sdk/vim.wsdl HTTP/2.0", upstream: "https://192.168.1.41:443/sdk/vim.wsdl", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:49:25 [warn] 328#328: *109 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/5/00/0000000005 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "GET /sdk/vim-types.xsd HTTP/2.0", upstream: "https://192.168.1.41:443/sdk/vim-types.xsd", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:50:04 [warn] 327#327: *212 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/6/00/0000000006 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "POST /sdk/ HTTP/2.0", upstream: "https://192.168.1.41:443/sdk/", host: "esxi.mydomain.io", referrer: "https://esxi.mydomain.io/ui/"
2023/03/13 16:50:09 [warn] 328#328: *305 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/7/00/0000000007 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "POST /sdk HTTP/1.1", upstream: "https://192.168.1.41:443/sdk", host: "esxi.mydomain.io"
2023/03/13 16:50:09 [warn] 327#327: *311 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/8/00/0000000008 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "POST /sdk HTTP/1.1", upstream: "https://192.168.1.41:443/sdk", host: "esxi.mydomain.io"
2023/03/13 16:50:09 [warn] 327#327: *310 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/9/00/0000000009 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "POST /sdk HTTP/1.1", upstream: "https://192.168.1.41:443/sdk", host: "esxi.mydomain.io"
2023/03/13 16:50:09 [warn] 327#327: *310 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/0/01/0000000010 while reading upstream, client: 192.168.1.96, server: esxi.mydomain.io, request: "POST /sdk HTTP/1.1", upstream: "https://192.168.1.41:443/sdk", host: "esxi.mydomain.io"

Are you still able to access your VMs via VMRC and if so did you have to import your letsencrypt cert that you can download from NRPM into the esxi web interface? I tried that as well and whenever I swapped the default certs for the ones provided by LE via NRPM I would be unable to access the web interface anymore.

sysadmininator commented 1 year ago

I'm sorry to say that I don't use this nginx/proxymgr for vmrc access anymore. Moved away from it about a year ago when my lab developed some other criteria that took me elsewhere.

I do remember parts of the setup though and am almost certain that I never had to copy any LE certs around. I also remember that the conf file didn't change and I took it out of commission right around vCenter 6.7 U2 or U3.

Wish I could be of more help! 🤞🏻 that @binarymime is still roaming the halls and might have something to add. Best of luck either way.

Oninaig commented 1 year ago

I'm sorry to say that I don't use this nginx/proxymgr for vmrc access anymore. Moved away from it about a year ago when my lab developed some other criteria that took me elsewhere.

I do remember parts of the setup though and am almost certain that I never had to copy any LE certs around. I also remember that the conf file didn't change and I took it out of commission right around vCenter 6.7 U2 or U3.

Wish I could be of more help! 🤞🏻 that @binarymime is still roaming the halls and might have something to add. Best of luck either way.

Thanks for the quick reply anyway, what are you using now? I also tried copying the LE certs from NPM to the ESXI host but that just caused the ESXI host to throw "connection refused" errors when I would try to connect afterwards.

sysadmininator commented 1 year ago

Thanks for the quick reply anyway, what are you using now?

A tunneling/access solution from a company that rhymes with Schmoudflare ;). Which actually looks like it has challenges and limitations supporting vmrc as well but because I moved away from my vCenter server altogether I was able to let this one go at the same time.

I also tried copying the LE certs from NPM to the ESXI host but that just caused the ESXI host to throw "connection refused" errors when I would try to connect afterwards.

I noticed that you specified ‘ESXi host’ again in your follow up so I want to make sure I clarify on something else from above. I could be incredibly wrong here, but I have memory of this config not working with ESXi hosts directly. I want to say that the only time I had success with it was with a vCenter server instance (the photon based virtual appliance from VMware if that matters). I hope I’m misremembering this for the sake of your troubleshooting, but if you have a vCenter trial and a little bit of time to burn through it might be worth a spin. And many apologies in advance if that doesn’t pan out to be true.

Edit: I reviewed my comment history above and it seems to agree with my memory that I was running vCenter server at the time. I also want to say that at one point I could tell you why the config worked with vCenter and not a host directly (and that it had something to do with the way the two products serve up their pages/services) but it would honestly be shots in dark based on what is likely now old information anyway.

Oninaig commented 1 year ago

Success! I finally figured out what the issue was. After banging my head against the wall because I could not find anyone out there who is trying to do this with ESXI 7.0 without VCenter, I started to dig into the innards of LetsEncrypt and Certbot and the various errors I was getting in my hostd log in ESXI.

It turns out that by default LetsEncrypt will generate certificates with a key type of ECDSA. If you modify your letsencrypt.ini file and change the type back to RSA (what it used to be a long time ago) and generate the cert yourself via the command line within the running NPM container and then copy those certs to your ESXI instance then the cert will work with ESXI and VMRC without issues.

I have not yet attempted this via NPM exclusively (changing the config to use RSA keys and then just using the reverse proxy to pass the SSL connection to ESXI/VMRC). Right now my setup is that every internal service I have running is DNS'd to NPM except for ESXI which has its own DNS entry pointing towards its actual IP address and domain name (which matches the cert).

Posting this here in case anyone else stumbles across this issue.

github-actions[bot] commented 5 months ago

Issue is now considered stale. If you want to keep it open, please comment :+1: