Webconfigurator NGINX 400 Error



  • I changed the webconfigurator port to 8443 in advanced settings.

    Now when accessing the webconfigurator, if I leave off the protocol from the beginning of the url(pfsense.home:8443), nginx replies with an error: "400 Bad Request; The plain HTTP request was sent to HTTPS port"

    If the correct protocol is specified (https://pfsense.home:8443), the webconfigurator loads correctly.

    If the webconfigurator is set to the default port (443), then a bare url works fine and the https redirect is handled correctly.

    It seems like the radio buttons (http, https) on the advanced settings page should set the nginx proxy to redirect to the appropriate url scheme.  Is this something I can fix by editing the nginx config files?  Or should I be submitting a bug report?

    Thanks!

    I am running 2.4.0-BETA (amd64) built on Wed Mar 08 09:06:03 CST 2017.  I am not sure whether or not this error exists in the 2.3 builds, but I do not have another box to test on.



  • This is expected behavior and is working as it should. The default redirect is from port 80 to port 443. When you specify a non standard port for https you're going to have to set up the corresponding redirect for it as well.



  • I'm sorry, maybe I was not clear in my earlier post.

    The issue is not a redirect from port 80 to port 443, it is a url rewrite.  When accessing the webconfigurator at a given port with the "https" button selected, nginx should rewrite the incoming url from http:// to https://.

    I think the default config works because nginx automatically redirects all connections from port 80 to port 443 (telling the browser to redirect to an ssl port).  Here, port 80 is not involved at all.  I am directly connecting to port 8443, which is listening for an SSL connection.  Nginx should be configured to rewrite the url (so that the browser can connect properly).

    If this is still expected behavior, how would I go about adding a rewrite rule to the nginx configuration?

    Thanks!


  • Banned

    Uhm… Considering it's sending HSTS header as soon as you've switched to HTTPS, the described behaviour is very much impossible unless you browser is broken.

    https://github.com/pfsense/pfsense/blob/master/src/etc/inc/system.inc#L1455



  • I've tested on both the latest versions of Chrome and Firefox with the same result.

    After looking a bit more closely, I think what we are really talking about is how pfsense's nginx config handles redirects from http to https.

    Here is how I think things work right now:

    By default, pfsense's nginx listens on two ports: 80 and 443.  When the checkbox "https" is selected, nginx uses a 301 redirect to tell traffic on port 80 to connect to port 443.  If a custom https port is used, then the config redirects to that port instead, keeping port 80 open and listening to do so.

    See here (I think) for the redirect config: https://github.com/pfsense/pfsense/blob/master/src/etc/inc/system.inc#L1548

    This redirect can be disabled via the checkbox labeled "disable webConfigurator redirect rule" on the advanced settings pane.
    However, even if it is disabled, it does not help those using a non-standard https port, as pfsense does nothing to redirect accidental http requests to https on a custom port.

    I think (but please take my uninformed opinion with a grain of salt), when https is selected and a custom port is used, pfsense should use a 497 redirect to rewrite http requests to https.  Nginx defines this (non-standard) status code to allow redirects to a custom ssl port.

    Something like the configuration below could be used:

    listen      8443 ssl;
      server_name pfsense.home;
      ssl        on;
      error_page  497 https://$host:8443$request_uri;

    Thanks, please let me know if I am on the right track.

    Resources:
    http://nginx.org/en/docs/http/ngx_http_ssl_module.html
    https://ma.ttias.be/force-redirect-http-https-custom-port-nginx/


  • Banned

    Once again, it's your browser that should be doing the redirect. Really don't know what you are "fixing" there.



  • Mea Culpa.  I tested on a third computer/browser combo and it seems to work fine.

    Thanks for all your help.