Exposing privileged ports on private network

Docker Engine Compose
1

Hi there,

I’m writing some code for dealing with DHCP leases and in order to test that, I would like to connect two docker containers on a private network that can communicate with each other on UDP ports 67 and 68.

So basically one container with DHCP client functionality and another container running a DHCP server daemon.

I have made it work by having a docker-compose.yml file containing (basically):

services:
  dhcpd:
    image: networkboot/dhcpd:latest
    container_name: dhcpd
    ports:
      - 67:67/udp
    networks:
      - privnet
  dhcp_client:
    build: dhcp_client
    container_name: dhcp_client
    ports:
      - 68:68/udp

networks:
  privnet:
    ipam:
      config:
        - subnet: 192.168.0.0/24

But that means that port 67 and 68 gets exposed on the host as well which I definitely do not want.

I have tried using expose to simply expose the ports as well as linking the containers, but then the containers are not able to communicate with each other through these ports.

I feel like there’s something very basic that I’m missing, or is it simply not possible to achieve what I want?

Thanks a lot.

Kind regards,

Kasper Laudrup

2

you don’t have to use the ports clause… the ports will still be open on the containers…

how are the containers communicating? DHCP use the mac address of the client. (cause it doesn’t have an ip address yet)

sadly the host doesn’t listen for the containers mac address on its network adapter, except in promiscuous mode.
(which you will never get to do in a production or hosted environment anywhere)

3

Hi sdetweil,

Thanks a lot for your input.

you don’t have to use the ports clause… the ports will still be open on the containers…

I’m not sure I understand what you mean. I have tried making some very simple tests using netcat, tcpdump etc. and it doesn’t seem like they are able to contact each other.

how are the containers communicating? DHCP use the mac address of the client. (cause it doesn’t have an ip address yet)

That is indeed an issue, but I have worked around that by writing some hackish code that fakes the MAC address. That part works just fine if I expose the ports on both containers.

Took me a while to figure out though :slight_smile:

sadly the host doesn’t listen for the containers mac address on its network adapter, except in promiscuous mode.
(which you will never get to do in a production or hosted environment anywhere)

Indeed, but that’s not really my problem. I guess we can boil it down to having two containers contacting each other on privileged ports in a private network.

I only mentioned DHCP to provide some context to what I’m trying to achieve.

Thanks a lot.

Cheers.

Kasper

4

if, for example, you start the http image, which exposes port 80,

docker run -name mytest -d httpd

then inspect the container to get its network address

docker inspect mytest

then use curl for example to call its port 80

curl http://172.17.0.3

you will get a response

<html><body><h1>It works!</h1></body></html>

even tho the port is not mapped to the host

5

Hi again,

Thank a lot for your answer.

I just made a simple test case similar to yours, and you are absolutely right, it does work exactly as expected.

Might have something to do with my use case which is a bit special, so there’s probably something else going on that I have to look into, but I don’t want to waste your time helping me with that :slight_smile:

I should have made that simple test myself before wasting other peoples time here, but thanks a lot.

Kind regards,

Kasper

6

I think it’s udp thru the bridge that is restricted.

7

Hi again,

It isn’t a problem with UDP being restricted, but your answer sent me in the right direction.

It seems like I need to add NET_BROADCAST privileges to the containers in order for broadcasting to work.

If I do a simple broadcast test with socat, then it works just fine with this privilege added.

My code doesn’t work though, but that’s not a docker related issue :slight_smile:

Thanks a lot for your help and kind regards.

Kasper