I am having issues with Unraid being unable to to ping or access ips outside of the same sub-net. Initially only docker apps had this issue but while I was playing around with the settings now it seems I can't even get Unraid server itself from command line to ping the other networks (unraid on 192.168.1.x ip and other networks are on 192.168.10.x or 192.168.30.x sub-net). Other devices from same sub-net as Unraid can ping those other networks fine so does not seem firewall issue and unraid itself can ping the gateway ips of the other networks such as 192.168.10.1 but then fails to ping any other ips on the same network such as 192.168.10.10. 
Any ideas what could be the issue?

if in vlans then its at the switch/router level preventing cross talk as it should...

you may need host access to custom enabled to allo traffic cross

 

Unraid is not a networking device...

 

So I have to assume networking misconfigurations, especially when Unraid is isolated in its ability to reach other subnets

 

lets review:

Key Observations

-Unraid is on 192.168.1.x

-It can ping 192.168.10.1, the gateway for another subnet

-It cannot ping 192.168.10.10, a host on that subnet

-Other devices on 192.168.1.x can ping those .10.x and .30.x hosts

-Initially only Docker was affected, but now the whole Unraid OS is impacted

 

casues and fixzes... terminal commands to double-check and review:

1. You may be missing a ip route...

ip route

 

Make sure you see something like:

Quote

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.x
 

 

If you do not see a default route, or something is misconfigured, try reassigning it:

ip route add default via 192.168.1.1 dev eth0

 

Docker Bridging/Custom Networking Overwriting Routes

When Docker is configured with custom bridges or macvlan networks, it can interfere with Unraid’s ability to route traffic properly.

Try disabling Docker temporarily:

Go to Settings > Docker

Set Enable Docker to No

Apply

 

then try to ping 

ping 192.168.10.10

-If it works now, the issue is caused by Docker overriding Unraid’s network stack, often due to macvlan vs ipvlan or poor bridge configuration.

 

3.Unraid Static IP + Wrong Netmask

Ensure that Unraid’s IP/netmask is correct. If you're using a static IP like 192.168.1.50, make sure the subnet mask is 255.255.255.0 (not e.g., 255.255.0.0, which can cause weird behavior).

Check with:

ip addr show eth0

-the interface that has the ip address.... eth0, br0, bond0, etc...

--Review subnets and ip ranges... defaults /24 255.255.255.0 255 ip 254 useable for devices...

 

4. Proxy ARP or Isolation on Inter-VLAN Routing

If your router/firewall is doing inter-subnet routing (e.g. 192.168.1.x ↔ 192.168.10.x), and Unraid has no firewall issues, then it's possible that Unraid is not replying to ARP requests correctly.

Try checking ARP with:

arp -a

-If Unraid isn't seeing MACs of .10.x hosts despite routing being OK, Docker/macvlan settings can again be at fault. Try using ipvlan instead of macvlan for Docker networks in Unraid.

 

BUT THIS SOUNDS LIKE A VLAN CROSS TALK ISSUE... Not enough info to further assist....

Thanks for the help. Host access to custom enabled to allow traffic across is already enabled. I disabled Docker and enabled again and now form Unraid I can ping 192.168.10.10. Ip route from Unraid shows:

 

Tower:~# ip route
default via 192.168.1.1 dev shim-br0 
default via 192.168.1.1 dev br0 metric 1 
default via 192.168.1.1 dev eth1 proto dhcp src 192.168.1.223 metric 1005 
default via 192.168.10.1 dev br0.10 proto dhcp src 192.168.10.242 metric 1066 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.0.0/16 dev shim-br0 proto kernel scope link src 192.168.1.2 
192.168.0.0/16 dev br0 proto kernel scope link src 192.168.1.2 metric 1 
192.168.1.0/24 dev vhost1 proto kernel scope link src 192.168.1.223 
192.168.1.0/24 dev eth1 proto dhcp scope link src 192.168.1.223 metric 1005 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 

 

ip addr show eth0 output:

 

Tower:~# ip addr show eth0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 74:19:f8:15:f5:23 brd ff:ff:ff:ff:ff:ff

 

