Hi,

 

I have my Unraid main IP of 192.168.1.10 and its GUI running in standard 80/443 ports of that IP.

 

Since few years I had my swag proxy docker 80/443 ports bound to dedicated IP, running as a secondary IP 192.168.1.11 on the same interface as Unraid GUI, so on the same br0 (eth0). I was achieving assigning secondary IP to br0 by using User Scripts plugin, to add additional IP to br0 interface after array start. The script looks like this:

 

IP=191.168.1.11/24
DEV=br0
echo "Adding $IP to $DEV"
ip address add $IP dev $DEV

 

After executing the above script I have had such a config:
 

root@unraid:~# ip addr | grep 192.168.1
    inet 192.168.1.10/24 metric 1 scope global br0
    inet 192.168.1.11/24 scope global secondary br0

 

but Unraid GUI was bound to .10 only, and swag docker on .11 only - using the same standard 80/443 ports.

 

It was working fine until 7.x Unraid was released. Seems that on 6.x Unraid GUI was binding to the primary IP only (possibly the one defined in Settings/Network), not to all IPs assigned to the br0. That way ports 80/443 were free on the secondary IP and available for swag docker.

 

Seems the above behaviour was changed after upgrading to version 7, and now Unraid GUI is binding on all IPs assigned to br0 interface. That causes a problem with swag running on secondary IP, as now there is no free ports available for this docker.

 

I solved this problem by assigning different, non-standard http/https port numbers for Unraid GUI, but is there any way to force Unraid GUI 7.x to bind only to its primary IP address and leave ports on the secondary IP untouched? as it was before...

Edited May 5, 20251 yr by Smith007

5 minutes ago, Smith007 said:

I was achieving assigning secondary IP to br0 by using User Scripts plugin, to add additional IP to br0 interface after array start.

Why?`There is no need to do any of this, selecting br0 as the container network already gives it its own IP with all ports available. 

 

8 minutes ago, Kilrah said:

Why?`There is no need to do any of this, selecting br0 as the container network already gives it its own IP with all ports available. 

 

Swag is running on Custom:proxynet for its backend services with plenty of free IPs and all ports available. But it has defined 192.168.1.11:80 and :443 for its frontend. Since version 7.x this is not working, as ports 80/443 are taken by Unraid GUI, which now binds to all IPs assigned to br0. It was not like this before, why was it changed?

I don't know, but I've always seen the solution to that being to change the ports used by the unraid UI. Never seen your solution used so it's not likely it would be something that would have been tested for. 

Clearly it was not tested. It was changed compared to 6.x though - intentionally or not.

 

My solution is quite simple and so far allowed to keep standard ports for both GUI and swag frontend. Yes, the other solution is to change the GUI ports, but I see it less elegant and also possibly confusing in emergency scenarios (you need to know and remember non-standard ports). Thus would love to see the old behaviour back - meaning Unraid GUI binding only to the primary IP defined for br0 in Settings/Network.

Edited May 5, 20251 yr by Smith007

Confirming having issues with multiple ip's assigned to br0 after updating to 7. Running Pihole on separate ip and now I am unable to get these up and running using a similar approach as @Smith007.

On 5/5/2025 at 6:05 PM, Smith007 said:

Clearly it was not tested. It was changed compared to 6.x though - intentionally or not.

 

 

Intentional, for changing ipv4 and ipv6 addresses, it's in the release notes I'm sure

Officially use of secondary addresses is not supported, because some services may not work properly with it, be aware.

 

I made an update for the next release to exclude secondary addresses from binding.

 

6 minutes ago, bonienl said:

Officially use of secondary addresses is not supported, because some services may not work properly with it, be aware.

 

I made an update for the next release to exclude secondary addresses from binding.

 

Any reason why this worked when I upgraded to 7.1.0, but failed after going to 7.1.1? And do I have to a manual downgrade to 7.0.1 to get this working again? Right now all services has stopped due to my dns servers not working... 

Edited May 10, 20251 yr by Ulf Thomas Johansen

8 minutes ago, bonienl said:

(...) I made an update for the next release to exclude secondary addresses from binding.

 

 

Thanks a lot, much appreciated.

 

Side comment: that is why I love open projects or small companies. Try to get such a response from the big guys.

A better approach is to assign your Pihole container to custom network eth0 (or br0) and assign a static IP address for the container on the custom network.

 

I am using Unbound as DNS server. Here is an example of assigning static addresses to the container (running on br0)

 

3 minutes ago, Ulf Thomas Johansen said:

Any reason why this worked when I upgraded to 7.1.0, but failed after going to 7.1.1? And do I have to a manual downgrade to 7.0.1 to get this working again? Right now all services has stopped due to my dns servers not working... 

 

For me it was broken in any version 7. I upgraded from 6 and as I had no time to debug, I rolled back. Only now I finally had some time to sit and debug. But I'm pretty sure it was in 7.0 as well.

Interresting. In my case I’ve running on 7 since it became available, and on 7.1.0. It only failed after 7.1.1. 

22 minutes ago, bonienl said:

A better approach is to assign your Pihole container to custom network eth0 (or br0) and assign a static IP address for the container on the custom network.

 

I am using Unbound as DNS server. Here is an example of assigning static addresses to the container (running on br0)

 

Just tried this. Removed all the manual ip add’s, and assigned the ip’s in the custom br0 - still fails. No ping or service response.

1 hour ago, bonienl said:

A better approach is to assign your Pihole container to custom network eth0 (or br0) and assign a static IP address for the container on the custom network.

 

I am using Unbound as DNS server. Here is an example of assigning static addresses to the container (running on br0)

 

 

Here's my config @bonienl Any suggestions as to how I can get my containers back up? I have downgraded to 7.0.1, but same issue. Running all zfs's I don't want to downgrade below 7.

You need to enable host access in the docker config if you try to access the pi hole from unraid itself.

 

By default it's a security feature of docker to not allow host to container communication on Mac/ipvlan

Thanks for the follow-up, but this is not a new setup - this has been running for years. With host access enabled.

1 minute ago, Ulf Thomas Johansen said:

Thanks for the follow-up, but this is not a new setup - this has been running for years. With host access enabled.

 

Aha - that is indeed interesting. Testing the suggested fix now.

Thank you so much @Mainfrezzer - I have something to learn when it comes to searching!

 

Problem solved.

Problem will reoccur if you reboot your server.

3 minutes ago, Ulf Thomas Johansen said:

Problem will reoccur if you reboot your server.

For the moment just change Unraid GUI ports and use them for your Pi Hole as before. And wait for the update that @bonienl scheduled, which will restore the previous behavior of binding to the primary br0 IP only.

On 5/10/2025 at 12:55 PM, bonienl said:

Officially use of secondary addresses is not supported, because some services may not work properly with it, be aware.

 

I made an update for the next release to exclude secondary addresses from binding.

 

Hey @bonienl,

are there any updates regarding this topic? Because I just updated from the last 6.x version to the newest 7.1.4 and am still experiencing this issue.

I currently have two extra IP addresses on the br0 which is connected to the eth0 interface. This br0 with its addresses is used to connect to Docker containers like traefik or pihole.

Upon starting unRAID, it claims every three IP addresses for its GUI, thus letting the containers run into the “bind already used” error. Interestingly it binds every IP explicitly.

When following your comment here, this should have already been fixed in version 7.1.3, as this was the next release after your comment.

Kind regards,

Tim