Synology reverse proxy HTTP errors

Tags: #<Tag:0x00007f73a6b34950>

Did you connect the right certificate to your duckdns domain? I use more than one certificates and only one is a default certificate the others you manually have to connect to the right domain name.

The certificates are directed by synology, and for the duckDNS site, i am pointing the DuckDNS certs.

Am i supposed to be endeavouring to connect via https://myduck.duckdns.org (gives an error) or http://myduck.duckdns.org (attaches to HA?)

Ive never used reverse proxy before and assumed it should be https

should i be heading to my site via https or http?
https gives errors,
http attaches, and connects, but obviously not in a secure manner.
Confused!!

If you want it secure you should be using https. Ignore using http remotely altogether

this is where my issue occurs, as soon as i go to https i get HA errors on http

my App portal reverse proxy is as follows

Source:
    protocol HTTPS
    Hostname: MyDuck.duckdns.org
    Port: 4443
Enable HSTS is checked
Destination:
    protocol: HTTP
    hostname: localhost
    Port: 8123
Websockets have been added through custom header, create WebSockets

ive also tried with HSTS unchecked

my http section in HA is

http:
  api_password: mypassword
  base_url: myduck.duckdns.org

my duckdns certificates in synology are pointed at the reverse proxy. Ive used a cert checker, and they point to my duckdns address, so should be good.

Have you followed these instructions?

All followed. As i am a later iteration of DSM(up to date) i only follow the initial part including websockets. The lower half of the page i believe is for earlier DSM versions.

Are you sure about that? You need those options in your config for the reverse proxy…

from the page it states

It’s not necessary anymore to change the template anymore since Version DSM 6.2.1. Changing the Portal.mustache is not recommended! You should use the following part only if you’re using a Version before DSM 6.2.1. on your Synology.

from that point on, as my DSM version is > 6.2.1 i have not added the options…

I will look at the files to see if the options have been added automatically

i checked my files and found the exisitng files held the required upgrade test etc. file reads:

server {
    listen 4443 ssl;
    listen [::]:4443 ssl;

    server_name myDuck.duckdns.org;

    ssl_certificate /usr/syno/etc/certificate/ReverseProxy/966ba-47e2-9904-c783ec144b89/fullchain.pem;

    ssl_certificate_key /usr/syno/etc/certificate/ReverseProxy/966ba-47e2-9904-c783ec144b89/privkey.pem;

    location / {

        proxy_connect_timeout 60;

        proxy_read_timeout 60;

        proxy_send_timeout 60;

        proxy_intercept_errors on;

        proxy_http_version 1.1;

        proxy_set_header        Upgrade            $http_upgrade;

        proxy_set_header        Connection            $connection_upgrade;

        proxy_set_header        Host            $http_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_pass http://localhost:8123;

    }

    error_page 403 404 500 502 503 504 @error_page;

    location @error_page {
        root /usr/syno/share/nginx;
        rewrite (.*) /error.html break;
        allow all;
    }

}

What i didnt have was the second copy called http.HomeAssistant.conf located in the second location. I copied the file acrooss, and restarted NGINX.

No change in issue :frowning:

Thanks for the help so far

I spent a lot of time trying to get the reverse proxy working on my DS218+ and gave up and went with NGINX in docker - haven’t looked back. I also have a certbot docker container which renews my lets encrypt certs every 30 days which has a shared durectory with my NGINX container.

would you be able to let me know exactly which docker containers you used, and examples of how it is set up?

one thing i hadn’t tried was setting up so my external port was 443 (port redirects were in use for my pi HA)
Ive set up the built in Reverse proxy with port 443, having redirected my router port forwarding, and it goes straight in. I thought the reverse proxy would have dealt with this?? and HA would have just seen the access over https?

It will, but I am guessing your built in reverse proxy wasn’t listening on 4443?

HA doesn’t know anything about the SSL, and it doesn’t care. It is seeing a connection come from the reverse proxy as http and is happy to serve it to the connection, which in turn gets SSL’d on the proxy back to you.

How would i force the HA to listen on an alternate port?

Thanks for your time.

You don’t need to.

8123 is just fine to use. For what reason do you feel the need to?

its purely as whilst i was configuring the changeover, i wanted my router to point 443 elsewhere, so i port forwarded 4443 at the router to 443 at the NAS…
writing that out basically says the NAS was seeing it at port 443, and i should have set up reverse proxy to look at 443…Have I spent weeks being a doughnut??

i also meant earlier force the reverse proxy , not force the HA

If you set your forward to be 4443 on external to 443 on internal (Synology), then it should just work. But see, your Synology is set to listen to 4443 according to your settings. Set the Synology to listen on 443, the SOURCE section.

1 Like

All working, i was setting the reverse proxy to the external port, not the port forwarded internal port!

Many thanks!!