Expose VM & container port only on host loopback/127.0.0.1

[zcutlip]

I'm running Colima on macOS. I have a docker container I'm running with -p "127.0.0.1:25:25". But on my host I see the vm listening on *:25 rather than 127.0.0.1:25.

I tried setting hostAddresses: true in the Colima config. The description sounds like what this option is for, but it didn't change anything.

Am I missing something?

[abiosoft]

Can you share the output of docker ps?

[zcutlip]

sure, here you go:

CONTAINER ID   IMAGE                      COMMAND     CREATED        STATUS        PORTS                  NAMES
cfea06890457   juanluisbaptiste/postfix   "/run.sh"   21 hours ago   Up 21 hours   127.0.0.1:25->25/tcp   postfix

[zcutlip]

here's lsof showing limactl listing on all interfaces on port 25:

❱ sudo lsof -iTCP:25 -sTCP:LISTEN -n -P
Password:
COMMAND   PID       USER   FD   TYPE            DEVICE SIZE/OFF NODE NAME
limactl 47925 zach-admin   13u  IPv6 0x1edbc24e55a8116      0t0  TCP *:25 (LISTEN)

And here's an nmap scan of that host showing port 25 open externally:

❱ nmap -n -p25 exegol
Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-27 09:05 PST
Nmap scan report for exegol (10.0.1.4)
Host is up (0.010s latency).

PORT   STATE SERVICE
25/tcp open  smtp

Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

[msimkunas]

Out of curiosity: what is exegol in your case? Is it the same host you're running nmap on?

If your macOS firewall is up, nmap shouldn't show any open ports.

[zcutlip]

no, separate machine. When I run nmap as above for the first time, the firewall does prompt for limactl to accept connections. But the port is still reported open. I hadn't noticed this before because I wasn't physically logged in. I'm assuming this happens because nmap doesn't attempt to complete the TCP connection, and that once it gets a response on port 25, it considers the port open.

[msimkunas]

Oh, okay.

I use the Block all incoming connections toggle in firewall settings. I haven't tried port scanning with nmap but I assume that enabling this toggle should result in radio silence.

And if it's disabled, my assumption is that even though nmap reports the port as open, the port should reject packets that don't have loopback as their source address. I'll have to try this myself.

[zcutlip]

Hi, I just wondered if there's any advice here? Is this a known issue or a configuration mistake on my end?

I have containers that I need to not be exposed to the local network and only available on the host. I suspect others have similar needs.

Thanks!

[soemiran]

Seems like it applies only for ports under 1024

[msimkunas]

@zcutlip This surprising behavior is due to how privileged port (i.e. ports lower than 1024) forwarding is handled in Lima. Listening on 127.0.0.1:25 requires root privileges on macOS whereas 0.0.0.0:25 does not. See here for more details.

The way I understand it is that Lima (which Colima is based on) accepts connections on 0.0.0.0:25 in your case and rejects connections whose source IP does not match the loopback address.

Personally, I also enable the macOS firewall and block all incoming connections for an additional layer of protection but if my understanding is correct, Lima already rejects non-loopback connections when forwarding privileged ports.

[zcutlip]

@msimkunas ahhh....interesting. Okay, so I admit I only checked externally with nmap. So I tried with nc, and the macOS firewall immediately prompted me whether lima should accept connections. I said "yes" to see how far I could get. When I did this, and re-ran nc alongside tcpdump in another terminal session (this is all from my laptop over the LAN), I saw nc send the HELO to port 25, but then the TCP reset come back.

I do think at the very least colima's documentation should reflect this.

[msimkunas]

I think this should be documented in Lima's documentation because it's not a Colima-specific behavior. You could raise an issue on Lima's Github repository.

[zcutlip]

Yes! It absolutely should be documented in the Lima project if it isn't already.

Regarding Colima, my thinking is that a user of Colima shouldn't have to dive into Lima's documentation to understand its idiosynchrosies. This is the technology Colima has built on (by choice or otherwise), and Colima serves as an abstraction of that technology. If there are underlying idiosyncrasies that result in Colima having unexpexted behaviors, Colima's documentation should reflect that so users don't spend undue effort trying to fix or troubleshoot, thinking perhaps they've misconfigured or otherwise misused Colima.

I agree with your earlier characterization of "This surprising behavior." I believe this violates the Principle of Lease Surprise. Though it may be something Colima can't correct for, the documentation can at least prepare the user to not be caught off guard.

At any rate, thank you for chiming in with clarification. This has been super helpful on what I'd more or less considered a dead issue.