it should be
The right part of the port mapping should not change.
What @CutieePie meant that perhaps router is unable to forward port range correctly. But I do not think this is the case, since your Windows storagenode working normally with UDP.
What you actually can do is to try to select TCP/UDP in the Protocol parameter instead of just TCP here
Save the change and try to restart the STORJ_01.
Hi Alexey,
I have there TCP/UDP before…just forgot set it back when I tried something but no change at all anyway.
And yes “STORJ_07: -p 28974:28967/tcp -p 28974:28967/udp” works before and works now (without QUIC) because when I tried change it I was offline completely.
I am going to try remove all docker containers, remove all FW rules on router (related to NAS 10.0.0.200). Reboot NAS and router. Then try add only one FW rule TCP/UDP 28967-28967 and only one STORJ_1 docker container. See what will be the result.
Wigo
I have a feeling that this DSM update broke something related to UDP and how docker is working with it.
Is it possible to revert the update without losing everything?
For good measure, you might also want to uninstall docker, then reboot the NAS and reinstall docker. Trying one at a time seems like a good debugging step after that.
I have to check if this is possible but I am afraid that rollback will not be possible.
Only one container and one simple rule does not work either:
Hi BrightSilence,
I am going to reinstall also Docker itself before re-add storagenode containers.
Thanks for this idea 
Wigo
Reinstall of Docker did not helped neither. Configuration backup I have after latest DSM SYNOLOGY system update so not possible rollback.
I have opened ticket with SYNOLOGY support so let see.
Thank you
Wigo
Hello all,
Just small update from Synology. Seems like issue has been FW to Product Group.
Let me know if anything in your mind regarding this issue or if someone else facing the similar problem.
Thank you
As there is not any relevant information from Synology developers I will plan buy new router (not only because this issue) and let see if this QUIC issue will be fixed somehow 
Hi LordWigo,
just out of interest … what happens if you give a container the following parameters at the start command:
--net=bridge
This should cause Docker to start the container in bridge mode instead of NAT mode.
This should result in this container then being assigned an IP in the 10.0.0.X range by your router.
Then set rules on the router, which forward your desired ports TCP and UDP to the IP of your Docker container (10.0.0.X) on port 28967.
best regards
Vossi
Hi Vosi,
I have recreate one of nodes with this parameter but looks like this is by default because when I checked other nodes all are running in bride mode:
Maybe I should try run with --net=nat instead?
Wigo
Hi LordWigo,
sorry i am writing so late.
As I understand it, your network looks like this:
Internet → Router → Net 10.0.0.0/24
If your docker container is now running in NAT mode, docker will assign it an IP … in your case apparently from the network 172.17.0.0/24.
Like your router, Docker then has to forward the IP packets to the correct container IP. Therefore you have to specify the NAT rule for forwarding at docker in the port settings.
If your container were to run in bridge mode, it would have to be assigned an IP from the network 10.0.0.0/24 by your internet router. Then you would create a port rule on your internet router that would forward the appropriate ports to the appropriate 10.0.0.X IP your container was given.
At least that is the typical behavior of hypervisors such as VMware, Hyper-V, Virtualbox, etc.
I think Docker behaves the same way.
Perhaps docker is bothered by the port settings and is therefore still doing NAT, because rules are configured, but unfortunately I can’t make a 100% statement on this, since I haven’t dealt with Docker too much myself.
I found an article in the docker forum:
Connect container without NAT
Seems –net=host is the solution
I continue read the article.
Doesn’t seem right. Since it would then use the IP from your NAS and would not get its own from your router with dhcp. 
best regards
Vossi
Docker is not VM. The docker container will not get an IP from your router if you select a bridge network (this will be still NAT). With --net=host the container will be exposed to the host as a regular service, so all ports will be mapped to the host.
The router should forward ports for TCP and UDP to IP of the host in both cases.
I have tried increase this value but also did not help:
xxxxxxxxx@SYNOLOGY:/$ sysctl net.core.rmem_max
net.core.rmem_max = 2500000
This is what I have received as final answer from SYNOLOGY support:
Dear Customer,
Thank you for the patience in waiting.
From my discursion with the developers, I am sorry, there is little we can do about the situation. I was informed that, the Synology does not officially (currently) supports QUIC. Docker being an open source package, I have checked through the documentation without being able to find any information relating to the Network settings.
I will suggest that you contact Storj for more information on why the issue occurred and how to prevent such in future.
Do not hesitate to contact me, if you have any further questions.
Best Regards,
O. Medahunsi
Technical Support Engineer
QUIC is just traffic over UDP… seems like a super cop out answer of them. Are you able to open UDP ports at all to your Synology after the update?
Hi BrightSilenc,
Well I have nothing change before/after update. Well I have tried recreated port forwarding rules, even change router. But do not know what else to do on SYNOLOGY because on Win10 machines behind the same router QUIC works properly. This mean that main issue is Docker itself. I have VM Win10 on the same SYNOLOGY running and there is no issue with QUIC as well so I believe on the router side everything is set properly.
Firewall on SYNOLOGY is disabled. There is no too much what can be set under Docker with network.
Typical Synology. Their “opensource package not our problem” copout is not even valid, as they do modify those packages and do introduce issues. Not saying this is the case here but it happened in the past. Before they became too popular they had email support straight to engineering and those folks were brilliant at solving problems. Now the support is pretty useless, making the Synology appliances useless. If users wanted to support them - they would buy something else. /rant.
I skimmed thought the whole thread, I did not see how are you configuring network for running containers, in host mode (not recommended) or with a separate network stack (recommended); in the latter case the MAC address will be different.
Few things that you may or may not have tried
Hi Arrogantrabbit,
I will need maybe littlbe bit help locate where those settings looking for.
Docker network looks like:
As you can see I am in Bridge mode. As I mentioned in thread this worked without issue before DSM update. Router does not filter based on MAC. I have opened ports based on IP address…all docker containers are behind the same IP just changed port for each both TCP and UDP and all are online so from point of router looks all good.
This is how container is configured:
Where can I find geo restriction settings on DSM?
How can I easy check access port on the container from other local machine?
Firewall start/stop - tested.
Where to turn off anti-ddos on SYNOLOGY?
As I wrote VM Win10 machine running on the same SYNOLOGY worked without QUIC issue so from network point of view should be all good.
If there would be issue with port whole node became offline am I right?
Thank you very much for you effort
Wigo
On Virtual DSM Version: 6.2.4-25556 Update 6
Docker 20.10.3-0554 is available there
Is it worth trying…?
