How to isolate Docker container traffic with Linux VLANs

Why isolate Docker container traffic with VLANs?

When deploying dozens of applications on a single server, the need to separate who talks to whom arises quickly. By default, Docker creates an internal network bridge where every container gets a private IP and can freely talk to its neighbors. In practice, this means that if a web application is compromised, an attacker has a clear path to spy on database traffic or other sensitive services running on the same host. To avoid this security nightmare, engineers turn to physical and logical segmentation using virtual local area networks.

VLANs, short for Virtual Local Area Networks, act as invisible partitions within the same physical network cable. In Linux, we can teach the operating system to tag data packets with identification numbers called 802.1Q tags. When we apply this concept to the container ecosystem, we can bind entire projects to specific subnets, ensuring corporate traffic does not mix with support tools or testing environments. This strategy protects data against accidental leaks and meets rigorous compliance requirements in mission-critical environments.

Understanding the role of the Macvlan driver in Docker

To make Docker talk directly to Linux VLANs without going through the standard bridges, the most elegant path is using the Macvlan driver. In practice, Macvlan allows you to create a virtual network interface coupled to your server's main physical network card, gaining the ability to assign real local network IPs directly inside containers. It is as if each container gets its own physical network card connected to your company's switch, responding to external requests without needing complex port-forwarding rules.

Before diving in, it is worth remembering that network isolation is a cornerstone of a robust infrastructure, working much like what we discussed in our guide on how to isolate server traffic with VLANs and switches at the hardware and switch level. However, when we bring this into the operating system, we need to handle details such as network rule persistence and traffic behavior when the OOM Killer kicks in to terminate memory-hungry processes on the server. Careful planning prevents unpleasant surprises during service startup.

Creating the VLAN interface on the Linux host step by step

The first step to implement this architecture happens directly on the host operating system, even before touching Docker. We need to load the kernel module responsible for VLANs and create the virtual subinterface linked to our main physical network card. Let's assume your physical network card is named eth0 and we want to create the VLAN with ID 10.

1. Load the 8021q module into the kernel by running the command in the host terminal:

   sudo modprobe 8021q

2. Create the virtual interface linked to the physical card with the VLAN identifier:

   sudo ip link add link eth0 name eth0.10 type vlan id 10

3. Activate the newly created virtual interface to start passing packets:

   sudo ip link set dev eth0.10 up

With this structure ready in the operating system, Linux already knows how to separate and tag packets belonging to that specific VLAN. The next challenge is teaching the Docker engine to recognize this newly created interface and make it available for our container configuration files.

Configuring the Macvlan network in Docker Compose

Now that the virtual physical interface is active on the host, we can declare our custom network in Docker so containers can use it transparently. Instead of creating the network manually via command line every time, the recommended practice in production environments is managing this through well-documented composition files or automation scripts.

Below is an example configuration snippet in a docker-compose.yml file that connects a service directly to our newly created VLAN:

version: '3.8'

networks:
  vlan10_net:
    driver: macvlan
    driver_opts:
      parent: eth0.10
    ipam:
      config:
        - subnet: 192.168.10.0/24
          gateway: 192.168.10.1

services:
  app_producao:
    image: nginx:alpine
    container_name: app_producao
    networks:
      vlan10_net:
        ipv4_address: 192.168.10.50
    restart: unless-stopped

In this structure, the container app_producao takes the IP address 192.168.10.50 within the company's physical network, isolated from any other container running on the default Docker network. To ensure everything works seamlessly and services respond to routine tests without hidden flaws, it is worth integrating rigorous checks, aligned with best practices on how to test Docker container health checks offline before putting the environment into final production.

Validating isolation and resolving common pitfalls

After spinning up containers on the new VLAN, the most important step is validating if isolation works as planned. A classic pitfall of the Macvlan driver is that, by default, the host operating system and containers connected via Macvlan cannot talk directly to each other through that interface due to kernel network architecture restrictions. If you need the host to access the container, you will need to create an additional virtual interface of type macvtap or configure specific bridge routes.

Another critical maintenance point involves continuous auditing of log files generated by isolated applications. Keeping monitoring active prevents silent network failures from going unnoticed, complementing environment security alongside automated routines like how to manage container logs with Logrotate on Linux. Testing network resilience by simulating link drops also helps confirm traffic does not leak to other VLANs during peak moments or abrupt switch reboots.

Final considerations on secure networks in Docker

Isolating Docker container traffic using VLANs on Linux turns an ordinary server into a segmented fortress, ideal for corporate environments and demanding infrastructure projects. Although it requires prior understanding of network concepts and interface manipulation on the host, the gain in terms of security, organization, and traffic control widely outweighs the operational effort involved in initial setup.

By combining the Macvlan driver with monitoring best practices, restrictive firewall policies, and rigorous connectivity tests, you ensure your applications run isolated and protected against unauthorized access. This mature approach raises the technical level of your infrastructure, allowing you to scale services with peace of mind and total operational predictability.