DSM 7.0 Docker with Traefik reverse proxy under Synology DSM 7 // free port 80 and 443

Currently reading
DSM 7.0 Docker with Traefik reverse proxy under Synology DSM 7 // free port 80 and 443

Hi everyone,
to run docker with the reverse proxy Traefik v2 on a Synology NAS, I need to be able to use port 80 and 443 on the host system. DSM 7 uses its own reverse proxy, nginx, which tries to occupy the ports on its own.
Under DSM 6.2 I could change the port 80 and 443 by using a boot script (change-ports.sh), like described here, so that the ports went free and could be used by docker Traefik reverse proxy.

#! /bin/bash

HTTP_PORT=81
HTTPS_PORT=444

sed -i "s/^\( *listen .*\)80/\1$HTTP_PORT/" /usr/syno/share/nginx/*.mustache
sed -i "s/^\( *listen .*\)443/\1$HTTPS_PORT/" /usr/syno/share/nginx/*.mustache

After upgrading my Synology NAS 918+ to DSM 7, I'm no longer able to "free" port 80 and 443.
Obviously the script doesn't work and Nginx (from DSM) is always blocking the port.

The Question is, how to reach the docker reverse proxy Traefik again, by using port 80/443 under the new OS DSM 7.
On my docker-stack are running a lot of important tool, so I need to finde a way to fix the bug urgently.

Thanks for your help in advance. - Best regads Daniel
 
Hello, thanks for your answers and advice. I'm not an expert on networking stuff and in the past I was glad the connection on port 80/443 worked.
I have informed myself for a few days now and I would like to try to use the LAN2 interface on the DS only for Docker and Traefik, by set up a macvlan network.

I tried to reach Traefik proxy, like @Rusty described, by forwarding Router 443 > DS Port 447 > custom local container port (447) > 443 container port. But it don't work.
I'm using Cloudflare Services, with an A Record and my own domain.
For example, if I enter https://mycontainer.mydomain.com, I can get no connectionen.

I hope to find a solution in the next days. If you can give me any futher help and tips, i would be glad.
 
Traefik 2 working again!

I double-checked all steps again, to reach Traefik proxy, like @Rusty described, by forwarding Router 443 > DS Port 447 > custom local container port (447) > 443 container port. I did a mistake by port forwarding on my router. Now everything works fine again.

Thanks for your help - and best regards.

(PS: How could I set the topik as solved?)
 
Traefik 2 working again!

I double-checked all steps again, to reach Traefik proxy, like @Rusty described, by forwarding Router 443 > DS Port 447 > custom local container port (447) > 443 container port. I did a mistake by port forwarding on my router. Now everything works fine again.

Thanks for your help - and best regards.

(PS: How could I set the topik as solved?)
Well done 😉
 
Traefik 2 working again!

I double-checked all steps again, to reach Traefik proxy, like @Rusty described, by forwarding Router 443 > DS Port 447 > custom local container port (447) > 443 container port. I did a mistake by port forwarding on my router. Now everything works fine again.

Thanks for your help - and best regards.

(PS: How could I set the topik as solved?)
Hey man, I think you may have the answer I’ve been seeking all week. Can I please ask- any chance you can show how you set up the port forward?
I can’t figure out what you mean by 443>447>443.
Did you set up 3 separate rules?
 
Hey man, I think you may have the answer I’ve been seeking all week. Can I please ask- any chance you can show how you set up the port forward?
I can’t figure out what you mean by 443>447>443.
Did you set up 3 separate rules?
Perhaps you already figured this out, but it is basically a bypass of directly using port 443 by using one intermediate port (proxy port if you will). Configuration requires two rules; one for redirecting requests to the intermediate port and one for receiving requests from the intermediate port (rather than the original port).

The first configuration is in your router. You should add a port forwarding / mapping rule that forwards a request on port 443 to port 447 on the NAS IP.

The second configuration is in mapping all requests on NAS port 447 to traefic's port 443 (this is what it listens on in the docker network). This can be done by adding -p 447:443 to the docker run command or by adding 447:443 to the array of ports in the docker compose file.

Hope this helps.
-- post merged: --

Having said all that, I have everything working from outside my LAN but inside my LAN my requests end up at the NAS nginx rather than my traefik container.

@one-eyed-king, @Rusty or anyone else: if you have any thoughts on this I'd be very happy to hear them!
 
IIf you publish the container port 443 on the host port 447 and Forward your routers WAN port 443 to the NAS:447, you can reach the Treafik container using your WAN port 443.

This is without any bypass, proxies or whatever, just a simple portwarding rule in the router to the published host port of Treafik.

Though, you will want to publish Traefik's port 80 as well to a host port and forward WAN port 80 to this port, in order to be able to perform LE http-challenge. Except, if you own a private dns and your dns provider is supported by Treafik's dns-challenge for LE. Then you should definitly prefer the dns-challenge.

Traefik makes most sense if you controll the reverse proxy rules by container labels using docker compose deployments. Without declaring the rules using docker compose's contaienr labels, I don't see much benefit in using it honestly...
 
Except, if you own a private dns and your dns provider is supported by Treafik's dns-challenge for LE. Then you should definitly prefer the dns-challenge.
I have to agree with everything that King said, especially this part. I use it that way specifically.
 
I also completely agree. What I failed to mention in my post is that this is indeed by no means a proxy port / mapping / whatsoever -- it is just that when I started to look into the networking and port mapping stuff, I was a bit dazzled by networks, interfaces and ports and intuitively it first made most sense to me to think of this construct as "I want outside requests on port 80 to reach port 80 on my Docker container, and I need a small bypass to circumvent the request from ending at my NAS port 80 instead." I figured that this (initial) thought might help @Daniel-WW. Your remarks are completely justified and in hindsight I definitely should not have used the term 'proxy' considering its significance in this thread.
NTS: do not write posts just before going to bed.

Now that the port mapping analogy stands corrected, I'd like to get back to the port 80 and 443 issue from within LAN. As described above, I have forwarded WAN 80 and 443 to alternative ports (say 84 and 447) on my NAS. My Traefik container is listening on these host ports and maps them back to 80 and 443 for the Traefik service. All reverse proxy rules are controlled by other services, leveraging docker labels. This setup runs successfully from outside my LAN; e.g. connecting to service1.mydomain.com is correctly routed to Traefik and connects to the container that provides service1. However, requesting the same address from inside my LAN results in a 404 from nginx.

From my limited experience with networking, I hypothesize that the internal requests never leave the premises and particularly do not try to enter my LAN via WAN port 80 but rather have a direct communication with NAS port 80. The port forwarding rules therefore have no effect. Either way, I am hoping to receive help on how I can configure my router / NAS / ... so that I can also connect to service1 via service1.mydomain.com from within my LAN!
 
This setup runs successfully from outside my LAN; e.g. connecting to service1.mydomain.com is correctly routed to Traefik and connects to the container that provides service1. However, requesting the same address from inside my LAN results in a 404 from nginx.
You call https://service1.mydomain.com from outside your lan and and reach the LE-Container.
But when you call https://service1.mydomin.com from inside the land you end up connecting the NAS?

Traefik will use the full qualified domain name to identify to which container the traffic needs to be routed. So just service1 or the ip is insufficient, except you added an additional label for that FQDN and IP as well (though this won't work for https, as the subject name will NOT match the full qualified domain name used by LE for certificates)

It kind of sounds like you are running a dns server (on the NAS/Pihole?) for the hosted zone mydomain.com and resolve the service name service1 in this hosted zone to your NAS. If so, this is a no no, as the portforwarding will only apply when accessed using the WAN port.

Addionaly, as soon as your resolve lan ip's with a dns server accessible by WAN, you need to exclude the DNS-Rebind protection for that domain. Otherwise your router will break the name resolution. Usualy this is not a desired configuration - unless you know why you need it differently (convinence usualy is not the right reason).
 
You call https://service1.mydomain.com from outside your lan and and reach the LE-Container.
But when you call https://service1.mydomin.com from inside the land you end up connecting the NAS?
Correct (assuming that by LE-Container you mean any container that is served on a FQDN with a LE-issued certificate that covers that domain).

Ter info, here is the result of a nslookup command while I am connected to a VPN network (e.g. access outside LAN):
nslookup_with_VPN.png

This is the output when I am not connected via VPN (e.g. access from within LAN):
nslookup_without_VPN.png

Both of them point me to the same (WAN) address, so to my beginner's understanding that seems to be OK.

Traefik will use the full qualified domain name to identify to which container the traffic needs to be routed. So just service1 or the ip is insufficient, except you added an additional label for that FQDN and IP as well (though this won't work for https, as the subject name will NOT match the full qualified domain name used by LE for certificates)
I confirm that I'm entering the FQDN.

It kind of sounds like you are running a dns server (on the NAS/Pihole?) for the hosted zone mydomain.com and resolve the service name service1 in this hosted zone to your NAS. If so, this is a no no, as the portforwarding will only apply when accessed using the WAN port.

Addionaly, as soon as your resolve lan ip's with a dns server accessible by WAN, you need to exclude the DNS-Rebind protection for that domain. Otherwise your router will break the name resolution. Usualy this is not a desired configuration - unless you know why you need it differently (convinence usualy is not the right reason).
As far as I know, I'm not running a local DNS server. I tried setting up Pihole about a year ago, but that didn't please me so I reverted everything immediately after. I'd like to think that the network is not aware of these attempts.
 
Your problem is caused by a split-brain dns.

Since there is no trail about what might cause it: you are pretty much on your own.
Or is this is a special behavior of the synology.me domains? I don't use them, as I have my personalized domains and I am not using synology.me.
 
I'm not familiar with split-brain DNS, but from my brief browsing session it seems to be another problem? The way I interpret split-brain DNS is that a (single) DNS server would resolve to different IP addresses for the same FQDN, depending on the origin (e.g. LAN or WAN) of the request. In my case, both from LAN and from WAN I receive the same address for my domain; the only change was the address of the DNS server (which I think makes sense).

This seems more like 'split-brain port forwarding', then. Anyway, from your replies I deduce that my issue is not as general as I thought and that setting port forwarding rules in the router should have been sufficient configuration, is that correct? (I'd still like some help if possible, though. I appreciate the involvement thus far!)
 
Last edited:
This seems more like 'split-brain port forwarding', then
How would name resolution relate to "conditional port forwarding"?

Anyway, from your replies I deduce that my issue is not as general as I thought and that setting port forwarding rules in the router should have been sufficient configuration, is that correct? (I'd still like some help if possible, though. I appreciate the involvement thus far!)
indeed, it should have been sufficient. Networks-wise the setup is as it should be. I stand by my conclusion: your problem IS caused by dns.

I can't help you with your stituation. It must be something the build-in dns server of your "router" does or something caused by the authoratite dns server that manages the synology.me hosted zone.
 
Last edited:
Well I got my problem resolved, although the exact issue and solution remain a mystery. Even though my issue was not quite related to this topic (I initially thought it was!), I will share the 'solution' for those interested.

Basically, I just followed the steps in Synology knowledge base - I cannot connect to my Synology device via DDNS and then undid them. More specifically, I followed preliminary steps 1 (manually set DNS servers of NAS to Google's servers), 2 (turn off ipv6) and 4 (synchronize time), and everything worked as expected. Then I undid step 2 (still working) and step 1 (still working). Regarding step 4, my configuration was already to synchronize with NTP server so in the end the only effective change was to force a time sync. I feel that somewhere in the process some cache or something was flushed / reset, solving the problem.

Anyhow, I am grateful for the help that I received here. Special thanks to @one-eyed-king.
-- post merged: --

I cheered a bit too soon, couple of minutes later it was broken again. But at least I now know it is related to ipv6. Anyhow, I will stop posting on this.
 
Breaking my previous promise, I'll share the solution that has been working for several weeks now. Reason for this is that this particular solution targeted Synology NAS configuration and therefore might be relevant to others in this community.

Issue
Able to connect trough entrypoints from LAN, but unable from WAN. This turned out to be related to IPv6.

Solution
Change the IPv6 setting of your NAS network interface. I guessed the English terminology in DSM UI, but it can't be off too far:
  1. In DSM, open the configuration panel.
  2. Go to Network -> Network interface and select your (default) profile.
  3. Edit the network and visit the IPv6 tab.
  4. Change Install IPv6 from auto to DHCPv6-PD and save your settings.
Cheers!
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

I can’t find any option to restore just the settings. 1710356648 Phew, managed to fix it. Within the...
Replies
4
Views
390
Good to hear. Deluge has not been updated for almost two years now as an app, nevertheless. But it gives...
Replies
12
Views
960
  • Question
Open an issue on that GitHub page. The developers will be glad to assist. OP has posted two threads on...
Replies
5
Views
963
I'm happy with email notifications but in v0.3.3 of dockcheck the author added apprise notifications...
Replies
4
Views
1,041
I am also trying to setup a Z-wave USB dongle and am getting stuck after following the same steps as...
Replies
1
Views
1,030
How did you create the Portainer container in first place? As in exact docker run commands or in case...
Replies
7
Views
1,240
Looks like I triggered you somehow with my post: it was not my intention. I have no idea whether bash or...
Replies
4
Views
1,534

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top