Homelab,Network Infrastructure,Virtual Machines

Accessing ESXi Remotely via NGINX Reverse Proxying

As part of setting up my “vms from anywhere” system, I wanted to be able to access my ESXi web consoles over the web. If you read my post about reverse proxies, you know I have a basic NGINX server running on my LAN that proxies the rest of my web applications out over HTTPS based on request subdomains.

I’m going to preface these notes with a warning: there’s a bunch of security issues with opening up an ESXi portal to the internet in production (or honestly, even in a home lab). Bad actors can very quickly lock you out via DDOS on the root account login – which will keep you out of your entire ESXi host for as long as they want. Leaving the portal open to the web is also begging for brute forcing, and exposes details of your infrastructure that would probably be better if closely held. That said, I felt like addressing these at a later date since nothing I’m hosting is mission critical at the moment. Once I’m less pressed for time, I’ll likely have another post where I’m working on making this setup secure sometime down the road. In other words – I’m making a bad (temporary) decision, and its fine. Just don’t blindly copy things unless you accept the limitations.

Naively, I decided I’d start by just plugging in my ESXi management address as a basic server block (just like I did for my iLo portals):

server{
   listen 443;
   server_name esxi.dupuis.xyz;
   ssl on;
   ssl_certificate /etc/letsencrypt/live/dupuis.xyz/fullchain.pem;
   ssl_certificate_key /etc/letsencrpyt/live/dupuis.xyz/privkey.pem;
   location / {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-Proto https;
      proxy_redirect off;
      proxy_http_version 1.1;
      proxy_pass https://192.168.1.15;
   }
}

This setup allowed me to access the ESXi web interface, but none of the remote console services worked (either in the browser or on my machine via VMWare Remote Console):

With the basic proxy setup above, we can access everything but the remote console…

Turning to Google, I found Damion Brown’s BasicAuth recommended setup for ESXi proxies on GitHub. Damion fixes some of the ESXi insecurity by hiding the management proxy behind a basic auth login. I didn’t feel like dealing with double login screens on my setup, so I skipped that part of his code and basically just adopted a bunch of his header forwarding options and proxy timeout settings, since he’d already tuned them for ESXi. The result was the following server configuration block:

server {
   listen 443 
   server_name esxi.dupuis.xyz;

   ssl on;
   ssl_certificate /etc/letsencrypt/live/dupuis.xyz/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/dupuis.xyz/privkey.pem;

   location / {
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-Server $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Authorization "";
      proxy_redirect off;

      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Origin "";
      proxy_pass_header X-XSRF-TOKEN;
      proxy_pass https://192.168.1.15;
      proxy_send_timeout      300;
      proxy_read_timeout      300;
      send_timeout            300;
      client_max_body_size    1000m;

      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
   }
}

This got me most of the way there – I could use the HTML5 remote console, but was still getting certificate mismatch errors from both Chrome and ESXi. The desktop Remote Console application also wouldn’t connect, giving me “HTTP Error 401 Unauthorized” after the console started to load. I figured that the easiest way to fix what appeared to be a certificate mismatching error would be to just install the actual site certificates on ESXi – that way, the reverse proxy wouldn’t be stripping anything out, and both the client and server sides would be looking at the same keys with the same domain information.

Thankfully, VMware has docs about replacing default certificates from the ESXi shell. I started by renaming the old certificate and key as a backup. I then ran a remote copy of my SSH full chain certificate and key using scp from my Ubuntu network management VM to my ESXi server, and renamed the new certificates the match what ESXi is expecting:

mv rui.crt orig.rui.crt
mv rui.key orig.rui.key

scp /etc/vmware/ssl user@remoteserver:/etc/letsencrypt/live/dupuis.xyz/fullchain.pem 
scp /etc/vmware/ssl user@remoteserver:/etc/letsencrypt/live/dupuis.xyz/privkey.pem

mv fullchain.pem rui.crt
mv privkey.pem rui.key

At this point, I rebooted my ESXi server – I probably didn’t have to, but it felt like a good measure to get everything to a stable point. Following the reboot, I was able to connect to a Remote Console from the desktop application successfully, and there were no more certificate errors in the browser:

Browser and desktop ESXi Remote Consoles both worked once the proxy settings and SSL certificates were correctly configured – VM console access anywhere!

I’m really pleased with the setup, aside from the glaring security holes – but we’ll patch those later. For now, I’m able to fully control my VMs from anywhere in the world, and that’s enough for me!

Hopefully this post is useful to configure ESXi on your remote proxy setup – if you have a question, or if there’s something I did wrong/could do better, leave a comment and I’ll get back to you as soon as I have a second. Thanks for reading!

Leave a Reply

Your email address will not be published. Required fields are marked *