chipmk
Docker Desktop host networking conflicts with docker-mac-net-connect and causes login to fail
Docker Desktop 4.34.0 (release notes) comes with host networking support. This conflicts with docker-mac-net-connect.
The problem digests as docker login failing. In the Docker Desktop UI, there's a popup visible for a few seconds where there's an error message about a port conflict.
Port Conflict Host Networking: Failed to bind port 61236 on the host. Check if it is already in use
(the port number changes each time)
The problem was resolved by running sudo brew services stop chipmk/tap/docker-mac-net-connect since I had enabled the service when I installed docker-mac-net-connect.
As a resolution to this issue, I guess it would be sufficient to mention this in the documentation of docker-mac-net-connect.
Does that mean you don't have to use docker-mac-net-connect to expose the containers' IPs to the host?
Does that mean you don't have to use docker-mac-net-connect to expose the containers' IPs to the host?
@kmahelona Do I have to use it? If I'd like to be able to access the container IPs, it would continue to be useful. The reported problem here is that docker-mac-net-connect conflicts with Docker Desktop's host network feature and it's hard to find out the reason.
It took me by surprise as well, and it took some time to find what is the problem.
I managed to get it into the working state, running docker login from the terminal successfully logs the docker desktop back.
Everything seems to continue working fine. Running docker mac connect from terminal shows no errors
DEBUG: (utun0) 2025/05/14 17:32:18 Setting up Wireguard on Docker Desktop VM
Creating WireGuard interface chip0
Assigning IP to WireGuard interface
Configuring WireGuard device
DEBUG: (utun0) 2025/05/14 17:32:18 peer(Scep…yPTY) - Received handshake initiation
DEBUG: (utun0) 2025/05/14 17:32:18 peer(Scep…yPTY) - Sending handshake response
DEBUG: (utun0) 2025/05/14 17:32:18 peer(Scep…yPTY) - Receiving keepalive packet
Adding iptables NAT rule for host WireGuard IP
Setup container complete
Adding route for 172.42.0.0/16 -> utun0 (minikube)
Adding route for 172.17.0.0/16 -> utun0 (bridge)
DEBUG: (utun0) 2025/05/14 17:32:18 Watching Docker events
DEBUG: (utun0) 2025/05/14 17:32:43 peer(Scep…yPTY) - Receiving keepalive packet
DEBUG: (utun0) 2025/05/14 17:33:08 peer(Scep…yPTY) - Receiving keepalive packet
and nginx example seems to work fine.
Hopefully it shouldn't be too difficult to fix properly in this scenario... Though there may be more happening under the hood that I am not aware about.
Thanks for reporting @lhotari and the follow up @RafalSkolasinski. To help me reproduce this, can you confirm these are the steps to produce the port conflict error?
- You enable host networking via Settings > Resources > Network > Enable host networking
- You are running
docker-mac-net-connect - You attempt to login to Docker via
docker login - Port conflict error message appears
Update: I reproduced the port conflict error popup by simply enabling host networking mode and waiting a few seconds. For me though, the L3 docker-mac-net-connect tunnel continued to work and docker login succeeded. I tried doing this is both orders too:
- Start
docker-mac-net-connect, then enable host networking - Enable host networking, then start
docker-mac-net-connect
Both produced the port conflict error, but neither caused any tunnel or docker login issues. If there is an extra step I'm missing please let me know.
If the problem is simply the warning, this is probably less critical than I first thought, though we should still try to find a way to prevent this. I'm suspicious it has to do with the WireGuard client running in the VM (as a kernel module) binding to a local UDP port when sending outbound UDP packets to the macOS host. My understanding is that Docker for Mac's host networking solution does some sort of port mapping/mirroring between the VM and the macOS host, so it tries to bind the same UDP port on the macOS host itself. This is not really what we want, but shouldn't really cause problems if it did. Clearly though the mapped binding fails though according to that popup, and I'm not 100% sure why.
Hi @gregnr, for me it was the 1. Start docker-mac-net-connect, then enable host networking that did it, where enabling host networking was restarting docker desktop.
I would say that running docker login is just a workaround and the problem being that docker desktop logged out and the "Sign in" feature through the UI was completely broken.
I am also observing recently that some containers through started are not appearing in docker ps and docker desktop but I cannot say that this is related here...
Thanks for the details. What broke with the UI sign in? I tried reproducing by:
- Start
docker-mac-net-connect - Enable host networking
- Click "Sign in" at top right in Docker Desktop UI
After redirecting to the browser and signing in, I was taken back to the desktop UI which had logged in successfully.
Yes, that looks about right. Starting from DD logged 1 -> 2 -> 3 should reproduce it.
With 2. Enable host networking causing the log out + warning about the port conflict.
Then 3. Click "Sign in" at top right in Docker Desktop UI takes me to the browser, then back to desktop UI but nothing is happening.
To confirm, on 3 after you are redirected back, Docker Desktop remains logged out for you instead of logged in? When I ran the above steps I logged in successfully. I'm not sure I understand what the problem is.
Yes, it does stay logged out until I do docker login from the terminal. I am surprised it is not happening for you.
I reproduced it on two independent machines. It also happens later on if with both enabled I just restart docker desktop.
It is very consistent with having both host networking and docker-mac-net-connect on at the same time.
Versions:
-
docker-mac-net-connect: v0.1.4 - Docker Desktop: 4.41.2 (191736)