3
1
Crossposting here since this question was marked as off-topic on SO.
I've seen a handful of questions about attaching Docker containers to a physical network using macvlan, but have yet to find an answer for my current scenario.
What I am trying to accomplish:
- Run Docker containers inside of a VirtualBox VM running Ubuntu.
- Using macvlan, connect the containers to the same docker network and assign each an IP address within my physical network's subnet.
- Access each container via this assigned IP address from the host or any other device connected to the network.
So far, I have done the following:
- Created my VM using Vagrant.
- Added my Wi-Fi interface as a bridged adapter to the VM.
- Set the associated default gateway for the VM as described here to my router's IP (192.168.1.1).
- Create the Docker network with the following command:
docker network create -d macvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 --ip-range=192.168.1.160/27 -o parent=eth1 test_net
- Run my containers, attaching them to the network described above.
I can verify that both containers are up and are assigned 192.168.1.160 and 192.168.1.161. Obviously, because of the way macvlan works, these addresses aren't reachable within the VM.
But, when I try to ping either of these addresses from my host machine, the request times out. However, after I have tried to ping these addresses, when I run a arp -a on the host, I can see entries for both containers:
? (192.168.1.160) at 2:42:c0:a8:1:a0 on en0 ifscope [ethernet]
? (192.168.1.161) at 2:42:c0:a8:1:a1 on en0 ifscope [ethernet]
I have checked to make sure my router's firewall was disabled, the IP addresses above do not conflict with any other devices on my network, that I can ping my VM from my host, and that the default gateway of my VM is correctly set to 192.168.1.1 on the eth1 interface. Additionally, I checked that the subnet in the docker network create command matches my router's configured subnet.
I have seen solutions that leverage Docker's -p
flag, but that is not an option for me as I need to be able to refer to each container by its IP address alone.
Has anyone had any success in accomplishing what I am trying to do? Additionally, why would both containers have ARP entries but not be accessible, and what could I do to rectify that? Or, is there something relevant to how VirtualBox handles bridged adapters?
I thought that I should edit iptables
on the VM to set the default FORWARD
policy to ACCEPT
, but that didn't work either. Because it seems like ARP works, I'm guessing that packets are just being dropped by the VM before they can return to the host, but I'm not sure what to change to fix that.
Something is strange here. You said you want to use the physical network interface of the host, so Virtualbox should use the physical adapter ("Bridged Networking" in Virtualbox), and the macvlans in turn should use this adapter, too. If that works, you don't need iptables. If you forward/NAT in the VM, you don't need macvlans/bridged networking. So what you describe doesn't add up. And I'm unsure if the double "just use the physical device" can work at all. What is the outer host OS? Also Ubuntu? – dirkt – 2018-07-25T18:05:39.293
I was thinking it's strange too, so perhaps something else is at play. I've seen this working "out of the box" in VMWare like you describe (macvlan just using the physical adapter), but I am bound to using VirtualBox. I would definitely prefer to not use iptables, so any suggestions are appreciated. That said, I'm not sure if I understand why I wouldn't need to use macvlan/bridged networking, as I want the containers to appear as if they are on the physical network. And my host OS is macOS 10.13.6. – atomborn – 2018-07-25T18:37:54.560
1Alright, after some further testing, it seems that dirkt is correct that iptables is not necessary. I was attempting a shotgun approach in finding a solution, and in doing so failed to single out the true fix. Essentially, making sure that the interface is set to promiscuous mode is the key here. I have updated my answer above to reflect this. – atomborn – 2018-07-25T19:17:39.587