Go to System Settings -> Privacy & Security -> Local Network and make sure the relevant Docker application has local network access enabled. Although Colima may not be on the list, Docker's settings may affect it. In addition, you can actually use servbay to replace docker, which is easier to use on mac than tools such as docker and mamp

Local Network is enabled for Docker. I need to reach a server on our local network and I need to stick to a container based approach.

check : #711 and make sure you can reach it. It may be a resolution issue.

I met the similar problem. I couldn't push docker image to a registry in a local network by IP address. The workaround for me is setting network.address to true in ~/.colima/default/colima.yaml

# Network configurations for the virtual machine.
network:
  # Assign reachable IP address to the virtual machine.
  # NOTE: this is currently macOS only and ignored on Linux.
  # Default: false
  address: true

Apple Silicon (M1): Sequoia 15.1

$ docker login my.private.registry
Authenticating with existing credentials...
Login did not succeed, error: Error response from daemon: Get "https://my.private.registry/v2/": net/http: TLS handshake timeout
Username (mread): ^C
$ docker login my.private.registry
Authenticating with existing credentials...
Login did not succeed, error: Error response from daemon: Get "https://my.private.registry/v2/": context deadline exceeded
Username (mread): ^C
$ docker login my.private.registry
Authenticating with existing credentials...
Login did not succeed, error: Error response from daemon: Get "https://my.private.registry/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Username (mread): ^C

I see the above various timeouts connecting to a private Artifactory instance over VPN, on Mac OS 15.1. There were no issues prior to the Sequioa upgrade. network.address: true and network.dns: [ <my internal DNS> ] unfortunately don't improve anything. Using Docker Desktop instead of Colima does work, so my Artifactory instance and other networking are fine.

And unlike the OP, Colima does appear in my System Settings → Privacy & Security → Local Network, and I have given it access. I also added & enabled it under Developer Tools (which seemed to be required for Docker Desktop, FWIW) and Full Disk Access to no effect. A complete reinstall of Colima including the removal of ~/.colima/ also made no difference.

 $ colima version && limactl --version && qemu-img --version
colima version 0.8.0
git commit: 9c08cff339f087c0600d9d56af7b5fbcfe02e287

runtime: docker
arch: aarch64
client: v27.3.1
server: v27.3.1
limactl version 1.0.1
qemu-img version 9.1.1
Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers

$ colima status
INFO[0000] colima is running using QEMU                 
INFO[0000] arch: aarch64                                
INFO[0000] runtime: docker                              
INFO[0000] mountType: sshfs                             
INFO[0000] address: 192.168.106.6                       
INFO[0000] socket: unix:///Users/mread/.colima/default/docker.sock 

I have a similar issue after upgrading to Sequoia 15.1. Pulling images from a registry behind a VPN does not work anymore with colima flag --network-address.

Error message is similar to the previous poster, e.g. net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).

However, if network-address flag is not set, pulling works fine.

Reinstalling colima, using dev version, deleting profiles and colima/lima related files did not help.
For me, colima does not apppear under System Settings → Privacy & Security → Local Network.

$ colima status -p k8s
INFO[0000] colima [profile=k8s] is running using QEMU
INFO[0000] arch: x86_64
INFO[0000] runtime: docker
INFO[0000] mountType: sshfs
INFO[0000] address: 192.168.XXX.XX
INFO[0000] socket: unix:///Users/xxx/.colima/k8s/docker.sock
INFO[0001] kubernetes: enabled

$ colima version && limactl --version && qemu-img --version
colima version HEAD-38c20fc
git commit: 38c20fc1ee04d6202375fa66cb3c3e46571c413a
limactl version 1.0.1
qemu-img version 9.1.1
Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers

Operating System is 15.1 (24B83) on Intel Mac.

However, if network-address flag is not set, pulling works fine.

Can you share the output of colima ssh -- ip route after starting Colima with network address enabled?

You should get something like the following

default via 192.168.106.1 dev col0 proto dhcp src 192.168.106.2 metric 100
default via 192.168.5.2 dev eth0 proto dhcp src 192.168.5.1 metric 200
...

What happens if you delete the entry for the network address?

colima ssh -- sudo ip route del default via 192.168.106.1

Can you share the output of colima ssh -- ip route
after starting Colima with network address enabled?

default via 192.168.106.1 dev col0 proto dhcp src 192.168.106.24 metric 100
default via 192.168.5.2 dev eth0 proto dhcp src 192.168.5.6 metric 200
10.42.0.0/24 dev cni0 proto kernel scope link src 10.42.0.1
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.5.0/24 dev eth0 proto kernel scope link src 192.168.5.6 metric 200
192.168.5.2 dev eth0 proto dhcp scope link src 192.168.5.6 metric 200
192.168.106.0/24 dev col0 proto kernel scope link src 192.168.106.24 metric 100
192.168.106.1 dev col0 proto dhcp scope link src 192.168.106.24 metric 100

What happens if you delete the entry for the network address?
colima ssh -- sudo ip route del default via 192.168.106.1

This fixes the issue as a workaround - I can still reach colima from my host with network-address and pulling images in colima from the Registry behind VPN works.

@f-helm if that indeed resolves it, then an update can be pushed to enforce the behaviour.

I would wait for confirmation from others as well.

above workaround works for me as well

I had the same issue, the workaround above also fixes it for me

I think we've got enough confirmations, would go ahead with the fix.