Docker Community Forums

Share and learn in the Docker community.

Docker containers, exposing containers to the internet, VLANs, DMZ, router IPs -- is my understanding correct?

General Discussions
#1

Hello. I am just starting on my Docker journey so I am researching/reading whatever I can. The one thing I am unsure of is how I should handle the network side of my containers.

My home network has a few VLANs. The relevant ones are:

  • trust
    • my main computer
    • can access internet and other VLANs
  • serve
    • all my server/service stuff like samba and what not
    • limited internet access
    • can access other devices in serve
    • cannot access other VLANs
  • dmz
    • for anything that’ll be exposed to the internet
    • limited internet access
    • cannot access other VLANs

I intend to run multiple Docker containers on my server myMainServer that is in the serve VLAN. Most of the containers are internal services like Samba, NZBGet, etc.

If I understand right, if I leave all the Docker network stuff as default, then:

  • all my containers on myMainServer will secretly also be in the serve VLAN since that is where myMainServer is

  • but none of the containers will actually get an IP on my router?

  • containers cannot talk to each other using localhost because, for containers, localhost does not actually mean myMainServer's localhost

  • container A on myMainServer will be able to talk to container B on myMainServer using http://[IP of myMainServer]:[host port of container B]

  • any devices on my trust VLAN will also be able to access container B from http://[IP of myMainServer]:[host port of container B]

Do I understand this right so far?

If so, if container A talks to container B then does the traffic stay on myMainServer or does it go through my router? I assume no?

Second, I know I can use macvlan to create VLAN networks for Docker. But are those VLANs self-contained on the host or can the match my home network’s setup? Can I somehow get it to create a network for my dmz VLAN? Meaning, I want container C to be on the dmz VLAN? If containers don’t actually get IPs from the router, then the container network will not really be on the dmz VLAN, right?

Meaning, if I wanted to open ports in my router and forward them to my container, I’d actually be forwarding them to myMainServer which is in the serve VLAN.

I guess I am trying to see if it even makes sense to have a dmz VLAN since the containers don’t get IPs on the router and the host handles all the traffic routing…

#2

The containers will use whatever interfaces are configured on the host. Docker’s bridge and overlay network will create a nat, thus the containter does not need to know anything about your VLANs.

True for bridged and overlay networks.
Not true for containers that are created with --network host,as the host may have already received it’s ip by dhcp.

yep, localhost inside a container is local to the container, not to the host. Unless '–network host` is used, which will put the container in the host network’s namespace (=network-wise behave like a native process)

That’s a possible sollution. Though, for container to container communication it is prefered to use user defined (docker) networks instead.

yep.

Will respond to the other questions sometime later.

1 Like
#3

Depends on the docker network type and wether you use a https fqdn that resolves to your wan ip or not (which could be tackled by a split-horizon dns).

If you create a macvlan that has an ip-range within your subnet, you can assign ips of this ip-range to your containers. A Macvlan network acts like a “network bridge” (in a way a physical switch works), its parent interface is the “uplink” to your physical network. Though: be aware that macvlan (container) child interfaces are not able to communicate directly with their parent interface (on the host) - this is a kernel securty feature, not a docker bug. Traffic to other devices in the network is not affected.

Usualy people trying to force vm behavior on containers tend to think macvlan is the solution - though, for most use cases it is not needed.

If you use a bridged (=for plain docker container) or overlay (=for docker swarm services) network and publish ports, you would foward the port to the docker host and the host side of the published port. This does not apply to container interfaces in (docker) macvlan networks, which would work like standalone devices with their own ip and mac address.

In none of the cases the containers will get dhcp ip’s from outside docker, not even with macvlan. Docker will act as dhcp in its networks, unless you specify fixed ips for your containers (which does not work for swarm services). Are you sure macvlan’s actualy are VLAN aware?

1 Like
#4

I don’t know. this is new to me. But your responses were very helpful.

From what I am reading, if I use macvlan, I can assign an IP to a container that matches the VLAN of my network and said IP/container will be accessible from other devices on my network.

#5

I never used macvlans with VLANs before, though the blog post https://hicu.be/docker-networking-macvlan-vlan-configuration indicates that the VLAN binding is done by the parent interface you use for a macvlan network. Seems feasabel to me.

Good luck!

#6

So I am confused then. What is the point of macvlan if you’re not using it with VLANs?

#7

To have container ips which are part of your home lan’s subnet?

I figured my use cases in my homelab do not necessarily require macvlan, so I stopped using it.

During the last 6 years in my job, I never needed macvlan at all, not even in the most complicated deployment scenarios.

1 Like
#8

Yeah. I am wondering if I actually need VLANs for what I am trying to do.

Since its a separate topic I posted another thread to see what folks thought: Is there any value in using VLANs to segment dmz vs non DMZ containers?.

Would love your input on that.