No IP address on bridged mode

[watadarkstar]

Description

I’m trying to use Colima with bridged networking on macOS so that services running inside the VM/container can be reached from another device on my LAN, specifically Expo/Metro from a phone.

Colima starts successfully with bridged networking enabled, but colima list does not show an address. Inside the VM, col0 receives global IPv6 addresses from my LAN, but it does not receive an IPv4 DHCP lease.

Not using bridged gets an IP address, but I need a bridged connection since I have a VPN and need to bypass the VPN and connect directly to the router / network via a bridged connection.

Version

colima version 0.10.3
git commit: 00f6c297e92a82c04a4ab507db0a61435650d7e8
limactl version 2.1.2
qemu-img version 2.12.0(v2.12.0-19097-g85fa07f04ef)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

Operating System

• macOS Intel <= 13 (Ventura)
• macOS Intel >= 14 (Sonoma)
• Apple Silicon <= 13 (Ventura)
• Apple Silicon >= 14 (Sonoma)
• Linux

Output of colima status

colima status
INFO[0000] colima is running using macOS Virtualization.Framework 
INFO[0000] arch: aarch64                                
INFO[0000] runtime: docker                              
INFO[0000] mountType: virtiofs                          
INFO[0000] docker socket: unix:///Users/adrian.carolli/.colima/default/docker.sock 
INFO[0000] containerd socket: unix:///Users/adrian.carolli/.colima/default/containerd.sock 

Reproduction Steps

Run:

colima stop; colima delete; colima prune

Then I ran it with this command:

colima start --network-address --network-mode bridged --save-config

colima list shows an empty ADDRESS column:

PROFILE       STATUS     ARCH       CPUS    MEMORY    DISK      RUNTIME    ADDRESS
default       Running    aarch64    2       2GiB      100GiB    docker     

Expected behaviour

With:

network:
  address: true
  mode: bridged
  interface: en0

I expected col0 to receive an IPv4 address from my LAN DHCP server, e.g.:

inet 10.0.0.x/24

and for colima list to show that address in the ADDRESS column.

Additional context

The host Mac’s active interface is en0 with IPv4 address:

en0: 10.0.0.138/24

The Colima VM does appear to be bridged for IPv6, because col0 receives global IPv6 addresses from the same LAN prefix. The failure seems specific to IPv4 DHCP.

I also confirmed that a service inside the VM can listen on both IPv4 and IPv6:

LISTEN 0 4096 0.0.0.0:8081 0.0.0.0:*
LISTEN 0 4096 [::]:8081    [::]:*

colima ssh ip addr output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:55:55:4d:75:44 brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.3/24 metric 200 brd 192.168.5.255 scope global dynamic eth0
       valid_lft 3301sec preferred_lft 3301sec
    inet6 fe80::5055:55ff:fe4d:7544/64 scope link 
       valid_lft forever preferred_lft forever
3: col0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:55:55:11:a3:06 brd ff:ff:ff:ff:ff:ff
    inet6 2607:fea8:349b:4f00::66b6/128 scope global dynamic noprefixroute 
       valid_lft 533960sec preferred_lft 101960sec
    inet6 2607:fea8:349b:4f00:5055:55ff:fe11:a306/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 534253sec preferred_lft 102253sec
    inet6 fe80::5055:55ff:fe11:a306/64 scope link 
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 46:86:a4:8e:ec:d6 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

On my local machine:

ifconfig en0 | grep "inet "
	inet 10.0.0.138 netmask 0xffffff00 broadcast 10.0.0.255