Port forwarding does not work when the bridged interface is not the first one on a device (MacOS, Windows)

[tcaiazzi]

trafficstars

The current implementation of port forwarding in Kathará encounters an issue when the bridged interface is not the first one on a device. This error is related to a Docker Desktop issue (docker/for-mac#6978) that affects port forwarding functionality.

To address this issue, while waiting for an official Docker fix, we propose a possible workaround that involves starting the device with only the bridged interface initially and then dynamically connecting other interfaces using the vconfig/lconfig command.

In the following you can find a quick example, which starts a device with the apache2 service exposed on port 8080 of the host:

kathara vstart -n pc1 --bridged --port 8080:80 --image kathara/base --exec "/etc/init.d/apache2 start"

Now, you can attach a new interface using the vconfig command:

 kathara vconfig -n pc1 --add A

In this way, the port forwarding works and you can attach other interfaces to the device.

[marcelofernandez]

Hi! I'm testing this workaround with the latest versions of Kathara/Docker Desktop on Mac OS and it seems it isn't working, could it be?

My lab's code is here: https://github.com/redesunlu/kathara-labs/tree/adding_browser_http3_lab/kathara-lab_http3

Thank you!

[tcaiazzi]

Hi @marcelofernandez!

As you did in the screen, you need to use the lconfig command to configure a device in a network scenario.

The vconfig command is needed to add/remove interfaces to devices ran using the vstart command, probably my answer above is a bit ambiguous.

Just to be sure, is the lconfig commands in you example working? Is the problem only in the vstart command?

[marcelofernandez]

Hi!

Sorry, I only posted the screenshot and I didn't explain the situation a little bit more (and I haven't pushed the changes in the lab's branch, now I did).

But this time I played around this a little bit more and what I didn't understand (until now) was that the katara lconfig -n <container> --add A actually adds a new interface to the container "plugged" to the A network, so in order to use it I had to configure it first (assigning a new IP address within that A network, for example).

Sorry for the mistake. Now I know how to configure my lab, until the underlying bug gets fixed.

Thank you!