Goal

I'm trying to fully segregate Unraid and a Dockerized NGINX instance using two physical NICs:

• Unraid is bound to br0 (NIC 1)

• NGINX (container) is bound to br1 (NIC 2)

The intention is to isolate the traffic paths and allow communication from Unraid → NGINX.

Network Interface Setup

I’ve correctly configured Unraid’s network settings:

• br0 and br1 are assigned to separate NICs

• No IP conflict

• Bridging and assignment are set as expected

Connectivity Test

Both interfaces (br0 and br1) respond to pings independently, confirming physical and IP-level connectivity

PS C:\Users\admin> ping 192.168.1.40

Pinging 192.168.1.40 with 32 bytes of data:
Reply from 192.168.1.40: bytes=32 time<1ms TTL=64
Reply from 192.168.1.40: bytes=32 time<1ms TTL=64
Reply from 192.168.1.40: bytes=32 time<1ms TTL=64
Reply from 192.168.1.40: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.40:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
PS C:\Users\admin> ping 192.168.1.41

Pinging 192.168.1.41 with 32 bytes of data:
Reply from 192.168.1.41: bytes=32 time<1ms TTL=64
Reply from 192.168.1.41: bytes=32 time<1ms TTL=64
Reply from 192.168.1.41: bytes=32 time<1ms TTL=64
Reply from 192.168.1.41: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.1.41:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

Docker Settings

Docker is set to use macvlan as needed, with custom bridge support enabled.

The Issue

Even though Unraid logs clearly show that br1 is processed on Docker startup:

Jun 28 14:01:44 Tower rc.docker: Starting network...
Jun 28 14:01:44 Tower rc.docker: container nginx has an additional network that will be restored: local
Jun 28 14:01:45 Tower rc.docker: Processing... br0
Jun 28 14:01:45 Tower rc.docker: created network macvlan br0 with subnets: 192.168.1.0/24;
Jun 28 14:01:45 Tower rc.docker: ip link add link br0 name shim-br0 type macvlan mode bridge
Jun 28 14:01:45 Tower rc.docker: ip link set shim-br0 up
Jun 28 14:01:45 Tower rc.docker: ip -6 addr flush dev shim-br0
Jun 28 14:01:45 Tower rc.docker: ip -4 addr add 192.168.1.40/24 dev shim-br0 metric 0
Jun 28 14:01:45 Tower rc.docker: ip -4 route add default via 192.168.1.1 dev shim-br0 metric 0
Jun 28 14:01:45 Tower rc.docker: created network shim-br0 for host access
Jun 28 14:01:45 Tower rc.docker: Processing... br1
Jun 28 14:01:45 Tower rc.docker: connecting nginx to network br1
Jun 28 14:01:45 Tower rc.docker: connecting netshoot to network br1
Jun 28 14:01:45 Tower rc.docker: ip link add link br1 name shim-br1 type macvlan mode bridge
Jun 28 14:01:45 Tower rc.docker: ip link set shim-br1 up
Jun 28 14:01:45 Tower rc.docker: ip -6 addr flush dev shim-br1
Jun 28 14:01:45 Tower rc.docker: ip -4 addr add 192.168.1.41/24 dev shim-br1 metric 0
Jun 28 14:01:45 Tower rc.docker: ip -4 route add default via 192.168.1.1 dev shim-br1 metric 0
Jun 28 14:01:45 Tower rc.docker: created network shim-br1 for host access
Jun 28 14:01:45 Tower rc.docker: Network started.

When I run docker network ls, there is no br1 network registered in Docker.

root@Tower:~# docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
08bc6554cd9f   br0       macvlan   local
cc0ea04dad1e   bridge    bridge    local
59324e20c804   host      host      local
84eac1d6efe4   local     bridge    local
042a1f312c08   none      null      local

Looking for guidance on:

• Why br1 is not registered as a usable Docker network despite startup logs saying otherwise.

• Whether Unraid is doing partial setup (interface only) but not registering it with Docker’s IPAM

Thanks in advance for your time and help.

Solution was to ditch bridges and forcefully map the container's ports in extra parameters:
-p '192.168.1.41:80:80' -p '192.168.1.41:443:443'

However it is interesting to note that Unraid's UI mixes up the actual IP addresses, perhaps this is a bug, not sure:

ALSO (very important), uncheck the "enable default gateway" for the secondary interface because otherwise you will have an industrial quantity of asymmetric routing which will break your services.

Edited July 1, 20251 yr by DespairServices