Today we are going to look at how to set up Nginx Proxy Manager on a Synology NAS.
If you’re exposing any services on your network, using a reverse proxy is a great way to increase security and performance. A reverse proxy is a server that sits in front of your web servers and forwards client requests to the web servers. In layman’s terms, you only have to expose one server (using ports 80/443) and will be able to expose as many web services as you want.
This is an example of the network flow of a reverse proxy (simplified):
Please keep in mind that this is an alternative to Synology’s Application Portal where you can set up a Reverse Proxy. If your intentions are to only create a reverse proxy, you might want to use that instead, as there is no configuration necessary (other than the reverse proxy settings)!
1. Setup Instructions – Nginx Proxy Manager Synology NAS
This tutorial will utilize a Synology NAS and Docker. Since Nginx Proxy Manager uses a database, we will need to install two different containers. One for our database and one for Nginx Proxy Manager. By default, Synology uses ports 80 and 443 so using our host network interface isn’t ideal. For this reason, we will create a macvlan network interface (in Docker) that will allow us to bypass this port conflict.
1. Install Docker from Synology’s Package Center.
2. We need to create a few folders that we will be mapping our Docker containers. By default, the Docker package will create a folder named docker after it’s finished installing. Inside of this folder, we are going to create a folder named mariadb and nginx-proxy.
3. Inside of the nginx-proxy folder, create two sub-folders named data and letsencrypt.
4. Create and upload a file named config.json to the nginx-proxy folder. This file must contain the contents below. Ensure that you change SYNOLOGY_NAS_IP to the IP Address of your Synology NAS!
{
"database": {
"engine": "mysql",
"host": "SYNOLOGY_NAS_IP",
"name": "nginxproxymanager",
"user": "nginxproxymanager",
"password": "nginxproxymanager",
"port": 3306
}
}
5. The folder setup is complete!
1.1 Macvlan & Bridge Docker Network Interface Setup
1. Ensure you can SSH into your Synology NAS. Open Control Panel, select Terminal & SNMP, and Enable SSH service. If you are using Synology’s Firewall, ensure that you allow port 22 traffic. I created a video on how to SSH into your Synology NAS if you have any problems.
2. SSH into your Synology NAS using your favorite SSH tool.
3. We need to create a Docker macvlan network interface. First, we need to determine what network interfaces currently exist (on your Synology NAS) and note down the adapter name. To do this, run the command below and note down the network interface name that has your Synology NAS’s IP address (in this example, mine is eth0).
ifconfig
4. Next, you need to run the command below while substituting the correct subnet (most are 192.168.1.0/24 or 192.168.0.0/24 by default). You also need to pick an IP address that you’d like to use that’s not currently in use. I will be using 192.168.1.198. NOTE: npm_network will be the name of the network (you can substitute this as you’d like).
sudo docker network create -d macvlan -o parent=eth0 --subnet=192.168.1.0/24 --gateway=192.168.1.1 --ip-range=192.168.1.198/32 npm_network
5. Our network is now created. We can now exit our SSH session and disable it in DSM (if you won’t be using it). If you are disabling it and created a firewall rule for it, you should inactivate the firewall rule as well.
6. Next, we need to create a bridge network. This is what will allow our host (NAS) to communicate with our Nginx Proxy Manager container. Open Docker and navigate to the Network section. Select Add and enter a subnet that’s not currently in use. The IP address of the bridge I am creating will be 192.168.10.2.
7. Both network interfaces have now been set up!
1.2 MariaDB Install and Configuration
Nginx Proxy Manager requires a database to be set up in order for it to work properly. While Synology offers a MariaDB package, I like to separate it out by creating a second Docker container for the database only.
1. Open Docker, navigate to the Registry, and search for MariaDB. Download the latest version of MariaDB.
2. After the image has finished downloading, navigate to the Image section, and double click mariadb to set up a new container.
3. Give the container a name and then select Advanced Settings.
4. Select Enable auto-restart.
5. In the Volume section, select Add Folder and then select the mariadb folder we created earlier. In the Mount Path section, type /var/lib/mysql.
6. In the Port Settings section, change the Local Port to 3306. NOTE: If you have to use something other than 3306 as the port, you need to update the config.json file we created earlier.
7. In the Environment section, we need to create four variables. These variables are what will store our root password, database name, username, and password. NOTE: if you don’t want to use the values below (nginxproxymanager), you can change this to whatever you’d like. Just ensure that you update the config.json file that we created earlier with the new information.
8. Select Apply and create the container. The database has now been created!
1.3 Firewall Setup – Nginx Proxy Manager Synology NAS
Since we are using a macvlan network interface, there are no firewall rules that we need to set up for Nginx Proxy Manager. However, the MariaDB container is using the host network interface and for that reason, needs a firewall rule to allow traffic. If you haven’t set up Synology’s firewall, I created a tutorial on how you can do it (and suggest that you do).
1. Open the Control Panel, select Security, then Firewall. Select Edit Rules and add an allow rule for port 3306. NOTE: If you are using a different port in the config.json file that we created above, you will need to use that port instead of 3306.
1.4 Nginx Proxy Manager Container Setup – Synology NAS
1. Open Docker, navigate to the Registry, and search for nginx-proxy-manager. Download the latest version of jc21/nginx-proxy-manager.
2. After the image has finished downloading, navigate to the Image section and double click jc21/nginx-proxy-manager to set up a new container.
3. Give the container a name and select Advanced Settings.
4. Select Enable auto-restart.
5. In the Volume section, we need to create two folder mappings and one file mapping. Select Add Folder and add the data folder and add the mount path /data. Next, select the letsencrypt folder and add the mount path /etc/letsencrypt. Select Add File and select the config.json file we created earlier with the mount path /app/config/production.json.
6. Under Network, add the npm_network and npm_bridge networks and remove bridge.
7. Match the Port Settings to be like the image below. If you are using 4443, 8080, or 8081 for anything, you can change the ports to something not currently being used.
8. Select Apply and create the container! Give the container a few minutes and you should be able to access the web admin portal through the npm_network IP address and port 81!
http://[npm_network]:81
2. Nginx Proxy Manager Setup – Synology NAS
1. Login with the email address [email protected] and password changeme.
2. When prompted, change your name and email address, then set up your password.
3. Nginx Proxy Manager is now set up! Ensure that you port forward ports 80 and 443 on your router to the macvlan network we created above.
BAD GATEWAY ERROR
Certain people are experiencing “bad gateway” errors when they try and login . After troubleshooting this for a while (and a few helpful suggestions in the comments), there are really two ways to fix this:
1. If your NAS has multiple NIC’s and you have multiple IP addresses assigned to it, in the “config.json” file, enter the other IP address of your NAS.
2. Keep the default docker bridge network interface connected to both containers and use that IP address in the config.json file.
3. Using Nginx Proxy Manager
Now that we set up Nginx Proxy Manager, it’s important to know how to use it! I created a tutorial that you can follow that will show you how to expose Plex and setup an SSL certificate. The tutorial is fairly straight forward, but highlights how you can expose practically any web server quickly, easily, and securely!
4. Conclusion
This was a fairly complex tutorial, but I am hoping that it’s broken down enough to be easily understood. It’s not normal that you need to set up two different Docker containers to get one container to work, but in my opinion, this is the best way to get Nginx Proxy Manager working on a Synology NAS.
Thank you for reading the tutorial. If you have any questions, please leave them in the comments!
[10/19/2020] [10:28:49 AM] [Global ] › ✖ error connect EHOSTUNREACH 192.168.1.2:3306
When i try to log in to proxy mangager i get ”bad gateway”
Can you help me
This error states that Nginx Proxy Manager cannot access the database. A few things to check:
1. Is the database container running and did you properly specify the username/password when you set it up (you can check the screenshots of how it should look)?
2. If you are using Synology’s firewall, did you create an “allow” rule for 3306 on your NAS?
Let me know how it goes and we can continue troubleshooting!
I have this same problem as Peter does. I do not use the firewall.
There are a few small things which are unclear to me:
– does the docker container for MariaDB need to run on the same macvlan network? I can imagine this is why the NPM container cant connect to the MariaDB one. Btw i had to change the DB port to another port, so I did this in the config and in the docker container. (only the local one, not the docker port)
– which password needs to be in the config? The Root password or the other one?
Thanks for checking out the tutorial! A few notes:
1. The MariaDB container should NOT be run on the same macvlan network. That macvlan network is only for the Nginx Proxy Manager container.
2. If you changed the database port (from 3306), you need to ensure that you set it up in the MariaDB container and the config file. If you’re using Synology’s firewall, you need to create an “Allow” rule for that port as well. You are correct that it should only be done on the local port, not the container port.
3. The config file should have the username/password (not the root password). Honestly though, it’s probably easier to just keep them all the same since this container won’t be used for anything other than NPM.
Hopefully this helps, but if you have any other issues, please let me know!
Dumb question, but which of these ports needs to be set up for port forwarding on the router? Is it 443:443 and 80:80 or 443:4443 and 80:8080?
Never a dumb question! Just 443/80 to the macvlan network IP address. The other ports are just mapping container ports to local ports on the NAS.
If you have any other questions, please let me know!
So in the container’s port settings, is the “host” port the app’s internally used port, and the “container” port the one that is used to access the front end–or the other way around?
The “Local Port” is the host (NAS’s) port and the “Container Port” is the containers ports. Ironically, if you’re using a macvlan network, the “Container Port” is actually the port that you use to connect (192.168.1.198:81 in the tutorial).
Hopefully this makes sense, but if you have any further questions, please let me know!
That’s what threw me off. So even with the macvlan driver, a port is still used on the NAS network interface? Does this mean that firewall rules opening those ports to the NAS IP are still required (router/firewall and NAS software firewall) or does this approach only require firewall rules and port forwarding for the container’s IP and ports?
As I understand it, the host needs to have ports assigned because the macvlan network interface is a virtual network interface (behind the host’s physical network interface). So basically, even though we are accessing a virtual network interface (macvlan) with its own port configuration, it’s still running through the hosts network interface, so it needs to be mapped to an open port on the host.
You should NOT have to create any host (NAS) firewall rules. You ask a really great question though and it made me double check to see if I had any rules allowing traffic that I wasn’t aware of, but I don’t. You have the right train of thought, though, and I need to do some further research to tell you exactly why you don’t need to open the containers port. For now, my best assumption is that the NIC is capable of handling everything on its own.
Seriously great question that will certainly teach me something. Let me know if you have any other questions!
hi Wunder Tech,
Thanks for the tutorial! But unfortunately I’ve got the same error as Peter and Leon, when trying to login I’ve got the “bad gateway” error.
mariaDB is running, I’ve followed the tutorial 3 time already and still the same issue. On the log I’ve got this message though “error connect EHOSTUNREACH local_nas_ip_address:3306.
Again port 3306 is allowed on sync firewall and I’ve followed everything on the tutorial. Any thought?
Thanks for your help
Thanks for checking out the tutorial! Unfortunately, a lot of people ran into this issue and from what I’m finding, it’s due to the NAS model that they’re using. More specifically, the NIC that the NAS has which may or may not have specific features needed to get this to work. I haven’t updated the tutorial yet because I’m not clear on what NIC is required, but I can tell you that it works on a DS1019+. What NAS model are you using?
I’m using ds218+ . Tried to look on forums but no luck so far 🙁
My assumption is that’s what it is, sadly. Have you considered using Synology’s built-in reverse proxy? If you’re interested in using that, I have a video coming out for that tomorrow on YouTube!
I will do a little further research to see if I can figure anything out. If I can answer any other questions, please let me know!
I am using a DS918+ and I am also unable to get this to work. Do I need to setup the DNS? I did not see a need for a DNS when I set up the Synology NAS since my unifi network is handling the Ip addresses.
You would need to set up some form of DDNS (unless you have a static external IP address), but you would only use this if you plan on exposing services outside of your network. Alternatively, Synology offers a reverse proxy server as well!
Following these directions, mariadb keeps restarting with error:
2020-11-16 4:18:15 0 [Warning] Can’t create test file /var/lib/mysql/mariadb.lower-test
/usr/sbin/mysqld: Can’t change dir to ‘/var/lib/mysql/’ (Errcode: 13 “Permission denied”)
I’m not sure where I might have gone wrong. I even deleted it and redid everything and it still seems to have the exact same issue. Any help for this noob would be appreciated.
I know people have had issues connecting but I haven’t seen that error in specific. If you allow the Docker container to run with high privilege, does it still happen?
Let me know and we can continue troubleshooting!
Yes, even with high privilege it does the same thing.
Is that error the only error in the log? Is there anything else in the log that might point us in the right direction?
I googled the error message and have been trying to find information on what it could be, but there is very little helpful info. I’m hoping that there’s a different error message that we might be able to use to get additional information.
Any solution to the bad gateway error on a DS1621+ yet? Getting it…sucks…
I’m surprised the DS1621+ has the issue. I expected that to be one of the ones that works as it tends to be a little more premium than the others.
Are you receiving ANY errors in the Docker logs? Anything that can point us towards what it could be? From what I’ve found, it appears to be NIC related which makes it a very difficult issue to resolve (if it’s not something easy like the firewall). Let me know!
Following your good tutorial, I was able to setup everything as suggested by you. However, only when trying to connect to nginx-proxy-manager (IP 192.168.2.198:81 in my case) I receive the message “unable to connect”. I checked firewall on NAS and enabled port 3308 – as I use that port – and set port forwarding on my router for 80 and 443 for IP 192.168.2.198. I tried with firefox and chrome browser, cleared cache, but all these measures did not help.
You did not mention to forward port 81 also to container IP? Is this required? I tried with and without forwarding, however, nothing worked.
Any suggestion from your side what to do?
No, you should not be forwarding port 81. Have you created a firewall rule for port 81 on your Synology NAS? That seemed to be needed for others. If that doesn’t work, can you try disabling your Synology NAS firewall and seeing if it works? Definitely don’t keep it disabled, but just to temporarily test. If it works, then it’s a firewall rule or lack of firewall allow rule that’s causing the problem.
Let me know and we can continue troubleshooting!
I am very thankful that someone is taking a lot of time to make tutorials for those out of the loop…
Here is a screenshot with probably not very helpful information…
https://imgur.com/a/EPTv53l
I tried to go through this with as little variables as possible – the only thing I changed was the npm_network ip to 202 instead of 198.
I am not getting specific bad gateway errors like the others but merely a connection timeout.
The ‘substituting the correct subnet’ part really confused me as I don’t really understand how you would ‘find’ the correct subnet – so I just put in “192.168.1.0/24” hoping it was correct.
Hopefully, this is just a very simple noob mistake but would greatly appreciate any advice on how to get this working. Please let me know if you need any more detail on logs, screenshots, etc.
– Jay
Thanks for providing all of this info and for the kind words!
Can you please try and disable the firewall (temporarily) and check to see if it works? If it does, we have a firewall issue. For some people, it seems like allowing traffic on port 81 on the NAS is necessary. This is NOT the case for me, but to be honest, I haven’t had any of the bad gateway issues either so I am not the best example.
Please let me know if it works and if not, we can continue troubleshooting!
I tried with and without firewall rule for port 81 on my NAS and disabled firewall completely, however, everything without success. I can ping 192.168.2.198 from terminal. In my router I set internal and external port on 80/80 respectively 443/443; hope that is correct?
Thxs for trying to help me.
Are you trying to access the website using port 81? If your IP address is 192.168.1.198, you should navigate to the NPM webpage using http://192.168.1.198:81.
Let me know and we can continue troubleshooting!
Of course, I used http://192.168.2.198:81
Are you using the 192.168.2 subnet by default for all local devices? I apologize for the basic questions, I just haven’t seen this error before. If the firewall is disabled and you’re unable to get to the site, are there any errors in specific in the Docker logs?
Yes, I use the 192.168.2 subnet for all my local devices in the LAN. The docker logs are ok; Nginx-Proxy-Server is running. I observed the following: when entering http://192.168.2.198 without the port :81, the website “Welcome to nginx!” opened: “If you see this page, the nginx web server is successfully installed and working. Further configuration is required.”
Also, on the NAS under firewall settings the nginx-proxy-server is now listed as an internal application with the ports 4443, 8080 and 8081. I enabled the settings but still can’t access the IP 192.168.2.198:81.
The proxy server is up and running and I can access my DSM under my domain with http and https.
Something seems to be slightly off. When I do what you said (access 192.168.1.198 without port 81), I get this: “Congratulations! You’ve successfully started the Nginx Proxy Manager”.
If you’re getting that page, it appears like the traffic is somehow being routed back to your NAS rather than the NPM container itself. You said in an earlier comment that the ports now match (8080, 8081, 4443). By any chance, did you initially configure with ports 80/81/443? If so, that could be the problem. You might need to recreate the Nginx Proxy Manager container with the correct port mappings.
Let me know and we can continue troubleshooting!
I deleted everything (container, network and directories in docker) and installed everything from the beginning. Still, I am unable to connect to the site 192.168.2.198:81. I have also two LAN’s on my NAS and tried with eth0 and eth1 as these are the interfaces and also tried different IP addresses for my NAS in config.json. Every time I changed the setup, I deleted everything and made a fresh install, however, without success.
When I now try to ping 192.168.2.198 the response is: “Destination Host Unreachable”.
Sorry, to trouble you, but I am completely lost now :(.
It almost sounds like the macvlan network interface isn’t working properly.
If you SSH into your NAS and run the command “ifconfig”, are you substituting the correct network interface (could be eth0, eth1, ovs_eth0, etc.) into the macvlan network interface creation command? If the container is running and the macvlan network interface is associated with it, at minimum, you should be able to ping it, which makes me think the network interface isn’t working properly.
Let me know and we can continue troubleshooting.
I think the interface setup should be ok; I checked it with portainer and the assigned ports are all shown correctly. Checking the ports of all the other container running in docker, I noticed that one app from home assistant is using port 80. Could this cause the port conflict? Also, what is with the web server on Synology using port 80? I unchecked that one, however, without success. When I ping from my iMac, the following is shown:
root@Herby_DS:~# ping 192.168.2.198
PING 192.168.2.198 (192.168.2.198) 56(84) bytes of data.
From 192.168.2.125 icmp_seq=1 Destination Host Unreachable
From 192.168.2.125 icmp_seq=2 Destination Host Unreachable
It looks like the traffic is redirected to the NAS; don’t understand why?
You aren’t using the same network interface for Home Assistant, right? As long as you’re not, there shouldn’t be any port conflicts.
When you created the container, did you remove the bridge network?
Basically, you should run the “ifconfig” command in terminal. Find the network interface name and add it to the command below:
sudo docker network create -d macvlan -o parent=eth0 –subnet=192.168.2.0/24 –gateway=192.168.2.1 –ip-range=192.168.2.198/32 npm_network
Create the NPM container, add the npm_network and remove the bridge network. The traffic should not be routed back to your NAS, so we need to try and solve that issue first (which is most likely causing it).
Let me know how it goes and we can continue troubleshooting.
I did all the steps as suggested by you. Home Assistant uses different network interfaces than Nginx. When running the ifconfig command, it shows the two interfaces:
eth0 Link encap:Ethernet HWaddr 00:11:32:10:86:96
inet addr:192.168.2.125 Bcast:192.168.2.255 Mask:255.255.255.0
eth1 Link encap:Ethernet HWaddr 00:11:32:10:86:97
inet addr:192.168.2.130 Bcast:192.168.2.255 Mask:255.255.255.0
I created the npm_network command with eth0 and alternatively with eth1 – after deleting everything again -, however, both bring the same result “unable to connect” to 192.168.2.198:81.
Also, correctly shown is the npm_bridge network when running the terminal command ifconfig and there is no conflict to other docker container address ranges or interfaces.
docker-a1 Link encap:Ethernet HWaddr 02:42:65:6A:A1:0B
inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
If the npm_network is configured properly (as it looks like it is), the next thing to check would be the firewall. Do you have Synology’s firewall enabled? If you do, can you temporarily disable the firewall and check to see if the container starts responding?
I am starting to shift my focus to it being some sort of firewall rule blocking it. If it’s not, at least this will rule out the firewall as being the issue.
Let me know how it goes!
Today some other result. Now, after reinstalling everything again and also rebooting the Synology, I am getting the Bad Gateway. I set the port on 8725 and also tried with the second interface eth1, however. still getting Bad Gateway.
In the config.json file, can you try and use the second IP address for your NAS? That has fixed the issue for other people.
Let me know how it goes!
Yes, I tried that already, however, without success.
Unfortunately, it could be NIC related. It sounds like certain people with specific NAS models have problems with this tutorial and it comes down to the NIC that their NAS is using. If you changed the port and tried to use the other IP address and it still doesn’t work, that would be my unfortunate assumption.
Thanks for the reply, I was reading through some comments and here are some things I have tried so far:
1. Running both ‘MariaDB’ and ‘Nginx-Proxy-Manager’ containers using high privilege
2. Trying the connection with “192.168.1.202:81” and “192.168.1.202:8081” in both Firefox and Chrome
3. Adding a custom rule for Port 81 in Synology Firewall and also disabling Firewall
4. Restarting Docker
5. Using the command ‘sudo ping 192.168.1.202′ in PuTTY and getting the result “icmp_seq=23 destination net unreachable”
I am using a DS918+ on “DSM 6.2.3-25426 Update 2” and MARIADB_VERSION 1:10.5.8+maria~focal and NPM_BUILD_vERSION 2.7.1
I also have a Google Wifi with a DHCP reservation set for my NAS’ IP and no port forwarding rules on the router settings.
Something tells me this has to do with my router or that subnet substitution thing that I still don’t understand
I have skimmed other forums, all of which seem to have their own unique, meticulously detailed problems that dig far too much into terminal command line stuff I am not comfortable with
I am mainly just trying to set up a reverse proxy as it seems Google Wifi does not directly support using a VPN and I just wanted to hook up a domain name I bought so others can connect to Jellyfin.
It seems perhaps I am overcomplicating things but seems like it is a necessary evil…
Have you considered using Synology’s built-in reverse proxy? I have a video on how you can set it up here: https://www.youtube.com/watch?v=iWvCN2j7xjo
That’s not to deter you from using NPM, it just might be easier if you’re only using it for Jellyfin. If you are interested in using NPM, a few other questions:
1. I assume that you’re trying to access this from a machine on your local network? Does that machine have any trouble accessing DSM?
2. Is your router set up to use the 192.168.1.X subnet?
Another option would be configuring OpenVPN on your Synology NAS. It runs very well and I have a tutorial up for that if you’re interested. However, it’s probably easier to use a domain name with Jellyfin since you’ll probably want to use it on multiple devices and some of them may not support OpenVPN.
Let me know and we can continue troubleshooting!
I think I finally understand the “correct subnet” part as my IP had “192.168.86.x” and I wasn’t reading closely enough… Google Wifi uses that as part of its default DHCP Pool (?) but once I redid the SSH part, I was able to get to the Nginx login page!
Bad news is that I have the same exact problem as Richy (Peter, Leon) where we get the bad gateway on the login page, followed by “EHOSTUNREACH” error in the log of Nginx Proxy Manager
https://imgur.com/a/TSYsho6
I already have the firewall rule allowed for 3306 and also tried disabling the firewall but still get the same message.
Again, I have a DS918+ so maybe this model also has to be blacklisted for NIC incompatibility?
I’ll try out Synology’s Reverse Proxy solution for now (rly efficient tutorial btw) as I don’t think I’ll need to expose any other services remotely besides Jellyfin at the moment
I figured out why the error is occurring! I have two NIC’s on my NAS with two separate IP addresses assigned to them. When I use the first, I get the “bad gateway” error, but when I use the second, it works. My assumption is that port 3306 is being used for something by default and using the second NIC avoids the port conflict.
So if you have two ethernet cables plugged in to your NAS, in the config.json file, can you please try and change the “SYNOLOGY_NAS_IP” to the other IP address? That is, if you’re interested in using NPM. If you’d rather just use Synology’s reverse proxy server, that’s totally fine too! I really wish I used a different port to begin with because these errors would have never occurred.
If I can answer any other questions, please let me know!
I also have a 918+ and was having all those problems.
I changed the json IP to the second adaptor and it seems to be working now.
Thanks for the time and the great tutorials!
Glad you got it working and thanks for the kind words!
My DS918+ has two ethernet ports but I am only using the ‘LAN 1’ portion. So I am not sure if changing to the ‘other’ IP makes much sense here. Did you mean switch the cable to the other port?
Also, wouldn’t disabling the firewall essentially remove the problem of ports as far as “Bad gateway” is concerned?
Regardless, I have tried updating the config.json to port “3333” and also updating those ports within the MariaDB container. After restarting the containers, I still get the same error (bad gateway) which you can see in the Nginx log of EHOSTUNREACH before even trying to login.
I’m not really sure if MariaDB and its ports are the problem but maybe something with the npm_network when creating the subnet part…?
In part of the command “–subnet=192.168.86.0/24 –gateway=192.168.86.1 –ip-range=192.168.86.198/32”, the default gateway under Network -> General shows Default gateway is “192.168.86.1” which is my Router LAN IP. Does the subnet also need to be 86.1/24 instead of 86.0/24? (apologies as I don’t understand the significance of the /xx part)
There are other forums that talk about editing a Docker Compose file for the db or something but it seemed really confusing honestly (https://github.com/jc21/nginx-proxy-manager/issues/300#issuecomment-704025517)
Sorry if I am making things more complicated but this has been the best source so far for setting up a nas so I can just use jellyfin
When you say you’re only using the “LAN 1” portion, does that mean you only have one ethernet cable plugged in? I was wondering if you’d be able to plug a second one in so that you have two cables plugged in (and two IP addresses). This will allow you to access your NAS on the IP address that you already have set up and on a second IP address. Adding the second IP address to the config.json file is how I was able to resolve the “bad gateway” error.
As far as just changing the port in the Docker configuration for MariaDB, I’m not sure that will work unfortunately. You might have to recreate the entire container if you want to use a new port. I don’t think it’s the macvlan network interface. You appear to have done everything right and have the subnet correct as 192.168.86.0/24.
In summary, you can use a different port (3333 should be fine), but you will have to recreate the MariaDB container to use that port. Then, update the config.json file and my understanding (at least from my testing) is that the issue will be resolved.
The second option is to leave everything as-is, plug a second ethernet cable in to your NAS and in the config.json file, use that second IP address rather than the current IP address you’re using.
Sorry to drive you nuts. If you’d rather just use Synology’s reverse proxy, that’s totally cool too!
I did only have one ethernet plugged in (didn’t see a reason to use the second one) but once I plugged the second one in, the IP reads as 225 for LAN 2 (224 is LAN 1).
I added another DHCP Reservation for the second ethernet port through Google Wifi and restarted DSM.
I tried to just update the config.json with the 225 IP instead (using port 3333) and began to receive a “Connection lost: The server closed the connection”
Then I deleted the MariaDB container and removed the mariadb folder and recreated the mariadb folder and reconfigured from the image again.
This time, I tried to just use 3306 and updated the config.json to reflect this with the new 225 IP. After mounting the /var/lib/mysql to docker/mariadb and setting both local and container ports to 3306, doing the environment variables…
I still get the same “The server closed the connection” (High privilege doesn’t seem to matter either)
I redid those above steps using port 3333 and still get the same “Server closed the connection” and if I change the IP back to 224 (LAN 1) on config.json, then I get the EHOSTUNREACH error.
Regarding NPM or Synology’s Reverse Proxy, I was currently trying to get DynDNS configured since Namecheap domain provider isn’t part of Synology’s whitelist of Extended Access for DDNS and without DynDNS, I don’t think I can access my jellyfin through my domain name.
There were all sorts of things regarding A Records, Wildcards for subdomains (won’t be using that for now I think) that made me think remote access jellyfin might be a lot more harder than I thought it would be. Sorry to get off topic, let me know if there was something I skipped over again!
When you recreated the MariaDB container, did you use the same folders that you initially created, and if you did, did you delete the contents of them before running the container? I’m sorry, I know we’re doing a bunch of different things but without deleting the files (or creating new folders), it will use the existing data which is what you don’t want.
1. If I were you (to simplify things), I would use either Synology’s DDNS or set up DuckDNS. I have a tutorial on how to do that here: https://www.youtube.com/watch?v=RhB6EAEi4D8
2. Create a CNAME record in NameCheap pointing to the DDNS hostname (either Synology’s or DuckDNS).
3. Create Synology’s reverse proxy and skip over Nginx Proxy Manager. While I do think that we can get it to work, for only exposing Jellyfin, I’m not sure it’s worth it.
Let me know if you have any questions!
PS I was modifying the firewall rules accordingly (adding rule for custom 3333 or 3306) but left the Nginx folders and containers unchanged!
OK no more bad gateway! To be completely honest, I think I might have not deleted the contents of the MariaDB folder the first time I just deleted the container.
I was definitely sure to delete the container and the contents the second time, but I was getting the same error using either port…
This time I just used 3306 and simply changed the NAS IP to LAN 2. Really glad I didn’t have to redo the NPM part and macvlan creation so at least I think the problem of bad gateway does rest within the NIC like you suspected
Anyway, I agree DuckDNS would have been more convenient but since I bought my domain name and went through the trouble of getting PositiveSSL working, I am fairly motivated to use it.
Tried to follow the steps with DuckDNS replacing the DuckDNS portion with Namecheap but creating a xxx.Synology.me and pointing Namecheap to that domain and I feel like I am trying to untangle too many wires at once since I am lacking a lot of fundamentals of networking (if that wasn’t obvious).
The main issue with Nginx proxy manager is now resolved but I think I will have to do some hw on how to properly configure things on Namecheap since I don’t really want to go through transferring the domain
That’s amazing news! Glad to hear that it finally worked.
As far as your domain, I think we are talking about the same thing, but I might not be explaining it well. I will try and explain it a little better now.
When you have a dynamic IP address, a DDNS hostname will track your external IP address. If it changes, navigating to that DDNS hostname will still work, as the DDNS hostname is updated with the new IP address. Basically, you can be positive that your DDNS hostname is always your external IP address. If you have a static external IP address, a DDNS hostname is not required.
So with that in mind, let’s assume that you want to expose Jellyfin using your own domain from Namecheap. In Namecheap, you will create a CNAME record. The name will be the subdomain you want to use (if you wanted to use jellyfin.yourdomain.com, the “Host” would be “jellyfin”). In the value section, you’d add the DDNS hostname you’re using (xxx.duckdns.org, for example). This is basically telling Namecheap to route traffic for the domain jellyfin.yourdomain.com to the xxx.duckdns.org IP address.
From there, you would create a new record in Nginx Proxy Manager and point it back to your Jellyfin server, then create an SSL certificate. At this point, Jellyfin is exposed using jellyfin.yourdomain.com and DuckDNS is simply being used to update your external IP address if it changes.
I realize that’s a lot, so if you have any specific questions, let me know. If you knew everything that I said above and just wanted to use your domain as the DDNS hostname, you can ignore all of this!
Thanks so much for taking the time to write out that explanation. I added a CNAME Record and put the host to “Jelly” and I was able to land on the Nginx “Congratulations” page through the jelly.domain.tld but I don’t know if this actually means they’re both going to the right place.
Maybe it would help first to understand how to set up the xxx.synology.me DDNS correctly within Nginx Proxy Manager? It seems straight forward by putting in your local NAS IP and port within the forward hostname…
But I continue to get “internal error” with “some challenges failed” whenever I try to save the SSL request. Is this because I already have certificates (PositiveSSL & LetsEncrypt from Synology.me DDNS)? How would I point the certificates that I’ve acquired so that NPM knows I have them?
I’m sure screenshots of what I’m looking at (as well as logs) would help a ton but I think there’s a lot of sensitive information on those pages that probably isn’t good to show in a public website
I feel like I am noodling you for info because it’s the “next step of something I don’t understand” that this tutorial wasn’t meant to cover so I hope I’m not taking too much of your time!
Not a problem at all, I’m happy to help!
Just to confirm, you opened ports 80/443 to the macvlan IP address, correct?
If you’re using Nginx Proxy Manager, you will have to create a new proxy host. This tutorial is for Plex, but the same principals apply for Jellyfin. Just make sure that you use Jellyfin’s internal IP address and port number: https://www.wundertech.net/setup-an-ssl-certificate-for-plex-using-nginx-proxy-manager/
You can then request a new certificate through Let’s Encrypt (it’s in the tutorial as well) and accessing jelly.yourdomain.com should work. Also, if you’re trying to generate a new certificate through DSM, it will not work as ports 80/443 are opened to the macvlan network interface and not DSM. This is expected, but without getting too far into it, the synology.me DDNS hostname should still renew as it uses DNS as opposed to ports 80/443 for renewal. If you aren’t sure what I am talking about, don’t worry, but if you’d like to learn more about it, I’m happy to explain it.
I’m hoping the tutorial I linked helps, but if I can answer any specific questions, please let me know!
Sorry I didn’t disclose that I watched the followup Plex SSL tutorial. It’s where I realized that you can type in the internal IP address and port for Jellyfin when adding an Nginx Proxy Host.
I did port forward 443->443 and 80->80 on that .198 macvlan which my router detected but I don’t have any other ports open on my router for any other device.
I would have thought putting in hostname.synology.me as a proxy host in NPM and putting the internal IP and internal port should at least bring me to the DSM page but I get the default congrats page.
I actually read one of your comments in a reddit thread and used “nslookup hostname.Synology.me” and do get the public IP; DSM also shows status as “Normal” and shows my public external IP.
So it’s saying that my DDNS hostname is working but I still thought I should be brought to the DSM login page at least.
And if this would be solved with the SSL certifiate request, I still get “internal error” when trying to configure the proxy host for hostname.synology.me
Is there anything else we can rule out or is this mostly about ports and the proxy host not being configured properly?
I want to get the DDNS working before worrying about getting the Jellyfin proxy host working.
PS I just tried with duckdns.org via your DDNS Xpenology/Synology tutorial and get the same exact problem: both domains return 502 bad gateway even though the status is “Normal” in DSM DDNS – And the SSL request gets ‘internal error’
It sounds like DDNS is working. The only goal of DDNS (at this point) is to point to your external IP address, so if “nslookup hostname.synology.me” returns your external IP address, you’re good!
As for getting to the default DSM page, I wouldn’t recommend this, but you can test it quickly if you’d like. Add “hostname.synology.me” as the domain name in Nginx Proxy Manager, use “https” as the scheme and add your Synology NAS’s IP address in the forward hostname/IP. For the port, add 5001. If you changed the default ports from 5000/5001, you will have to put the HTTPS port there. After you save that, you should be brought to the default DSM login page. Keep in mind, we aren’t going to create an SSL certificate right now, we are just using this to test.
As soon as you confirm it works, delete the proxy host. You don’t want to expose DSM to the outside internet and this process will do that, so make sure you delete the proxy host.
Let’s get this to work first, and if it does, we can move on to Jellyfin.
Let me know how it goes!
So it doesn’t seem to matter whether we change the scheme or not because http scheme + http port or https scheme + https port still return me to the default congrats page (which is when nginx proxy manager is hit with an unknown host)
I am going to assume that the port forwarding part is correct as we only need to add 80-internal, 80-external (TCP), and 443-internal, 443-external (TCP) through that macvlan we created earlier.
I remember even turning off NPM and the firewall before adding port forwarding a few days ago and STILL not being able to access my hostname.synology.me
I have no issues getting into DSM through the actual internal IP and port. However, whatever I change the default site to (What to show when Nginx is hit with an unknown Host), I ALWAYS get that page.
How is it possible that I am not configuring the proxy host correctly??
When you navigate to hostname.synology.me, you won’t actually be brought to any pages unless a web service is exposed. It’s correct that navigating to hostname.synology.me will not bring you to DSM. It actually won’t bring you to anything if you aren’t exposing anything on ports 80 or 443.
Now, with that said, if you’re hitting the “Congratulations! You’ve successfully started Nginx Proxy Manager”, NPM is working, but something is off with the proxy host.
Just to confirm, these are the settings I am hoping you can use:
Domain Name: [your_subdomain].synology.me
Scheme: http
Forward Hostname/IP: Internal IP address of your Synology NAS
Forward Port: 5000 (this should be the HTTP port. If you changed it, it will be something else).
Save it, ensure port 80/443 is port forwarded to your macvlan network interface (198 IP). Use this site to ensure that both, port 80 and 443 are open: https://www.yougetsignal.com/tools/open-ports/
Navigate to [your_subdomain].synology.me. As long as you aren’t using a DNS server, you’re supposed to be brought to the login page for DSM. If it isn’t working on your local machine, try and navigate to it using your cell phone if possible. Also, try using the mobile network if it initially doesn’t work.
This is certainly a strange issue, but since you’re getting to the “congratulations” page, my assumption is it’s something small holding us back.
Let me know how it goes!
The website says that my public IP does not have port 80 or port 443 open. My settings in Google Wifi app says I do (unless I did this wrong somehow). Also restarted the router after port forwarding in case.
https://imgur.com/a/8oNWLYj
Using CMD, I can ping the macvlan IP address but cannot ping my nas (request timed out) but I don’t know if this is normal with the way NPM was set up.
I noticed there is an option to configure the router in DSM under External Access – Do I need to do anything here?
It gives me a red flag for “Checking network environment” and there was no option to enter Google Wifi as a manufacturer of routers…
I do not have another router between the ONT terminal box so I’m pretty sure I do not have a double NAT issue nor any need to enable bridge mode.
I just realized that my ISP Fios may be blocking ports 80 and 443 as it seems to be a common problem.
Feel like this is opening another 5 cans of worms for configuring VPS/VPNs if that is the solution which seems a little complicated for remote jellyfin…
You are correct in saying that the ISP is most likely blocking ports 80/443 which is why all of these issues are occurring. I can’t guarantee that, but if we can’t get those ports open, we won’t be able to get anything else to work. I can tell you that my ISP blocked port 80 (443 was able to be opened) and I had to go into my online account and “confirm” that I wanted port 80 opened. Just to check, can you try disabling the Synology firewall and using that port checker to see if ports 80/443 will then say opened? Your screenshot for opening the ports is correct.
I had Fios at an old apartment and didn’t have issues with ports 80/443. You said it goes straight from the ONT terminal box to the router, so I assume that Fios disabled the coaxial connection and you’re using ethernet only?
You are experiencing somewhat abnormal issues, but I think that you’re close. Once we can get 80/443 opened, it should be smooth sailing.
If I remember correctly, the ONT box was connected by a thick white wire that looked a similar gauge to coaxial but didn’t screw into anything like coax normally would and looked like a green RJ45’ish head.
Only one long ethernet cable connects from the now tiny, ONT box to the Google Wifi.
To my surprise, the ports remain open once I disable the Synology firewall which gives me some hope again! But it still doesn’t work.
Initially, I didn’t think to verify if the ports were open or not because disabling Synology’s firewall still returned “502 Bad Gateway” when using either my ‘hostname.synology.me’ or my ‘jelly.domain.tld’ (both of which have the internal IP and ports in proxy host configuration within NPM)
So if:
1) My ports are apparently not blocked by my ISP
2) The router port forwarding to the Macvlan is done correctly
3) DDNS and external IP reads as “Normal” in DSM for synology.me and duckdns
4) My local internal IP services (e.g. Jellyfin, DSM) all work
I feel like there is something within DSM that needs to be configured?
Also, I remember in your Plex SSL tutorial that “remote access” would be turned off because we were using the reverse proxy to peep into our local network;
In Jellyfin, there is an option to leave a box unchecked which would block all remote connections. I guess we leave this unchecked because reverse proxy is kind of masking the remote connection?
That’s great news!
So to add to your list, a few things that we should check:
1) Google “what is my IP”. Google will return your public IP address. Then, run “nslookup [your.ddns.hostname]” and confirm that the IP address matches.
2) If the IP address matches, did you create a proxy host in NPM and does it match your DDNS hostname? It needs to match exactly so that NPM knows where to route it.
3) If it doesn’t work and you’re willing to experiment a little further, in Namecheap, create a CNAME DNS record with the value as your DDNS hostname. Set the subdomain to be jellyfin (or whatever you’d like to use). Wait about ten minutes or so and then run “nslookup [jellyfin.yourdomain.com]”. Does it return your external IP address? If so, create a new NPM Proxy Host:
Domain Name: jellyfin.yourdomain.com
Scheme: http
Forward Hostname/IP: Internal IP address of Jellyfin
Forward Port: 8096
If this doesn’t work, I would have to do a little more research on why it is happening. Generally, 502 errors occur because the proxy server cannot get a valid response from the server. If you can access Jellyfin using http://[IP_ADDRESS] and you use that same information in the Proxy Host, it should be working.
You are correct that you shouldn’t need to check off that box for blocking remote connections, but it can’t hurt to check it off if it still isn’t working after you try the steps above.
It has to be something minor at this point, we just need to figure out what it is. Let me know if this doesn’t work and we will continue troubleshooting. I am hoping that breaking it down like this will help us find what step isn’t working as expected. Let me know how it goes!
The result from google matches the external address found on DSM DDNS and the WAN from my router. The nslookup commands for my ‘hostname.synology.me’ and ‘jelly.domain.tld’ return my public IP address within “Non-authoritative answer:” (Hope that’s okay?)
From some reading and from what I can understand, someone had a similar issue and had to change their “proxy_pass” to localhost from their domain name. I really wish I understood what this meant but people who encounter similar issues seem to be configuring nginx manually somewhere.
https://www.reddit.com/r/Ubiquiti/comments/5v5kvw/port_forwarding_give_502_bad_gateway_error_with/
Would there be something we can paste or write within NPM – Edit Proxy Host -> Advanced to override the settings within DSM for faster troubleshooting?
I am scratching my head at this one if I’m being honest. 502 errors are generally web server errors which makes me feel like the macvlan network can’t connect to the Jellyfin web server. Do you have any services that aren’t on your NAS that you can try and connect to? Anything on a Raspberry Pi or Windows/Mac device?
This isn’t to say that what you’re doing shouldn’t work because it should, I’m just having a hard time wrapping my head around why it’s not working. If we can isolate it as being a macvlan to NAS issue, we will be better off when trying to troubleshoot. Another option is to use Synology’s Reverse Proxy as well just to test if it works.
I think you are right that the macvlan cannot connect in someway. The ports on my external IP address remain closed when I tried to use port forwarding to Macvlan (with NPM, MariaDB, Synology Firewall ON) and remain open if I disable Firewall (although I still get 502).
I was about to give up but I tried to port forward 80/443 to my NAS IP on my router instead of the Macvlan. Using the built-in reverse proxy, I can finally use “https://hostname.synology.me” and reach Jellyfin remotely (tested using cellular data).
The duckdns.org domain failed to validate before I forwarded those to the NAS IP but even when now validated, I’m getting “SSL_ERROR_BAD_CERT_DOMAIN” so I guess it did not validate?
I see Firefox has a problem reading some certs but I thought the synology.me one also comes from Letsencrypt so I’m not really sure what’s the problem?
Great news! Do you have a certificate for that DuckDNS domain setup and configured? If not, you will receive that error.
In Nginx Proxy Manager (if you still want to try and get that to work), did you try the bridge network IP (192.168.10.2 in the tutorial) for Jellyfin (I am assuming Jellyfin is configured on the NAS)? I can’t believe that I had this mental block for so long, but the container needs to use the bridge to communicate with the host and vice versa. So while you might access Jellyfin using the NAS’s IP address from a browser window, you will need to use the bridge network IP in the proxy host configuration. I apologize for not thinking of this earlier, it’s just hard trying to troubleshoot without seeing it myself!
You might be tired of testing/tinkering at this point, so feel free to use Synology’s Reverse Proxy if you’d like! I just don’t want to leave you stranded if you still want to use NPM.
Let me know and thanks for all your testing!
The ‘hostname.duckdns.org’ has the green lock issued by R3, with the expiry set ~ 3 months from now so I think it has been validated.
The duckdns website does not show me if it has been validated or not so I am looking only at the certificate tab under DSM.
https://i.imgur.com/0Q8SbQm.png
Interesting note about using the “npm_bridge” IP under proxy host for jellyfin – I assume we use port 8096 but it ended up going to a warning page regarding HSTS.
More importantly I think, ports 80/443 were also closed on the public IP once again if I try to port forward to the macvlan (198) on my router. I think this needs to work before being able to add that npm_bridge IP into the proxy host.
There is a bridge mode I can enable in my router (as opposed to standard NAT) but I don’t think this has anything to do with why port forwarding on the macvlan does not seem to work.
If I revist your tutorial for setting up the local and container ports within NPM, as long as we use port numbers that aren’t being used (like 8080), the macvlan IP should be able have the 80/443 from the router to the container, right?
I think I am driving you more nuts than me but I guess I can live with the built-in reverse proxy as long as I can proceed to using duckdns first, then namecheap (which has its own problems outside of this tutorial).
The error that you provided is actually very interesting! It looks like it’s trying to connect via HTTPS and an SSL certificate is not assigned.
You are correct in stating that the SSL certificate will only validate when ports 80/443 are opened to your Synology NAS. However, when you’re using Nginx Proxy Manager, you will use SSL certificates inside of Nginx Proxy Manager as opposed to DSM.
First, on Synology’s firewall, create three allow rules for ports 8080, 8081, and 4443. Then, check to see if the ports are opened. If they are, go into Nginx Proxy Manager (everything you have is setup properly, by the way), select the Proxy Host, go to “SSL” and request a new SSL certificate. As long as that validates properly, I am starting to think that it will work.
I truly do apologize for the back and forth. I am basically trying to troubleshoot through messaging which isn’t always easy! Hopefully that will work – let me know how it goes!
Here’s the other screenshots if they are helpful
https://imgur.com/a/dTwsijZ
No problem about the back and forth but I realized that I had those firewall rules in place already (I just used the application checkbox instead of typing in 3 port numbers).
https://imgur.com/a/2F3Tsl7
When I put in those 3 ports as separate custom rules, I still get the same result: external IP says 80/443 are closed. When I turn that firewall off, 80/443 are open.
But trying to launch the proxy host from NPM with “http://192.168.10.2:8096”, I get “NET::ERR_CERT_AUTHORITY_INVALID” from Chrome and “MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT” when either the ports are open or not…
So for whatever reason, port forwarding to the macvlan does not seem to open the ports to the external IP. If I use ‘LAN 2 IP’ which was used for that config.json file to avoid that NIC issue, the ports are open.
I’ve tried to add a task scheduler to use some /bin/curl command to update Namecheap DDNS but it seems people have been having their scripts and workarounds all breaking and I think I may just go ahead and try to move the domain to an approved Synology DDNS domain.
I guess I should be glad that at least the hostname.synology.me reverse proxy works and hopefully it is secure enough for my needs. I would definitely prefer not trying to SSH into the NAS playing blindfolded hopscotch as others seem to have no problem doing.
Your firewall looks perfect. The good/bad news is that when you disable the firewall, the fact that the external ports open means that it’s 100% a firewall rule that’s blocking it. I am just having a hard time even guessing what you should open next, as literally every port (80, 443, 8080, 4443, 8081, 8096, 3306) are all opened. The honest answer is that it’s probably a combination of things causing the issue and trial and error will allow you to fix it, but like you said, I’m not sure it’s worth it if Synology’s reverse proxy is working properly. With that said, if you DO want to get it to work, I am happy to continue troubleshooting. The self-signed error can probably be bypassed by selecting “advanced” and proceeding to the site. A valid SSL certificate should get rid of that error.
As far as using Namecheap for DDNS, outside of the actual domain name, I’m not sure it’s worth it. DuckDNS, Synology’s DDNS, or practically any other DDNS service will track your external IP address and do little more. With the CNAME record pointing to your DDNS hostname, you can still use your domain and everything will be pointed to the right place. I did a quick google search on Namecheap Synology DDNS and I wouldn’t suggest using any of the solutions. That’s not to say they wouldn’t work, but it’s always advised to use an “out-of-the-box” solution as opposed to a custom one. I use Synology’s DDNS service and I use my DDNS hostname for practically nothing (since I own my own domain). I just point my CNAME records to the DDNS hostname and get the same result. Obviously, you are free to do whatever you’d like! I just don’t think it’s worth the efforts since you own your own domain. Other than the hostname being in that CNAME record, you probably won’t use the DDNS hostname for anything else.
Let me know how you’d like to proceed!
I sincerely apologize for such a trivial mistake but I just forgot to hit configure after letting Synology DSM fetch the Letsencrypt… And obviously because I did not match the service with the newly assigned domain certificate, OF COURSE IT WOULDN’T MATCH
So duckdns.org, the google domain (I bought out of frustration), namecheap, they all work now…………….. But I may take your suggestion and not use a custom provider to avoid dealing with query URLs and weird cURL tasks and just let DSM deal with that.
While I would like to use the cheaper domain and SSL I paid for, I kind of don’t want to deal with DSM breaking the query URL in an update like I’ve seen happen to people in the past.
Having purchased a TLD with HSTS, I don’t think I can get around having to type in exactly https:// before my domain.tld otherwise I am also brought to an invalid cert page.
There are options to forward the domain so that “www” leads to “https://” but they come into conflict with the Dynamic DNS that I set up through Google since I can’t use host or @ twice. When I try to just add a CNAME record pointing to ‘hostname.synology.me’, I cannot establish a connection back to jellyfin.
I would think the reverse proxy for external access would still use the domain.tld and that as long as DDNS for the Synology.me had “Normal”, that I could just point to it?
Should have been a little more patient, my subdomain forward for http://www.domain.tld now works via google domains!
Basically, I can enter the bare domain or http://www.domain.tld and now it will redirect to the bare domain (jellyfin) instead of being told I need to type in exactly “https://domain.tld” due to HSTS.
I did not expect to go down this kind of rabbit hole but am really thankful for your patience throughout this process!
Hopefully, I can now try to get hardware acceleration to work properly on Jellyfin as I had trouble trying to install the vappi driver? since Intel quicksync did not seem to work with my DS918+
Thanks again!!!
No need to apologize (from your last post). I’m very happy to hear that you got it working!! I was going to mention after reading your first comment that the HTTPS settings in the reverse proxy should clear that issue up.
I wish I could help with the hardware acceleration, but I unfortunately haven’t set that up and don’t want to point you in the wrong direction. I am pretty sure that the docker container has to have the setting “Execute container using high privilege” enabled, but that’s the extent of what I remember reading (when I was considering setting this up).
If I can help in any other way, please let me know!
Hi WunderTech, quick question. Why is there a need to create the npm_bridge network? We have already created the macVLAN, isn’t the purpose of that to make it appear to be a physical network interface directly connected to the physical network? Why would the Synology NAS then have to communicate with the Nginx proxy manager?
You don’t give too much explanation for creating the bridge network other than “This is what will allow our host (NAS) to communicate with our Nginx Proxy Manager container.” (WunderTech). But why is this? What role does the NAS have that it needs to communicate with it?
The npm_bridge network is used for the host (NAS) to communicate with the container. If you have any services running on your NAS, you would need to use the bridge IP address in NPM. The bridge is the only way the host can see the container or the container can see the host. If you try and use the Synology NAS’s IP address from NPM, it won’t work as the macvlan network interface does not allow communication with the host.
In summary, you will use the bridge IP address in NPM if you have to create a reverse proxy for any services running on your NAS’s IP address. Hopefully this clears it up a little (I acknowledge that it’s a little confusing), but let me know if I can clear it up further!
I think I am understanding it now, thank you for the clarification. So in other words the npm_bridge network is used so the MariaDB has a network to live on, then we publish the port 3306 to our host the Synology NAS. Which will allow the Nginx proxy manager, (that now lives on the local network through the macvlan) to communicate with the host Synology NAS which is forwarding the port(3306) that connects back to MariaDB. And the reason for the macvlan is because of the port conflicts we would get with the Synology NAS services, that’s why we publish those ports on a new IP to avoid port conflicts using the macvlan. Is that correct? I think where some people are getting confused with your tutorial is within the networking aspect. You don’t really mention anywhere in the tutorial that you need to connect the Nginx proxy manager to the macvlan network(npm_network) and the MariaDB to the name specific bridge network(npm_bridge).
You are 90% correct. The bridge network is not used on the MariaDB container (the host network interface is used there). The macvlan network interface does avoid the port conflicts that the Synology NAS will have by default. The bridge network is used so that the Nginx Proxy Manager container can communicate with the host.
I will try and rewrite that section when I get some time to be a little clearer. If I can answer any other questions, please let me know!
Hello Ramon & WunderTech,
For me the “bad gateway” on first login is indeed due to a network problem.
From Nginx container (npm_bridge|192.168.10.x or npm_network|192.168.1.x) i can’t access MariaDB container (bridge|172.x.x.x).
I just modify the network of the MariaDB container, replace bridge (default Synology Docker network) to npm_bridge so that they are both in the same network and can comunicate. Problem solved for me.
Does this change cause a problem?
Merry Xmas 😉
Hey Wundertech, thanks for the great tutorial. It looks like you have your hands full helping others, but unfortunately I am also stuck with the bad gateway issue at nginx login. I changed port 3306 to 8725 from the start so I’m a bit perplexed as to what I could be missing. 8725 is set in both the mariadb container and the config.json. I’m also running Google Wifi router with the gateway at 192.168.86.1 so for the npm_bridge I bumped the subnet up to 192.168.96.0/24. I’m using a DS218+ with only one ethernet port and I’m not using the synology firewall. Any ideas?
You appear to have done everything right. This tutorial has been a problem for a lot of people and I’m somewhat perplexed as to why. I can replicate the issue, but can also resolve the issue on my side using the two suggestions I provided. By any chance, do you have the MariaDB Synology package installed?
Let me know and I will try and provide additional help!
Nope, the MariaDB Synology package is not installed. The only thing on there is Plex and Docker. Any suggestions are greatly appreciated. I spent some time reading through the comments section and so far no luck.
Someone just commented that this worked for them, so I’m hoping that you can try it if you get some time!
On the MariaDB container, replace the default bridge network with the npm_bridge network that we created. Then, you should be able to access the database using that npm_bridge IP address.
Let me know how it goes!
Went through the tutorial from scratch again and this time I replaced bridge with npm_bridge. Then when trying to launch the nginx container I received a docker api failed message. The logs came back with: Start container Nginx-Proxy-Manager failed: {“message”:”no available IPv4 addresses on this network’s address pools: npm_network
I’m a bit out of my depth and haven’t had a chance yet to look into it. Totally possible that I whiffed and made a mistake along the way.
Did you add both, the npm_bridge and npm_network to MariaDB or just the bridge? Try adding just the bridge if possible.
I will also mention that I haven’t had a chance to test this out and it’s a suggestion from another viewer who said it works, but the idea of it makes sense. I will try and test this out when I get some time and hopefully provide full instructions to get it working!
Thank you for this tutorial. I would like to give some information about the things I had to do to make things work on my DS918+ NAS with the macvlan setup, as I read about similar difficulties over here that I myself experienced as well (bad gateway).
First, I had to setup a macvlan interface on the NAS itself as well as within docker. The docker part is mentioned in this tutorial, but on the NAS I had to do:
(you might need to prepend sudo with these commands)
ip link add macvlan0 link bond0 type macvlan mode bridge
ip addr add 192.168.200.1/25 dev macvlan0
ip link set macvlan0 up
In my case the NAS would live in subnet 192.168.200.0/24 with 192.168.200.254 as the default gateway for that subnet. For the maclvan0 I used the first half of that subnet (/25) and 192.168.200.1 to be used as a gateway address as can bee seen in the commands. I also use bond0 instead of eth0 as that is how my NAS is physically connected to the network (LACP etherchannel). Should work the same for eth0 if that is what you have.
The docker command for me looks like:
docker network create –driver=macvlan –gateway=192.168.200.1 –subnet=192.168.200.0/24 –ip-range=192.168.200.0/25 –opt parent=bond0 name
After the commands I would have:
# ifconfig macvlan0
macvlan0 Link encap:Ethernet HWaddr 7A:08:95:A0:D5:66
inet addr:192.168.200.1 Bcast:0.0.0.0 Mask:255.255.255.128
inet6 addr: fe80::7808:95ff:fea0:d566/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:110603 errors:0 dropped:0 overruns:0 frame:0
TX packets:19396 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:30356512 (28.9 MiB) TX bytes:22121499 (21.0 MiB)
This interface would not be there without the “ip” commands mentioned earlier and I could not use the docker command to create a network with macvlan driver.
Another thing I had to do was to change a network settings on the NAS. Control Panel –> Network –> General and click on the “Advanced Settings” button under the DNS server fields. Then you will get a window with a few settings to turn on or off. One of them is called “Reply to ARP request if the target IP address is identical to the local address configured on the incoming interface”. I had to turn this one off to make everything work for me. I can imagine this might not be needed when you use MariaDB as a docker image as per this tutorial, but in my case I use MariaDB as a “normal” package running on the NAS. I guess this has to do with the fact that with the macvlan setup there are several IP addresses behind the NAS interface. To be able to communicate with the other (docker,macvlan) addresses the NAS needs to respons to ARP requests for those addresses as well and not only it’s own address.
Because I have MariaDB running “outside” of Docker, I had to tell MariaDB that is was ok for user “npm” to access the “npm” database. For that to happen I had to run this SQL query in MariaDB:
GRANT ALL PRIVILEGES ON npm.* TO ‘npm’@’l192.168.200.10’ IDENTIFIED BY ‘password’ WITH GRANT OPTION;
192.168.200.10 is the IP address that NPM is using in docker and password should be replaced with the actual password that you would like to use for this database user. Without the SQL query a remote connection from NPM to the database would not be allowed by MariaDB. You would see timeout messages in the logs of your NPM docker container.
Still need to figure out a few things. Whenever my NAS is rebooted, I have to recreate the macvlan0 interface (with the ip commands) and have to flip the ARP setting twice (turn on –> apply, turn off –> apply) to make NPM work again. If I do not do that, I get timeouts for NPM trying to connect to MariaDB. While the ARP setting is remembered, the double flip needs to happen for some reason. For the ip commands I probably need to find out a way for the NAS to configure this during boot.
Anyway, with the above commands and settings I could get NPM to work fine with MariaDB running on the NAS itself (not as a docker container).
Hope this info helps a few!
This is truly great information and I can’t thank you enough for writing it! I will try and test this out when I get some time to see if I can get it to work. Hopefully, I’ll even be able to help with your reboot issue!
Thanks again!
same issues as everyone, on a DS920+ Bad Gateway from nginx, none of the fixed (port change or nic) work, I am only using one nic in my DS920+ but it has two in the back.
Can you use the second? That’s one of the recommended fixes (and what personally works for me). Plug the second in, use the second IP address in the config file and it should push you through that error.
There is clearly an issue involving IPV6 for I get
❯ Enabling IPV6 in hosts: /data/nginx
[1/12/2021] [9:25:32 AM] [Global ] › ✖ error connect ECONNREFUSED 192.168.1.213:3306
I admire the work you are doing, just wish I could resolve this with the limited docker knowledge I have.
Are you using IPv6? I admit that I’m not, so I tailored the tutorial in a way that it uses IPv4. If you’re using IPv4, ignoring that error should allow you to proceed.
I am using IPv4, yes, though it throws errors continuously.
this is unrelated but the error log shows this:
2021/01/13 05:42:47 [error] 245#245: *11 connect() failed (111: Connection refused) while connecting to upstream, client: 192.xxx.1.200, server: nginxproxymanager, request: “POST /api/tokens HTTP/1.1”, upstream: “http://127.0.0.1:3000/tokens”, host: “192.xxx.1.101:81”, referrer: “http://192.xxx.1.101:81/login”
2021/01/13 05:42:49 [error] 251#251: *16 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: “GET /api/ HTTP/1.1”, upstream: “http://127.0.0.1:3000/”, host: “127.0.0.1:81”
2021/01/13 05:42:54 [error] 251#251: *20 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: “GET /api/ HTTP/1.1”, upstream: “http://127.0.0.1:3000/”, host: “127.0.0.1:81”
2021/01/13 05:42:55 [error] 245#245: *18 connect() failed (111: Connection refused) while connecting to upstream, client: 192.xxx.1.200, server: nginxproxymanager, request: “POST /api/tokens HTTP/1.1”, upstream: “http://127.0.0.1:3000/tokens”, host: “192.xxx.1.101:81”, referrer: “http://192.xxx.1.101:81/login”
2021/01/13 05:42:59 [error] 251#251: *23 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: “GET /api/ HTTP/1.1”, upstream: “http://127.0.0.1:3000/”, host: “127.0.0.1:81”
2021/01/13 05:43:04 [error] 247#247: *25 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: “GET /api/ HTTP/1.1”, upstream: “http://127.0.0.1:3000/”, host: “127.0.0.1:81”
So my host os is:
192.xxx.1.100
macvlan is:
192.xxx.1.101
desktop working from:
192.xxx.1.200
That makes it sound like the firewall is blocking it. Do you have the firewall enabled? Can you try disabling it temporarily to see if it works?
Also, what functionality exactly isn’t working? Does the webpage not load?
I found a solution for the bad-gateway error, in my case it was simply a wrong .json file. Check the logs of your nginx-docker, if you find something like this:
UnhandledPromiseRejectionWarning: Error: Cannot parse config file: ‘/app/config/production.json’: SyntaxError: Unexpected token \ in JSON at position 1
Double check your config. Since the code on your website contains some formatting, i.e background color, textedit in mac took those values and fu**ed up the file.
But I love the tutorial! 🙂
This is awesome! Thanks so much for sharing!
When you say to connect to “http://[npm_network]:81”, does that mean the IP address associated with the “parent=eth0” argument in the macvlan setup, or the IP of the “–ip-range” argument (192.168.1.198 in your example)?
I can get to the admin via my Syno’s IP address (any of the addresses, actually, even the ones I didn’t set as the parent), but not at the IP address I specified for the macvlan.
The actual command I used was:
sudo docker network create -d macvlan -o parent=eth2 –subnet=192.168.7.0/24 –gateway=192.168.7.1 –ip-range=192.168.7.221/32 npm_network
And I can access the admin UI from 192.168.7.177 (bond0 for eth0 and eth1) or 192.168.7.197 (eth2), but not from 192.168.7.221.
Is that expected?
The macvlan network will be the “ip-range” IP address, so 192.168.1.198 in the example.
As for accessing it from the Synology’s IP – I wouldn’t expect that behavior. When you created the container, did you add the mavclan network to the NPM container and remove the bridge network?
Hi, Im on a DS918+ – I had to use the IP adress of the Docker container to get around the bad gateway error.
ifconfig
docker0 Link encap:Ethernet HWaddr XX
inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
inet6 addr: fe80::42:5eff:febf:b58f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:648 (648.0 B)
I’m glad to hear you were able to resolve it, thank you for sharing!
Morten’s reply here needs to be made sticky somehow! DS918+ here and using the IP address of the docker container did the trick too. Updated in the config.json file, replacing 192.168.1.100 (fixed IP of my Synology) with 172.17.0.1 (docker IP).
Using the IP for “docker0” interface in the config.json fixed my “bad gateway” and the problem with the NPM container not being able to connect to the MariaDB container – Thanks for the great guide, and thanks to Morten for this hint! 🙂
Thank you! Glad you got it working!
Hi i Have a DS920+
i’m not very good with docker. Can you put this all in a docker-compose.yml, that its run with only docker-compose.yml
Yes and no – you should be able to modify the Docker Compose file on this page to get it working: https://nginxproxymanager.com/setup/
The issue is that Synology’s services use ports 80/443 and implementing NPM without using the maclvan network interface will result in it not working. I haven’t tested this out, but you CAN get it working with a docker compose file, it just needs to be modified.
thanks i tried it with this tutorial but i get this error in my nginx docker
connect EHOSTUNREACH 192.168.178.200:3333
firewall is deactiv
i changed the port from the mariadb from 3306:3306 to 3333:3306
2. trie
I have it now installed with your tutorial also with a other port(3333) put I get
[2/3/2021] [10:54:17 AM] [Global ] › ✖ error connect EHOSTUNREACH 192.168.178.200:3333
I’m assuming that 192.168.178.200 is the IP address of your Synology NAS? Are you able to get to the web interface via the macvlan network interface IP?
yes 192.168.178.200 is the 1.ip from the Nas and 192.168.178.201 is the 2. ip. 192.168.178.210 is the nginx ip.
When i forword in my modem to 192.168.178.201 i’cant get a certificate. If i forward to 192.168.178.210 i can’t get a certificate. If i forward to 192.168.178.201 i can get the certificate but get an error if i call my domain.(502 Bad gatway)
I know that you initially requested a Docker Compose file – is that what you used to create the container?
As for not getting a certificate, are you using Cloudflare by any chance? Do you have ports 80/443 opened on your NAS?
Hi,
I’am using a ds918+ and getting the same “bad gateway” error.
When i look to the logs, i get “enabling IPV6 in hosts” but i’am not using IPV6.
I tried disabling the firewall, changing the port, …
The logs in the MariaDB looks fine : “ready for connections”.
I run already a jlesage nginx server but having trouble using hostnames when connected to my wifi netwerk and was hoping this could help me.
If not, could you help me with a sollution for this?
Since you’re using a DS918+, do you have two ethernet cables plugged in? If you do, can you try setting the IP address for your NAS in the config.josn file to be the other IP address?
Hi,
when I try to follow Macvlan & Bridge Docker Network Interface Setup to create network I got this error:
“Error response from daemon: failed to allocate gateway (192.168.1.1): Address already in use”
I think this error is due to Pi-Hole as I have done macvlan network following your other tutorial I did follow your tutorials on
Can you make a tutorial on how to do this when you do have already macvlan network used by pi-hole?
I will look into creating a tutorial for this in the future! Have you tried using a different IP address?
Hello
Love the Tutorials – I have already set up AdGuard which uses one macvlan
The question is do I have to setup another macvlan for nginx on the other lan port or can I use the same macvlan which was set up for AdGuard already?
Are you using AdGuard Home still? If you aren’t, you can certainly use that macvlan network!
Hello,
I have a pfsense router with haproxy installed, could I do this same thing using that instead of installing docker on my nas?
I haven’t used HAProxy, but it looks like it’s a proxy server, while Nginx Proxy Manager is a reverse proxy server. So they are different, but depending on your goals, you might not need to implement a reverse proxy server!
I stumbled on this tutorial and I’m also getting “bad gateway”. I’ve tried all of the suggestions here but just can’t get around it on my DS716+. Is there a serious disadvantage to using the Synology reverse proxy? Thank you for making this tutorial just wish it worked for me.
Not at all. This is simply an alternative. Synology’s Reverse Proxy is a totally fine option if that’s the route that you want to take. I apologize that you are running into issues – I know that a lot of people are I still can’t replicate any of them myself.
I really appreciate your reply. If you don’t mind me asking, is there a way to look at some sort of log file to get more information which could help on troubleshooting this error? Is so, where would I find the log? I so badly want to use Nginx since I like the GUI.
So, I figured it out by carefully reading the entire page for “bad gateway”. I missed putting the MariaDB/config.json file in the MariaDB folder. Once I did the setup again with this addition no more bad gateway and I can login. Now my problem is anything I try to reverse proxy only brings me to the main webpage on port 80. For instance in nginx I configured Source = plex.mydomain.com Destination = http://192.168.0.55:32400 / SSL= HTTP only. Typing plex.mydomain.com doesn’t open plex it goes to the homepage of the webserver. No reverse proxy happening. What am I doing wrong? Thanks so much for any advice.
Glad to hear you got it working! Hmm, I haven’t seen it having trouble routing. Have you tried using HTTPS as the source and port 443? Are both, ports 80/443 opened? The good news is you should be able to fix it, since the “bad gateway” error is the hardest part to get passed.
@ WunderTech
I have no idea why I keep getting the homepage using Nginx. I followed your tutorial using Synology’s Reverse Proxy and it works just fine. I entered the same setup in Nginx and I always get the homepage. I suppose at this point since I’m nowhere near as smart as you I’ll have to use Synology instead of Nginx. Thanks again for your assistance and your great tutorials.
Don’t sell yourself short! I bang my head against the wall trying to fix things all the time. That’s the one thing with these types of setups – they’re not always smooth, unfortunately.
It’s totally fine if you want to use Synology’s Reverse Proxy (since it works), but if you want to continue troubleshooting and have any questions, please let me know!
I do (so badly) want to use Nginx but I just don’t know what questions to ask. I can say it always takes me to my under construction webpage no matter http or https setups. I went so far as to delete the under construction page from the volumes web folder. Even doing this I still see my under construction page. I tried Firefox in private mode and even cleared the cache but yep, still see that page. I have no idea where it’s coming from. Maybe if I figure out that I will solve my problem. Any thoughts?
When you say it brings you to the under construction page, do you mean for a proxy host you created? Or just that it brings you there when you type in that domain name?
It shows me the under consideration page I created for webstation. If I stop webstation then it tries to open the DSM login page. If I try to get an SSL certificate I get internal error displayed. It makes no sense to me since I’m specifying the plex port of 32400 but I’m getting no reverse proxy intervention. My domain in Cloudflare is set to DNS only.
I would try and kill web station (unless you’re using it for something). You shouldn’t be sent to DSM’s login page unless you’ve manually specified it to use port 80/443, but it’s going to involve some tinkering to try and figure out why it’s being routed there.
I completely removed web station but still not working. If I try http://plex.mydomain.com it resolves to plex.mydomaim.com:5000 but comes back not reachable. DSM seems to be taking over and not allowing Nginx to handle the requests. I followed the tutorial very carefully (countless times) including the section on macvlan. Any thoughts? I appreciate you taking the time to try and help me.
The only thing that’s confusing me is how it’s forwarding you to port 5000 without a proxy host being created. By any chance, can you trying outside of your network? I can (kind of) see it forwarding you to that address internally, but when you’re external, it shouldn’t be trying to forward you to 5000 unless a proxy host exists.
Any other weird things that you’re running into, or is that it?
I tried outside of my network with Firefox on Android and this is what I get.
The webpage at http://plex.mydomain.pw:5000/ could not be loaded because:
net::ERR_CONNECTION_TIMED_OUT
This is the only weird behavior I’m getting with my DiskStation. All other docker packages like portainer work as expected. I’ve watched YouTube videos of people using Nginx and everyone has the proxy working as it should. I’m really baffled as this doesn’t seem to be that difficult. I can say after having done the install so many times, I understand what you’re doing in the tutorial much better than when I first did it.
That is expected – you tried to access port 5000 from outside of your network and since it’s not open on your router, it won’t connect you. You don’t want to open port 5000. For the proxy host, you need to ensure that port 80/443 is properly forwarded to your macvlan network interface (where you’re running NPM), then create a proxy host. When you enter the domain into FireFox on your android (plex.mydomain.com, no port), you should be brought to Plex (if that’s the service you’re exposing).
My fault for not giving you more information. I don’t have the firewall on the DiskStation enabled and ports 80/443 are open on my router. When I type plex.mydomain.com it resolves to plex.mydomain.com:5000. I don’t add the port when I type the domain but it tries to resolve with the port 5000 automatically appending.
I’m not sure how it can be appending port 5000 to be honest. Nginx Proxy Manager is configured to use port 80/443, and the proxy host should be configured to use port 443 (and HTTPS). Port 5000 is really only for DSM, and only internally. Do you have any reverse proxies set up on your Synology NAS (outside of NPM)?
I don’t have any other reverse proxies setup. Is there someway to log what it’s trying to do?
@WunderTech
After countless redo’s everything is finally working. Thanks for everything.
That’s great news!! I wish I had better info on why it was happening, but I’m glad to hear you got it working.
I too have the bad gateway. I’ve bonded both of my ethernet ports on the Synology 920+ and it shows as ovs_bond0. So I ran the command…
sudo docker network create -d macvlan -o parent=ovs_bond0 –subnet=192.168.1.0/24 –gateway=192.168.1.1 –ip-range=192.168.1.4/32 npm_network
The network I created in docker is exactly as described above. I have verified MariaDB container is working and accessible to everything EXCEPT the npm container. Within the terminal of the npm container, I can ping outside world, local lan, new subnet ips, and the macvlan address, however I CANNOT ping the NAS IP itself. I am not using Synology Firewall, so it’s wide open. I’m not sure why it’s not allowing a connection to the NAS directly.
Since you’re running it as a container, you will not be able to ping the NAS from the container with the macvlan IP address. You can only ping it with the bridge network (npm_bridge) IP address, as the bridge is how the container and NAS can communicate. I haven’t tried setting this up using a bonded network, but a lot of people receive this error. The normal suggestion I provide is to try the second IP address assigned to your NAS (in the config file), but since you’re using a bonded connection, that isn’t possible.
I’ve had no luck replicating this issue so my suggestions are unfortunately limited. If you’re running a bonded network interface, you probably are using it to increase network speeds so getting rid of it will do more harm than good, but that’s the only way I know how to fix this issue.
I don’t know if the answer was already given for the error bad gateway but I resolve it by adding the second ethernet connection and put the Nginx-Proxy-manager on it. config.js -> to the new ip by the second ethernet connection.
Problem on Synology RS1619xs and DS7200+
Hope that help some people =)
Thank you so much for sharing!
Hi WunderTech,
I have the same problem as Ammar and Andre. I’m running AdGuard Home, so a macvlan is allready in use by the AdGuard-Container.
If I try to create a new macvlan (I tried some different IP’s at –ip-range [IP]), I get the following error:
“Error response from daemon: failed to allocate gateway (192.168.0.1): Address already in use”.
What can I do to run both containers?
Many thanks for your response!
The tough thing that I believe is happening is that a macvlan network interface can only be created individually for a specific network interface. When we set it to be a specific IP address (using /32), that macvlan network interface can only be used for an individual container. If you changed that to be something like /24, you should be able to use it for multiple containers, but then you can’t guarantee that the IP address will always be the same (and for something like this, that’s absolutely necessary). By any chance, are you using a NAS that has two ethernet ports? If so, you should be able to create two macvlan network interfaces (for each NIC) and manage it that way.
I solved the bad gateway error by setting the mariadb local port to 8725 and the container port to 3306. 8725 is used in the config.json.
Thanks so much for sharing!!
Thanks for all the work you’re putting into this project. It’s greatly appreciated. I’m not clear on how I can ping out from the container to the entire 192.168.1.x block EXCEPT the host itself. There’s no firewall open on the NAS.
I found this link, but it’s not clear to me, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_host_configuration_and_guest_installation_guide/app_macvtap
I’ve tried changing the port for MariaDB and verified it’s connection and db structure from another client, so that’s not the problem. I’ve ended up not really caring about the default ports and installed it without the macvlan address and just going with random ports that I’ll just memorize.
I’m glad you got it working. If you’re not using the macvlan network, you won’t have to worry about pinging the container/server, which kills two birds with one stone I guess!
Hi Wundertech
I am getting the following error in my log when I try start the nginx container “Start container Nginx-Proxy-Manager failed: {“message”:”failed to create the macvlan port: device or resource busy”}.”
Do you know where I might start to look to fix this?
Do you have a different macvlan network interface running on that same network interface?
If you are using VMM you need to substitute “eth0” in the instructions with “ovs_eth0” or whatever your Ethernet interface is called.
Got the same issue, failed to create the macvlan port?
Do you have any other macvlan network interfaces running? Also, did you select the right network interface name?
Thank you for this guide. I got it working on my old DS412+ !! 😀 Connecting a LAN cable to the second NIC did the trick.
NPM forwards my subdomains perfectly to my DS412, but I also have a second ubuntu server running on my network. NPM just doesn’t forward to that server, although I enter its IP and service port. It forwards to my DS412 instead…
Do I need to adjust some settings?
SOME INFO:
-DS412 nic1: 10.20.15.101
-DS412 nic2: 10.20.15.111
-Ubuntu Server: 10.20.15.102
npm_network:
-Subnet: 10.20.15.0/24
-IP Range: 10.20.15.200/32
-Gateway: 10.20.15.1
npm_bridge
-Subnet: 10.20.16.0/24
-IP Range: 10.20.16.2/32
-Gateway: 10.20.16.1
It sounds like you have everything set up properly. Do you have a firewall on the Ubuntu server running? If so, did you allow traffic from the NAS?
Thanks for creating the guide.
I’m also receiving the message connect EHOSTUNREACH 10.0.0.3:3306.
I already tried using different ports for MariaDB (and changed them in the config) and configured the firewall TCP setting.
Synology DS418Play, MariaDB 10.
Have you used a macvlan network interface for any other containers? I am not sure if IP Masquerading works with the DS418Play’s NIC, so that would be a good way to ensure that that portion is working.
So I believe I got to know why the “error connect EHOSTUNREACH local_nas_ip_address:3306″ was happening in my case. I realized that if you have a docker bridge available, if you do not select to attach the mariadb to your host nw, it defaults to the docker bridge ns available.
I tried all the debuging instructions I got here, and nothing worked until I forced mariadb docker to be on the host nw. There’s no need to update the default port on the json, you can go with 3306, UNLESS you have mariadb installed as a DSM package. Such is the case, then port will be taken and you will need to follow a different route.
I hope this helps.
This is great information for others, thanks so much for sharing it!
also, please see this post:
https://blog.oddbit.com/post/2018-03-12-using-docker-macvlan-networks/
if you follow the instructions, you will all have troubles when you try to reach the host network. When I did my debuging, I couldn’t ping the NAS from inside the container attached to the macvlan nw (nginx-proxy-manager). On this post you will find how to work it around.
I used the same macVLAN for Adguard and now I’m having an issue with NPM:
Error 2021/05/10 23:27:13 KevinStart container jlesage-nginx-proxy-manager1 failed: {“message”:”no available IPv4 addresses on this network’s address pools: ag_network (798c44a34a25df46474ej322cba8c8db3398525f46b5017ab883455234j374af)”}.
Error 2021/05/10 23:27:33 Kevin Start container jlesage-nginx-proxy-manager1 failed: {“message”:”no available IPv4 addresses on this network’s address pools: Bridge01 (cj2334c0aeb979fd38473c6dc73445d32fce789e318a8c22fc43231904c53f25)”}.
any workaround ?
thanks
Did you assign the network interface to both containers? If so, you will only be able to run one container at a time since the macvlan network interface only has one IP address. Do you have multiple NIC’s on your NAS (ethernet ports)? If so, you can try creating a second macvlan network with the other NIC!
The Congratulations page is ‘baked in’. It rather smugly has a link to the github home of nginx-proxy-manager.
I thought the general idea of nginx is that people landing on it are at a loss to know what is underneath; yet here we all are advertising the fact, for free.
You will have to create a Proxy Host in order to get around that page. You should then be able to navigate directly to the service that you’re exposing.
Hello Wundertech!
I followed your guide but NPM works only for containers that are in the macvlan, if I set a reverse proxy to something that is running on the nas such as the DSM or plex I get the “502 bad getaway error”. I also created this https://blog.oddbit.com/post/2018-03-12-using-docker-macvlan-networks/ to let the container in macvlan be able to communicate with the host but still not working. Can you help, please?
By any chance, do you know if it’s being blocked by the NAS’s firewall? The macvlan network interface isn’t on a different subnet, right?
First off I want to say, great tutorial, really informative.
I had the same “bad gateway” problem, it got solved by connecting the DS220+ other NIC and referring config file to the new network IP.
I’ve created a proxy host, using my Synology DDNS domain with a wildcard (host.mydomain.synology.me), but I get internal error every time when trying to create SSL certificate.
error:
[5/28/2021] [7:12:55 AM] [Express ] › ⚠ warning Command failed: /opt/certbot/bin/certbot certonly –non-interactive –config “/etc/letsencrypt.ini” –cert-name “npm-15” –agree-tos –email “MYEMAIL” –preferred-challenges “dns,http” –domains “MYDOMAIN”
Saving debug log to /var/log/letsencrypt/letsencrypt.log
any thoughts about what can cause the problem?
another thing is that I’m not really sure is what you’ve meant by “Ensure that you port forward ports 80 and 443 on your router to the macvlan network we created above.”
I’ve port forwarded 433 and 80 to the container ports (4433 and 8080) on the DSM external access -> router configuration.
Am I missing something?
Thanks so much! That is most likely your problem. NPM requires ports 443/80 to be port forwarded for access/Let’s Encrypt certificate retrieval. If it can’t communicate on those ports, you will get an internal error.
Can you login to your router and check to make sure that ports 80/443 are port forwarded to the macvlan IP address? I wouldn’t suggest using UPnP (which is what DSM’s external access is doing) as you won’t know exactly how it’s operating. Let me know if I can clarify at all!
Thanks for quick reply,
I moved all port forwarding to my router, and forwarded port 80 and 443 with the internal IP address of 192.168.1.198 (macvlan network IP) now certificate works fine 🙂
Glad you got it working!
Hi, i have problems to get working the url of transmission /rpc
It gives to me the conflict 409. Doing this can I solve it?
Sorry for my english
It sounds like port 409 might be a conflict? Can you try mapping it somewhere else?
Just leaving this here for anyone who is/was getting the 502 gateway error. Resolved it by changing the IP in NPM to the Synology’s 2nd NIC IP. Everything now working as expected.
Thanks for sharing! Glad you got it working!
Hi there, i’m also getting the error “[6/13/2021] [8:55:09 PM] [Global ] › ✖ error connect EHOSTUNREACH 192.168.0.5:3306”
I have a DS920+ with both NICs in use but in LACP mode, so my interface is ovs_bond0. My NAS IP is 192.168.0.5 and my Nginx-Proxy-Manager IP is 192.168.0.6 which is pingable from my pc when the npm container is running.
I set up the mac_vlan with the command “docker network create -d macvlan -o parent=ovs_bond0 –subnet=192.168.0.0/24 –gateway=192.168.0.1 –ip-range=192.168.0.6/32 npm_netmask” and the bridge networt to “subnet:192.168.10.0/24, range:192.168.10.2/32, gateway:192.168.10.1”
I tried both the host network for the mariadb container and bridge mode but getting the same error. I also tried a different Port (1521) but that also doesn’t work. I would really love to have npm running on a mac_vlan because as you already mentioned in your YT video changing the DSM Ports 80/443 to different ports brings a lot of other strange behavior.
Is there any mistake in my config or just that my NIC is not compatible?
Your config looks fine, but I’ve noticed with this tutorial that there are tons of variables. Variables that I didn’t think existed when I first created the tutorial, and that’s why so many people have different results. As far as I know, the bond network adds one of those “variables” that causes trouble. Are you able to get to the web interface and if so, do you receive the “bad gateway” error? If you do, can you try the suggestion from Morten (in the comments)?
Thank you for this tutorial. I have some issues. After getting BAD GATEWAY ERROR, I just change NAS IP ADDRESS in config.json file to 172.17.0.1. And Nginx Proxy Manager working well.
I have some docker service (Uni-Fi Controller, HomeAssistant, Calibre-Web etc) All service can be accessible from outside without any issue. But;
I have some web page in Synology Web Station. I can’t access any web page which is serving from Synology Web Station. I’m getting 502 error for all webserver.
Any advice?
It’s most likely that the container cannot communicate with the NAS. Are you using the Bridge IP address? If not, can you try to use that in NPM?
Have the ds918+ and had to follow similar steps to above to get everything working.
I can only access NGINX using the Bridge IP address thought. is this expected?
When you say access Nginx, do you mean the web portal or from a reverse proxy?
Thanks to the author for the tutorial as well as to all the contributors to this thread.
I also faced the gateway issue and solved with changing the .json with the IP address of the docker and not that of the NAS.
Where it does not work is that I have an internal error when I want to generate a certificate. This problem I had also on 2 mac OS (i7) with docker compose. My last chance was the NAS, because for some reason the NAS reverse proxy stopped working overnight.
So I installed docker compose on a mini pc with W10 and everything works perfectly fine without any errors.
It’s amazing how it can drive me crazy.
Regards
Glad that you were able to get it working!
Hello Thx for the great tutorial. I need some help
I always get this Error Bad Gateway when I want to log in
The log always says this:
[Global ] ‘ ✖ error connect EHOSTUNREACH 192.168.0.100:3306
then i changed the config and the db port local to 8725
left the firewall share on 3306
changed config to port 8725 and restarted everything
first the mariadb
then the proxymanger
On the login page I got still Bad gateway and in the log was the following
error connect EHOSTUNREACH 192.168.0.100:8725
I do not know what else I can do?
I have implemented all the suggestions on the Synlogy NAS and the settings?
One of the suggestions from a lot of people is to use the docker containers IP address in the config.json file. When you get a chance, can you try that?
I am setting this up on a DS-1621+.
So after playing around with this for a couple days, and trying to figure out the Bad Gateway issue with
error connect EHOSTUNREACH databaseIP:Port, I concluded it was a communication issue between the containers.
From what I can discern, there needs to be a link between the MariaDB and NPM containers. If you run the NPM container on its own network, you cannot create the link needed for the 2 to communicate, as both containers need to be part of the default Docker bridge.
I recreated the NPM container using the bridge for the network instead of the npm_bridge and npm_network created in the tutorial.
I used alternate ports for each of the 80/81/443 so not to conflict with the default synology reverse proxy, and created the link with the MariaDB instance.
I am also using a different port for the MariaDB instead of the default 3306.
For the .json file “host”: “mariaDB IP” is the IP of the DS-1621+, not the docker assigned IP 172…
I hope this helps. Now on to set up the reverse proxy and http>https redirects.
I appreciate the input and thank you for sharing! Does that mean you skipped the macvlan network interface step?
Just a question,
I have set up everything and it works very well except one thing.
I cannot use two way audio for my cameras when connecting through NPM. I can hear the audio just fine but cannot transmit my voice. Is there a specific nginx custom configuration to enable this?
Thanks
That sounds application specific unfortunately. What application is it?
Thank you for excellent tutorial. I have everything running on one Synology NAS but want to setup another in case on NAS goes down. I used Portainer to create vlan and then used macvlan and put nginx and mariadb on that vlan. Everything working great with ports 80 and 443 forwarded to NAS1.
Now I setup same on NAS2 but need to change the ports I forward. I tried making those changes in docker and Portainer but can not figure out how to set this up. Any advice. Thanks again.
When you say you need to use different ports, it’s because you port forwarded 80/443 to the first NAS I assume? If so, the only suggestion that I have is to use a different local port (8080 instead of 80 and 4443 instead of 443, but these can be changed to whatever you want). This is one scenario (on NAS 2) where using a macvlan is probably not necessary, as you won’t need to avoid the port conflicts. You can set up the container using the default network interface, then just change the ports.
WunderTech – thank you. Yes, on NAS1 I have ports forwarded (80/443) – everything operational. I did create a vlan for the proxy server and mariadb and that has worked well.
On NAS2 – I tried various approaches to changing ports – in the docker setup of your tutorial, I changed the “container” ports but left the “local” ports the same. That did not work. I may be missing something.
Another question – let’s encrypt uses port 80 and 443. So if I am not using those, will I be able to get SSL cert? I am thinking that will not work.
Appreciate the help.
I think that you did it opposite – you’ll want to leave the container ports the same (80 and 443), then on your local ports, change them to be something different (unless you use the recommendation below – then 80 will stay).
You are correct that Let’s Encrypt uses 80 and 443, but it only uses one of them. Therefore, if you want to keep 443 open on NAS 1 (all traffic should be routed through 443 anyways), that will allow LE to work. Then you can open port 80 on NAS 2 for LE. You will just have to use a different port for 443 on NAS 2.