http to https redirect

[Shoop]

Will try it, just one question: is it just one file for all the apps?

My example is for one specific app but to redirect every thing coming on port 80 no matter what fqdn was targeted, the configuration below should be ok as it would redirect all HTTP traffic to HTTPS (haven't tried though)

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}

 

[Shoop]

Will try it, just one question: is it just one file for all the apps?

Not sure if I really replied to your question so here is a more precise reply.
If I had more applications with more than one domain or subdomain, I would opt for 1 file per domain or subdomain I think so the content of /etc/nginx/sites-enabled would contain :
- synowstransfer.conf (which seems to be syno default conf)
- subdom1_redirect.conf
- subdom2_redirect.conf
- subdom3_redirect.conf
... and so on

 

[jphermans]

When I do "nginx -s reload" i get following warn no error.

nginx: [warn] conflicting server name "nas.mysite.com" on 0.0.0.0:443, ignored
nginx: [warn] conflicting server name "heimdall.mysite.com" on 0.0.0.0:443, ignored
nginx: [warn] conflicting server name "nas.mysite.com" on [::]:443, ignored
nginx: [warn] conflicting server name "heimdall.mysite.com" on [::]:443, ignored

Already configured 2 sites.

 

[Shoop]

Short update regarding the hosts and containers not able to communicate together with the set IP in the macvlan.
While searching the internets for some other way to set the iprange other than IP/Mask to have a more ganular control of the possible IPs in a macvlan, I stumbled on this tutorial on how to configure macvlans and it seems to cover the whole process including allowing the host and containers to communicate with the macvlan IPs.
Saddly, it looks like the only way to set the iprange is IP/Mask.

 

[otravers]

Rusty submitted a new resource:

http to https redirect - A short tutorial on http to https redirect

Thanks for another idiot-proof tutorial! Is there a way to tweak it to handle all subdomains with a single http rule in the reverse proxy? I tried a wildcard in the hostname but that gets rejected. I have a bunch of containers each with their subdomain and would rather not create two rules by subdomain if I can avoid it.

 

[Rusty]

Thanks for another idiot-proof tutorial! Is there a way to tweak it to handle all subdomains with a single http rule in the reverse proxy? I tried a wildcard in the hostname but that gets rejected. I have a bunch of containers each with their subdomain and would rather not create two rules by subdomain if I can avoid it.

I hear you, but I have tested a few solutions and never got a working one that would cover all the settings/RP settings. So ended up settling with one per record. Haven't looked back after that.

 

[otravers]

Related question: is there a way to redirect requests with the ipaddress: port syntax to their respective subdomain.domain.tld URLs? Reverse proxy rules don't accept IP addresses as the host name (I guess by design).

 

[Rusty]

Related question: is there a way to redirect requests with the ipaddress: port syntax to their respective subdomain.domain.tld URLs? Reverse proxy rules don't accept IP addresses as the host name (I guess by design).

Use web station virtual host feature. This is a classic web binding feature

 

[otravers]

I'm not sure I can do this from the web station GUI, and when I tried to add my own httpd-vhost-user.conf file to /usr/local/etc/apache24/sites-enabled, Apache refused to restart even though my file had a valid format (and I couldn't see anything relevant in the error log). You don't happen to have a tutorial around for this, do you?

 

[Rusty]

I'm not sure I can do this from the web station GUI, and when I tried to add my own httpd-vhost-user.conf file to /usr/local/etc/apache24/sites-enabled, Apache refused to restart even though my file had a valid format (and I couldn't see anything relevant in the error log). You don't happen to have a tutorial around for this, do you?

Is the ip in question here your nas ip or some other one on the network?

 

[otravers]

Is the ip in question here your nas ip or some other one on the network?

The IP is the NAS IP. I don't want services to work from the IP, I want to force a redirect to their FQDNs which will in turn enforce any access control profiles I might have set in the reverse proxy.

 

[Rusty]

The IP is the NAS IP. I don't want services to work from the IP, I want to force a redirect to their FQDNs which will in turn enforce any access control profiles I might have set in the reverse proxy.

