cirruslabs / tart

macOS and Linux VMs on Apple Silicon to use in CI and other automations
https://tart.run
Other
3.67k stars 103 forks source link

No internet connection in a fresh installation of Tart with Ubuntu #718

Closed andronat closed 5 months ago

andronat commented 5 months ago

Hello everyone! New here :D I just had chance to install Tart on my M1 with Macos Ventura 13.6 (22G120). I followed the commands from the quick-start guide for Ubuntu latest. The VM runs and I can SSH to it, but the Ubuntu guest doesn't have internet access:

admin@ubuntu:~$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
42 packets transmitted, 0 received, 100% packet loss, time 41970ms

From Macos ifconfig I can see the bridge:

bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
    options=63<RXCSUM,TXCSUM,TSO4,TSO6>
    ether be:d0:74:90:86:64
    inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255
    inet6 fe80::bcd0:74ff:fe90:8664%bridge100 prefixlen 64 scopeid 0x16
    inet6 fd84:d0eb:5505:fa25:14e4:bd45:7a3d:9c46 prefixlen 64 autoconf secured
    Configuration:
        id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
        maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
        root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
        ipfilter disabled flags 0x0
    member: vmenet0 flags=10803<LEARNING,DISCOVER,PRIVATE,CSUM>
            ifmaxaddr 0 port 21 priority 0 path cost 0
    member: vmenet1 flags=10803<LEARNING,DISCOVER,PRIVATE,CSUM>
            ifmaxaddr 0 port 32 priority 0 path cost 0
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active

And from Ubuntu I can see it connected with a proper IP address through ip address:

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
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 5e:a4:f4:13:14:f3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.64.6/24 metric 100 brd 192.168.64.255 scope global dynamic enp0s1
       valid_lft 83826sec preferred_lft 83826sec
    inet6 fd84:d0eb:5505:fa25:5ca4:f4ff:fe13:14f3/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591924sec preferred_lft 604724sec
    inet6 fe80::5ca4:f4ff:fe13:14f3/64 scope link
       valid_lft forever preferred_lft forever

IP routing in the Linux VM also seems right (ip route show default):

default via 192.168.64.1 dev enp0s1 proto dhcp src 192.168.64.6 metric 100

I saw some GH issues using the following command on Macos, I don't know how relevant it is:

% sudo pfctl -s nat -a "com.apple.internet-sharing/shared_v4"
Password:
No ALTQ support in kernel
ALTQ related functions disabled
nat on en8 inet from 192.168.64.0/24 to any -> (en8:0) extfilter ei
nat on en0 inet from 192.168.64.0/24 to any -> (en0:0) extfilter ei
no nat on bridge100 inet from 192.168.64.1 to 192.168.64.0/24

I can ping my Macos from the VM:

$ ping 192.168.64.1
PING 192.168.64.1 (192.168.64.1) 56(84) bytes of data.
64 bytes from 192.168.64.1: icmp_seq=1 ttl=64 time=0.310 ms
64 bytes from 192.168.64.1: icmp_seq=2 ttl=64 time=0.535 ms

I'm not sure what's the issue. Is this expected behavior for Linux VMs?

PS: I don't know how relevant it is for interference, but I also have Docker Desktop installed and running at the same time.

edigaryev commented 5 months ago

Hello Anastasios 👋

Do you have System SettingsNetworkFirewallOptionsEnable stealth mode enabled by a chance?

If so, that's what might be causing the issue.

Non-ICMP traffic should work just fine, for example:

sudo apt-get update
andronat commented 5 months ago

JFYI the problem is the default bridge100 that is not connected to any of the en* interfaces. Notice the member fields in the bridge above. I used tart run --net-bridged=en0 and I can now see a new bridge is created:

bridge101: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=63<RXCSUM,TXCSUM,TSO4,TSO6>
    ether be:d0:74:90:86:65
    Configuration:
        id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
        maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
        root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
        ipfilter disabled flags 0x0
    member: en0 flags=8003<LEARNING,DISCOVER,MACNAT>
            ifmaxaddr 0 port 15 priority 0 path cost 0
    member: vmenet1 flags=10003<LEARNING,DISCOVER,CSUM>
            ifmaxaddr 0 port 32 priority 0 path cost 0
    media: autoselect
    status: active

This one has en0 as its member and indeed internet is working now.

So I do suspect that maybe some better checks are required on Tart's default bridge connections? Maybe we should be checking for if interfaces like en* are connected to the default bridge? 🤷‍♂️

edigaryev commented 5 months ago

I used tart run --net-bridged=en0 and I can now see a new bridge is created:

Wait, but what command did you used before?

Is the issue still reproducible for you?

andronat commented 5 months ago

I used the default command from the quick start guide that doesn't specify a net bridge. And it automatically picks bridge100 as described above.

Yea the issue is reproducible on my machine.

edigaryev commented 5 months ago

And it automatically picks bridge100 as described above.

That seems to be working as intended.

Also note that this bridge should not have a Ethernet nor Wi-Fi interface added to it because the routing is achieved at the networking level and addresses are automatically translated using NAT.

Could you please give https://github.com/cirruslabs/tart/issues/718#issuecomment-1907799247 a look?

andronat commented 5 months ago

I confirm I had 0 connectivity. No non-icmp can go through.

fkorotkov commented 5 months ago

Do you have any VPN or other software that can interfere with host network setup?