Custom bridge network container connectivity

[xiphoid24]

I am new to Rancher Desktop and I am researching it for my company to see if it is a suitable replacement for Docker Desktop. We currently use docker compose on Windows to run an application being developed and any resources that application might need. We create a bridge network in the compose and all of the containers use it to communicate.

When I start my containers through docker compose using Rancher, the containers are not able to connect to each other. I have attached to a shell for a given container and pinged the IP of another container and there is no response. If I connect the containers to the default bridge network I can then ping the other container using the IP of the other container on the default bridge network.

I am using Rancher Desktop 1.9. I then enabled the experimental Network Tunnel setting and I am able to get the containers to communicate through the custom bridge network but I am running into this bug.

Does the experimental Network Tunnel setting need to be enabled in order for the containers to connect to each other on a custom bridge network or is there some other setting I am missing?

I also have my own separate WSL 2 Ubuntu installation. I installed docker directly in that and shutdown Rancher. I then started ran docker compose from that WSL 2 instance and I have no issue with the containers connecting to each other. This makes me think it is something with Rancher specifically and not WSL 2.

Update:
After doing some more testing it seems this is not isolated to container to container communication. from inside the container I am unable to ping Google's public dns ping 8.8.8.8

[mook-as]

Hmm, I can't think of anything that should affect container-to-container networking with the network tunnel configuration (that is, I don't see off the top of my head how that would fix things).

Would you be able to point us at an example compose file that would demonstrate the issue (to ensure that we're correctly reproducing it, and not being tripped up by something different)? I could not reproduce this with a simplified test case:

• Rancher Desktop 1.9.0, Windows (installed for all users), using the moby backend, Kubernetes disabled, network tunnel disabled.

• Create compose.yaml with the following contents:

  services:
    web:
      image: nginx:stable
      networks: [ foo ]
    exec:
      image: busybox
      command: [ /bin/sh, -c, 'sleep inf' ]
      networks: [ foo ]
  networks:
    foo:
  

• Run docker compose up

• In a separate terminate (because the first is still stuck), run docker exec -t -i <name of the exec container> /bin/sh

• Inside that, run wget -O - http://web

• Also check that doing wget -O - http://web from a container created by docker run --rm -t -i busybox does not work (because it's not in the same network).

Please be aware that I'm not sure whether ping is working correctly yet…

[gpechiro]

@mook-as Thank you for you response. I followed your step exactly and I am still having the same issue. The wget -O - http://web hung and never returned anything.

I shut down the containers and enabled the experimental network tunneling. Restarted the containers by following all of the steps you provided and it worked without issue.

I then shut rancher down and started my separate WSL 2 Ubuntu. I started the same docker compose from there and I had no issue with the wget command.

Since originally posting this question I have tried a Factory Reset on Rancher and fully uninstalled it, then reinstalled it with no change.

[gpechiro]

After looking into this further, this seems to be an issue specific to my setup. I worked with a few other developers on the team and no one else is experiencing this issue. I am not sure what the root cause is but it does not seem to be Rancher. This can be closed. If I find any resolution I will post it here incase others have a similar problem.

[mook-as]

Do you have any interesting networking setups, like wsl-vpnkit? It could be that the network tunnel mode works because we set up a network namespace there (to isolate ourselves from the rest of WSL).

[gpechiro]

I don't think so. There is a company VPN I am on but Docker desktop worked previously and docker directly through a different WSL 2 instance works fine. The other developers are also connecting through the company VPN. I am going to try fully removing / resetting WSL 2 at some point