HTTP -> HTTPS redirect in admin panel won't work

[AlexWoIf]

Due to 9098->8083 mapping Nginx can't redirect properly from HTTP to HTTPS admin panel.
It use instruction error_page 497 https://$host:$server_port$request_uri; in ./vesta/local/vesta/nginx/conf/nginx.conf But $server_port will always 8033 in spite of any port mappings.
Finally I've switch mapping to 8083->8083 but create fake subdomain vestacp.mygreatsite.com and strict access to admin panel only by using the name vestacp.mygreatsite.com:8083. (I've add approapriate record in my host file for this way.) All other domains on port 8083 will drop to default server for this port and will recieve 400 error page.

    server {
        listen          8083 default;
        ssl                  on;
        ssl_certificate      /usr/local/vesta/ssl/certificate.crt;
        ssl_certificate_key  /usr/local/vesta/ssl/certificate.key;
        server_name     _ "";
        return  400;
    }

[noogen]

I don't understand, do you have a question or is this an instruction?

The reason you/we use 9098 or a different port because we want to be safe with generic known Vesta security issue scans; but yes, it will create this issue. I rather have this problem than exposing myself to Vesta 0-days security issue; and yes, we've had several incidents like this in the past. See Vesta forum. Though I don't have an issue because I use different port and no report with any users running this docker.

If you are providing instruction, I'd like to note that there are many other ways to work-around the issue, such as proxy-pass it from some port (9098) to Vesta 8083. I'm guessing you're asking why 8083 doesn't work? This is because Vesta run it's own nginx server, yes there are two nginx servers running and one is specific to Vesta, you can see the configuration here /usr/local/vesta/nginx/conf/nginx.conf that have port 8083.

If you want to change or proxy vesta port, you need to look at/update that configuration. It's not very flexible, which make it difficult to change Vesta port. Some kind of a task may have to be setup to update this nginx.conf file on a regular basis to make sure it doesn't get override by update or a new installation.

[AlexWoIf]

It was both a bugreport and a question if my solution bad or good.
You gave me the full answer. Finally I decide that any "random" port will easily discovered by nmap. Doesn't matter 9098 or 8083. But you point me to the new idea: proxy-pass it from some port (9098) to Vesta 8083 Now I configure main public nginx (80 and 443 ports) as reverse-proxy to Vesta admin-panel (8083). And close 9098 and 8083 from outside the server. But this proxy-pass configured on a nonlisted in the DNS domain. In a such way this secret subdomain can't be discovered because it present only in the host file on my workstation and in /home/admin/conf/web/secrerdomain.servername.com.nginx.conf and /home/admin/conf/web/secrerdomain.servername.com.nginx.ssl.conf on VestaCP. This files should be in safe during update VestaCP. For more sure you may create special template (for example "control-panel.tpl" and "control-panel.stpl") and apply it. Thank you very much for this.

[noogen]

I'd like to point out two possible quirks with your setup so you can troubleshoot if running into these issues in the future:

1. Proxy pass should be configured on Vesta nginx, not the website nginx. The reason Vesta run two different Nginx servers is so that when Vesta restart of the public nginx with a bad configuration and break, you can still access Vesta Panel as it run on its own nginx. Otherwise, you have to ssh into Vesta to troubleshoot and restart. This is why my suggestion above was to modify the Vesta nginx.conf. Just want to let you know that you'll need to ssh in if you run into this in the future.

2. HTTP LetsEncrypt SSL willl not work as you're hiding the DNS, but if you can live with self-signed cert or cert error, then this is fine. As a result, you should not set/enable LetsEncrypt SSL on domain with no DNS record; otherwise, it may overwhelm (LetsEncrypt request limit) your server with failed request/retries.

This is why I just live with the original issue of bad port redirect but I have a bookmark so I don't run into bad port redirect.

The better solution I'm suggesting is:

If user provide a $VESTAPORT docker environment name and 8083 is found in vesta nginx conf
  sudo sed -i -e "s/8083/$VESTAPORT/g" /usr/local/vesta/nginx/conf/nginx.conf
  sudo restart vesta

Setup startup script and cron daily for this.