Then use the virtual host option to bind the app and it’s root folder to a specific http or https port. After that use your nas ip and that custom port in the reverse proxy entry and map it to a custom subdomain name.

 

[otravers]

Sorry I feel very stupid but I can't figure it out. When I try to create a named-based virtual host, it tells me the port is already used, which I guess it's picking up from the Docker container of the destination app.

 

[Rusty]

Sorry I feel very stupid but I can't figure it out. When I try to create a named-based virtual host, it tells me the port is already used, which I guess it's picking up from the Docker container of the destination app.

Don't worry about it.

So the idea is this. You want to get to your subdomain.domain.com location that will present some content right?

That content is placed on your NAS, so the idea is to host that content using WebStation on a custom, non-used port of your choice. It doesn't matter what port it is internally (on your NAS). That port will be used with your reverse proxy that will eventually push that content back on 443/https.

So it would like like this:

Internet request > subdomain.domain.com:443 (this is your reverse responding) > virtualhost on NASIPaddress:customport

To make this work, create a virtual host that will point to your content on your NAS and simply apply it a custom port:

As you can see on this image, you can apply a custom HTTP (or HTTPS if you want, but no need if you will push it via reverse later on), and select the document root of your app (this web/web_images is just an example).

Now that you have your app fixed on a custom port, this app is accessible on http://nasipaddress:2335.

The next and final step is to create a reverse proxy for this. So create a RP entry like this:

So as a result you have a subdomain.domain.com URL pointing to your NAS:customport location.

 

[otravers]

As always, I really appreciate your help. In this instance I think I explained poorly what I'm trying to accomplish. I have various apps already set up as docker containers (via Portainer most of the time) and they already have their reverse proxy rules. What I want to do is to force the redirect of http://nasip: port to http://sub.domain.tld, i.e. I don't want Calibre-Web, Plex, Organizr etc. to be accessible by IP address but only by FQDN.

 

[Rusty]

As always, I really appreciate your help. In this instance I think I explained poorly what I'm trying to accomplish. I have various apps already set up as docker containers (via Portainer most of the time) and they already have their reverse proxy rules. What I want to do is to force the redirect of http://nasip: port to http://sub.domain.tld, i.e. I don't want Calibre-Web, Plex, Organizr etc. to be accessible by IP address but only by FQDN.

Aha.

Then you will need to edit (backup 1st) nginx.conf file on your nas and add redirect rules to it. Or add those rules to htaccess file.

It is similar to the process of pure http to https redirect like this

HTTP to HTTPS redirect

http to https redirect nas dsm synology revers proxy docker virtual host web

www.blackvoid.club

 

[otravers]

Thank you, I'm pursuing the nginx route. Still struggling but I posted a follow up in a more relevant thread.

 

[mkulik]

Thank you, thank you, thank you!!! Scrubbed whole Internet looking for a way to redirect http websites for services on my synology such as emby or bitwarden - your is the only one that actually work. Great tutorial

 

[Bengt]

Rusty submitted a new resource:

http to https redirect - A short tutorial on http to https redirect



Read more about this resource...

Yes but we need to do it without any .htaccess files. We need to get the apache config right.
The use of .htaccess files is a major performance issue. This is the main reason why many peoples still believes that nginx (where .htaccess is not available) is faster than apache (where it’s optional).
I wish someone could explain how to do this with only apache configuration on the Synology.
I know how to do it in a normal Linux distribution, like Fedora, but Synology seems to have made some unique decisions.

 

[BobW]

Yes but we need to do it without any .htaccess files. We need to get the apache config right.
The use of .htaccess files is a major performance issue. This is the main reason why many peoples still believes that nginx (where .htaccess is not available) is faster than apache (where it’s optional).
I wish someone could explain how to do this with only apache configuration on the Synology.
I know how to do it in a normal Linux distribution, like Fedora, but Synology seems to have made some unique decisions.

I don’t know what you need exactly but have you considered reverse proxy?