When Docker Network Breaks Your Corporate Network: A Troubleshooting Journey

When Docker Network Breaks Your Corporate Network: A Troubleshooting Journey

Sometimes the most confusing infrastructure issues come from the most unexpected places.

Recently I encountered a networking issue where a Linux server suddenly became unreachable from certain internal networks after a reboot. What started as a simple connectivity problem turned into an interesting debugging journey involving Docker networks, routing tables, and subnet conflicts.

This article walks through the troubleshooting process step by step.

The Problem

A Linux server was running multiple Docker containers. After a routine server reboot, an unexpected issue occurred:

• The server was reachable from some internal machines
• But SSH connections from another internal network suddenly failed
• Ping requests were timing out
• Network services that were previously accessible were no longer reachable

Interestingly, the issue only occurred from specific network segments, which made the problem harder to diagnose.

Initial Checks

The first step in troubleshooting any connectivity issue is to verify the basics.

Check the server IP

ip addr

The server still had the correct internal IP address.

Check SSH service

ss -ntlp | grep 22

The SSH service was running normally and listening on port 22.

Check Docker containers

docker ps

All containers were running normally.

At this point, nothing seemed obviously broken.

Investigating Network Routing

The next step was to inspect the server’s routing table.

ip route

ip route

One entry immediately stood out:

192.168.x.x/20 dev br-xxxxxxxx proto kernel scope link src 192.168.x.x

This route was associated with a Docker bridge network.

Docker automatically creates bridge networks for containers, each with its own subnet and gateway.

Normally this works perfectly fine — unless the subnet overlaps with your corporate network.

A Suspicious Traceroute

To understand how packets were being routed, I ran:

traceroute <internal-gateway>

Instead of going through the expected corporate gateway, the first hop looked like this:

traceroute 192.168.105.1

1 192.168.96.1

This IP address belonged to the Docker bridge gateway.

That meant the Linux kernel believed the destination network existed inside the Docker network instead of the corporate network.

This explained everything.

Root Cause

The problem was caused by a subnet conflict between Docker and the corporate network.

Docker had automatically created a bridge network with a subnet similar to this:

192.168.x.x/20

Unfortunately, this range overlapped with part of the corporate network.

Because of this overlap, the Linux routing table contained a route pointing to the Docker bridge interface.

As a result:

• Packets intended for the corporate network
• Were incorrectly routed to the Docker bridge
• Which obviously could not reach the destination

In networking terms, the route with the matching subnet took priority, causing traffic to be misrouted.

Why It Happened After a Reboot

Before the reboot, the routing table order happened to work correctly.

But after the restart:

• Docker networks were recreated
• The routing table was rebuilt
• The conflicting subnet route was re-added

This caused the misrouting issue to appear.

The Fix

There were two possible solutions.

Option 1 — Remove the conflicting Docker network

If the network was not critical:

docker network rm <network-name>

This immediately removed the conflicting route.

Option 2 — Recreate the network with a safe subnet

The better long-term solution is to assign a custom Docker subnet that does not overlap with corporate networks.

For example:

networks:
  app-network:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.0.0/16

Using a private range such as:

172.16.0.0 – 172.31.255.255

helps avoid conflicts with corporate environments.

Verifying the Fix

After removing the conflicting network, I rechecked the routing table.

ip route

The problematic route was gone.

Running traceroute again showed the correct result:

traceroute 192.168.105.1

Output:

traceroute 192.168.105.1

Traffic was now routed correctly through the corporate gateway.

SSH connectivity immediately started working again.

Key Takeaways

This issue highlights an important lesson for containerized environments.

Docker networks can unintentionally conflict with existing infrastructure networks.

When troubleshooting connectivity issues on container hosts, always check:

• Docker bridge networks
• Routing tables
• Subnet overlaps

A simple command like this can reveal hidden problems:

ip route

Final Thoughts

This debugging session reinforced something every infrastructure engineer eventually learns:

Many network issues are not caused by firewalls or services — but by routing decisions.

Containers are powerful, but they also introduce additional networking layers that interact with the host system.

Understanding how Docker networking integrates with the Linux networking stack is essential when operating containerized infrastructure.

If you’re running Docker in a corporate environment, it’s worth defining custom subnets explicitly instead of relying on Docker’s automatic defaults.

It can save you from a long troubleshooting session later.