arp -a output:

 

Tower:~# arp -a
? (172.17.0.3) at 02:42:ac:11:00:03 [ether] on docker0
core.jumnim (192.168.1.72) at bc:24:11:04:48:7b [ether] on vhost1
pi.hole (192.168.1.71) at b8:27:eb:35:3e:e0 [ether] on vhost1
unifi.jumnim (192.168.1.1) at 94:2a:6f:f2:08:25 [ether] on shim-br0
Desktop.jumnim (192.168.1.24) at 8c:c6:81:f1:40:9b [ether] on vhost1
? (172.17.0.2) at 02:42:ac:11:00:02 [ether] on docker0
? (192.168.1.30) at 84:47:09:23:07:c5 [ether] on vhost1
unifi.jumnim (192.168.1.1) at 94:2a:6f:f2:08:25 [ether] on vhost1

 

 

But from Docker app (Nextcloud as an example), ping fails and its ip route shows:

 

root@9d7ef8fde8b7:/# ip route
default via 192.168.1.1 dev eth0 
192.168.0.0/16 dev eth0 scope link  src 192.168.1.9 
root@9d7ef8fde8b7:/# 

 

Issue seems like on Docker side but not sure what I am doing wrong. Dockers settings are below, any other ideas on what could be the issue?

 

Edited May 13, 20251 yr by Teknowiz

Thanks, this confirms a Docker networking conflict, especially related to how Unraid is bridging and routing containers. You're hitting the common issue where Docker containers using a custom bridge or macvlan network can't reach other subnets due to how Linux handles inter-subnet traffic and isolation between interfaces.

as Your container (Nextcloud):

default via 192.168.1.1 dev eth0 
192.168.0.0/16 dev eth0 scope link  src 192.168.1.9

The container is on 192.168.1.9 and its subnet route is 192.168.0.0/16 — which includes 192.168.10.x and 192.168.30.x — but since it's only on 192.168.1.x, this route is black holing other subnets (10.x, 30.x) because no actual interface routes to them.

 

Some potential ways to fix:

 

Option 1: Reduce Container Subnet Scope

 

If you’re using 192.168.0.0/16 as the container’s subnet in a custom Docker network, reduce it to 192.168.1.0/24 so Docker doesn’t try to "own" the whole 192.168.0.0/16 range.

Go to Docker > Settings > Docker Custom Network

Look for the custom network configuration that includes 192.168.0.0/16

Change it to 192.168.1.0/24

Apply and restart Docker

 

*This ensures Docker only claims 192.168.1.x, not the entire /16 block that includes 192.168.10.x and 192.168.30.x.

 

Option 2: Switch from macvlan to ipvlan (if you're using macvlan)

-While I Prefer macvlan do to lan identity... ipvlan will keep the same mac which may be needed here...

 

If Docker containers are using macvlan, they often cannot communicate with the host or other subnets due to Linux kernel limitations.

Switch to ipvlan which doesn't isolate as aggressively:

In Unraid's Docker network settings, create a custom ipvlan network instead of macvlan

Use that for containers that need inter-subnet communication

You’ll find this under:

Settings > Docker > Advanced

Switch “Docker custom network type” to ipvlan

Apply changes and reassign containers to the new network

 

Option 3: Add Static Routes (Temporary Workaround)

 

Inside the container, you could manually add a static route for the other subnets via the gateway:

ip route add 192.168.10.0/24 via 192.168.1.1
ip route add 192.168.30.0/24 via 192.168.1.1

as the docker is not gettign the ip route and adational data beyond teh bridge...

 

To confirm that the issue is subnet masking, inside the container try:

ipcalc 192.168.1.9/16

-ip calc may note be installed default... 

 

as it appears that unriad via host is working as it should, you may need to edit the dockers you want to cross subnet become the host network...

 

Review:

Some Docker networking Info when to use what docker network:

 

Thank you very much for the help, I went with Option 1: Reduce Container Subnet Scope and set it to 192.168.1.0/24 and now it works perfectly. Have been trying to figure out this for months and wasn't able to so really appreciate it.