0

Update

I try the same setup using Ubuntu as host. It works! And I notice the interface info (ip a) in host and container are the same in Ubuntu docker. But are different when using docker windows desktop.

So, the question becomes, why windows docker desktop give different network interface between host and container when using --net=host?

Original question

I open a container with --net=host. I want to connect to a device, which on the same subnet of my host, from inside the container. Also, the container has a server running on port 3000.

  • Host (192.168.64.101/18)
  • Device (192.168.64.102/18)
  • Container (--net=host, server on port 3000)
  1. Container can connect to device with 192.168.64.102.
  2. Container can ping the host with 192.168.64.101

But I cannot access container's server on port 3000 from host. I try curl localhost:3000 the connection refuse.

I thought --net=host will treat container as same network as host. Why can't I connect to the container's server using localhost?


ip a from container

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
4: services1@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether a2:41:c9:a1:cd:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.65.4 peer 192.168.65.5/32 scope global services1
       valid_lft forever preferred_lft forever
    inet6 fe80::a041:c9ff:fea1:cd4e/64 scope link
       valid_lft forever preferred_lft forever
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 1000
    link/ether 02:50:00:00:00:01 brd ff:ff:ff:ff:ff:ff
    inet 192.168.65.3/24 brd 192.168.65.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::50:ff:fe00:1/64 scope link
       valid_lft forever preferred_lft forever
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:fb:e9:2d:76 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:fbff:fee9:2d76/64 scope link
       valid_lft forever preferred_lft forever
11: vethfd2c43f@if10: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether d6:ee:fe:80:24:04 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::d4ee:feff:fe80:2404/64 scope link
       valid_lft forever preferred_lft forever
Josh Chiu
  • 832
  • 2
  • 7
  • 14
  • What if you do a curl on `127.0.0.1` rather than `localhost`: `curl 127.0.0.1:3000` ? – Martin Tovmassian May 31 '22 at 08:37
  • connection refused, either. – Josh Chiu May 31 '22 at 08:49
  • Is it the explanation: [The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server](https://docs.docker.com/network/network-tutorial-host/#prerequisites)? – Martin Tovmassian May 31 '22 at 09:02
  • Another related question is [windows run docker with --network=host and access with 127.0.0.1](https://stackoverflow.com/questions/48915458/windows-run-docker-with-network-host-and-access-with-127-0-0-1). You are likely getting the "host network" of a hidden Linux VM. Host networking is rarely necessary, though,; does your setup work if you just remove that option? – David Maze May 31 '22 at 09:55
  • Thanks to Martin and David. I can access the same subnet without using --net=host. – Josh Chiu Jun 01 '22 at 01:38

0 Answers0