Have you ever had a connection fail so silently that even your firewall didn’t notice? No “Connection Refused,” no UFW block logs, just… a void. I recently ran into a bizarre networking conflict that felt like a ghost in the machine, and the culprit was an over-ambitious Docker network.

The Symptoms

I was trying to SSH into a machine at 192.168.25.27 (Glinet Slate AX in Access Point Mode) from my main server (192.168.6.250 – DXP4800 Plus).

• The Destination: SSH was enabled and active.
• The Firewall: UFW was on, but checking the logs showed zero outbound blocks to that IP.
• The Firewalla Gold SE: Network rules allowed cross vlan traffic on port 22.
• The Result: Total silence. The packets were leaving the application but never hitting the physical wire.

The Investigation: The Smoking Gun

After checking the usual suspects, I ran a simple routing query:

Instead of seeing the traffic go out through my physical gateway (the router), the output showed this:

The revelation: My server thought that machine lived inside a Docker bridge, not on my physical house network.

The Problem: The “/20” Monster

When I inspected the Docker network associated with that bridge (part of a Big Bear Joplin stack), I found the culprit:

In networking, a /20 subnet mask is a greedy monster. It doesn’t just cover 192.168.16.x; it claims every IP from 192.168.16.0 all the way to 192.168.31.255.

Because my destination IP (192.168.25.27) fell inside that range, the Linux kernel did exactly what it was told: it routed the traffic to the local Docker bridge. Since there was no container actually using that IP inside the bridge, the packets simply died in a virtual dead-end.

The Fix: Evicting the Squatter

To fix this, I chose to manually define the network boundaries in the Joplin docker-compose.yml file, moving it to a non-overlapping space.

The Update in docker-compose.yml:

The “Zombie Bridge” Recovery

Updating the config wasn’t enough. The kernel was still haunted by the old route. To fully refresh the system and find the real path to my SSH target again, I had to perform two critical steps:

1. Tear down the stack: sudo docker compose down (Or in my case I just used Arcane Docker manager and downed the Joplin stack)
2. Exorcise the Ghost: Even after the stack was down, the virtual bridge remained in the system. I had to manually delete the link to force the kernel to look at the physical gateway again:

Bash

Donate Keith A Ko-fi

Once that “Zombie Bridge” was gone, `ip route get` finally pointed back to my router, and the SSH connection went through instantly.

The Bottom Line

Docker is incredibly convenient, but its default “Automatic IP” assignment can sometimes “squat” on your physical LAN IPs. If you ever find yourself unable to reach a local device, check your routing table. You might find that one of your containers has accidentally “stolen” a whole section of your house.