How a Docker Network Overlap Broke My VPN Connectivity

Recently, I faced a puzzling issue: a VPN client could reach my Linux server (packets arrived at the interface), but no responses were sent back. Services running in Docker were unreachable, even though ports appeared open in nmap.

Root Cause

A newly deployed Docker stack automatically created a network using the range 192.168.0.0/20. This overlapped with my VPN subnet (192.168.3.0/24). As a result:

• Incoming packets from the VPN were routed correctly to the server.
• The server’s response packets were routed through the Docker bridge (because of the overlapping range), causing asymmetric routing.
• Linux’s rp_filter and firewall dropped these responses silently.

Symptoms

• tcpdump showed ICMP requests arriving, but no replies leaving.
• ip route get VPN-client-IP revealed the wrong egress interface (br-xxxx instead of the VPN interface).

Solution

Update Docker network to avoid conflicts. In the docker-compose.yml:

services:
  service_name:
  [...]
    networks:
      - custom_net
[...]
networks:
  custom_net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.1.0/24
          gateway: 172.30.1.1

And then restart the compose stack.

Lesson Learned

Always define custom IP ranges for Docker networks or configure default-address-pools to avoid automatic allocation in common ranges like 192.168.x.x. Overlapping subnets can silently break routing and connectivity.

Any doubts?

Do not hesitate to contact me with any questions, suggestions, complaints, or clarifications you may have; I'll be happy to talk to you!