wsl: user-mode networking

[lstocchi]

On hyperv we're adding support for user-mode networking through cfergeau/podman#31 and #247 .
However we cannot give the option to enable usermode on WSL atm as this works using an extra VM (podman-net-usermode) and we need to refactor it.

Gerard pointed to wsl-vpnkit to solve it

why not? https://github.com/sakai135/wsl-vpnkit. We worked with @sakai135, to simplify his work as it addresses the same problem we solve: connectivity issues when using a VPN.

Originally posted by @gbraad in #247 (comment)

[lstocchi]

Podman to handle user-mode creates a dedicated distro to support it (which changes the default route, updates resolv.conf, run gvforwarder ...). This new setup is then inherited by all WSL instances.

So if a user runs a podman-machine with user-mode-networking flag, the podman-usermode machine is created and launched.

Now if we use a similar approach on macadam with wsl-vpnkit we could fall in some sort of conflict, no?

The new mirrored networking strategy solves the old issues with VPNs, so would it be enough to check if the user enabled it for user-mode networking with macadam? Why would wsl-vpnkit be better? Are there companies that do not allow to update wsl.config to devs and they are forced to nat? @gbraad

[lstocchi]

I've been playing with the mirrored mode for a while and i did not face any strong blocker. I tried to run podman inside a wsl VM with all different network options, a sample website pointing to an external db and services, using WSL for coding remotely, with/without vpn and it behaved correctly.

The only issue found related to it was the incompatibility with the macvlan network driver that can be used with docker/podman.

Macvlan is built to assign a different MAC address to each container and because mirrored mode is built so that the VM shares the same IP/mac with the host, the WSL Hyper-v virtual switch sees this different MAC, flags all packets as a potential "MAC Address Spoofing" attempt, and drops them.

Another thing to mention is its limitation that users need to be on windows 11 (22H2+).

---

As the current podman usermode implementation was made to bypass VPN issues and this is also one of the reason why mirrored mode was released, we could remove from our shoulders the burden to implement it ourselves, suggest people to switch to mirrored if facing connectivity problems and only get back to this if some customer has a specific use-case to handle. (??)

However, even with mirrored mode, we have a kind-of conflict "issue" with podman.

Podman is still able to update the routing table and add the gvforwarder address as first option, even if the networking stack is mirrored from the host.

E.g.

default via 192.168.127.1 dev podman-usermode
default via 192.168.1.254 dev eth5 proto kernel metric 25
169.254.0.0/16 dev eth4 proto kernel scope link metric 271
169.254.0.0/16 dev eth2 proto kernel scope link metric 271
169.254.0.0/16 dev eth0 proto kernel scope link metric 271
192.168.1.0/24 dev eth5 proto kernel scope link metric 281
192.168.1.254 dev eth5 proto kernel scope link metric 25
192.168.100.0/24 dev eth3 proto kernel scope link metric 271
192.168.127.0/24 dev podman-usermode proto kernel scope link src 192.168.127.2

So the traffic will still flow through gvforwarder/gvproxy if the user has an active podman-machine running on WSL. This could be transparent to the user if everything works, but this could be a problem and hard to detect if sometimes it works, and sometimes it doesn't.

The only other option would be to have a similar mechanism as podman and then handle the case when both podman/macadam have usermode machines running. Either we upgrade the logic in podman to also handle macadam VMs (and share with them the podman-user-mode machine), or we rely on mirrored mode.

Every other solution would mean to add another route entry and increase the chance to face some conflict.

Any other idea/comment on this? @gbraad @cfergeau