Unable to connect to instance on MacOS 15.1 (no route to host)

[mavwolverine]

Describe the bug
Describe what your problem is.
I am unable to shell to any running instance.

To Reproduce
How, and what happened?
Installed Multipass using the pkg installer.
Launched a new instance multipass launch
Confirm instance with multipass list
Try to shell multipass shell neutral-sailfish

Expected behavior
What did you expect to happen?

Logs
Please provide logs from the daemon, see accessing logs on where to find them on your platform.

Additional info

• OS: [e.g. macOS 10.15]
  MacOS 10.15.1
• multipass version
  multipass 1.14.1+mac
  multipassd 1.14.1+mac
• multipass info
  Name: neutral-sailfish
  State: Running
  Snapshots: 0
  IPv4: 192.168.64.6
  Release: Ubuntu 24.04.1 LTS
  Image hash: e380b683b0c4 (Ubuntu 24.04 LTS)
  CPU(s): 1
  Load: 0.00 0.00 0.00
  Disk usage: 1.8GiB out of 4.8GiB
  Memory usage: 209.4MiB out of 953.0MiB
  Mounts: --

Name: overruling-chimpanzee
State: Deleted
Snapshots: 0
IPv4: --
Release: --
Image hash: e380b683b0c4 (Ubuntu 24.04 LTS)
CPU(s): --
Load: --
Disk usage: --
Memory usage: --
Mounts: --

• multipass get local.driver
  qemu

Additional context
Add any other context about the problem here.

[levkropp]

Hi @virajkanwade, thanks for reporting this issue,

Would you be able to access the logs on your MacOS machine and send them here as files?

We have a troubleshooting launch/start issues document that may help you troubleshoot these network problems as well. Please let us know what the results of following the steps in the document are, as well as any other potential variables in your MacOS setup that could be affecting the ability to connect to instances (VPN, IPv4/IPv6 configuration etc). Thank you!

[mavwolverine]

@levkropp
multipassd.log.zip

[mavwolverine]

no vpn active. firewall is disabled.

[levkropp]

Thank you for providing the logs @virajkanwade! Just to confirm: are you using an ARM-based Mac with an M-series processor, or an Intel-based Mac?

[mavwolverine]

Yes, M2 Max

[mavwolverine]

We have a troubleshooting launch/start issues document that may help you troubleshoot these network problems as well.

Tried following most of the Mac steps I could understand. But no luck yet.

[levkropp]

Looking through the logs, it doesnt seem like there are any issues that were captured. What's interesting is that you have been able to to obtain an IP address for your neutral-sailfish instance (192.168.64.6) but multipass is not able to SSH into it.

Could you try SSHing manually into the instance with verbose logging enabled with the command:
ssh -i /var/root/Library/Application\ Support/multipassd/ssh-keys/id_rsa [email protected] -vvv
and provide the output? This could be an issue on the SSH side of things

On our How to Troubleshoot Network Issues document, there is a section for MacOS on troubleshooting network routing issues that may help diagnose the issue better as well. Thank you for your patience while we look into this!

[mavwolverine]

@levkropp

❯ sudo ssh -i /var/root/Library/Application\ Support/multipassd/ssh-keys/id_rsa [email protected] -vvv
OpenSSH_9.8p1, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.64.6 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/var/root/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/var/root/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.64.6 [192.168.64.6] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: connect to address 192.168.64.6 port 22: Operation timed out
ssh: connect to host 192.168.64.6 port 22: Operation timed out

[levkropp]

Could you double-check if the IP address in multipass info matches the one you're trying to SSH into? Also, ensure that the instance is running. Sometimes the IP can change or the instance might not be active. You should also be able to ping the instance once it is started with ping [IP of neutral-sailfish] to see if it is reachable from your current network

[mavwolverine]

@levkropp deleted all instances from /var/root/Library/Application Support/multipassd/qemu/vault/instances

Launched new instanced and tried the SSH command you mentioned. That worked. But multipass shell command failed.

[levkropp]

It's good to hear that you can SSH into the instance and reach a shell even if the multipass shell command is failing 🙂
Could you re-run a fresh multipass shell command with -vvvv (i.e. multipass shell -vvvv) to see if there is any more verbose error output that can be used to further troubleshoot the issues you are facing with the shell command?

[mavwolverine]

@levkropp

❯ multipass shell -vvvv hot-hound
shell failed: ssh connection failed: 'Failed to connect: No route to host'

[mavwolverine]

@levkropp
I copied the id_rsa key to my ~/.ssh and changed ownership and permissions similar to my regular id_rsa key.

ssh -i ~/.ssh/multipass_id_rsa [email protected]
ssh: connect to host 192.168.64.11 port 22: No route to host

sudo ssh -i ~/.ssh/multipass_id_rsa [email protected]
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-124-generic aarch64)

Maybe MacOS requires sudo when trying to ssh to internet sharing subnet and multipass is somehow not using sudo?

Just a thought, I could be misreading this.

[mavwolverine]

❯ sudo ping 192.168.64.11
PING 192.168.64.11 (192.168.64.11): 56 data bytes
64 bytes from 192.168.64.11: icmp_seq=0 ttl=64 time=0.447 ms
^C
--- 192.168.64.11 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.447/0.447/0.447/0.000 ms

❯ ping 192.168.64.11
PING 192.168.64.11 (192.168.64.11): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0
^C
--- 192.168.64.11 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

[jlj77]

Fyi, I'm experiencing a similar problem; details:

• macOS 15.1 (M3 Pro, in my case, however)
• multipass & multipassd 1.14.1+mac
• In my case, I suspended three VMs before signing off for the night; came back and started them this morning, finding that my shell command wasn't working, as described above; made a gist of the results of multipass shell -vvvv, plus showing how I can connect if I use Multipass's SSH key.

[jlj77]

And now, for reasons that aren't at all clear to me, the shell command is working once again. 😖

[SOFTWORK]

Here also the same problem, tried to access the multipass shell -vvvv and get also shell failed: ssh connection failed: 'Failed to connect: No route to host' - tried this with other vm, everytime the same problem
SSH Access to virtual IPs on the machine is regularly possible, but the multipass command ends always with the ssh connect error on macOS 15.1 (M1 Pro)
It seems, the multipass command cannot find the own VM by dynamic hosts name

[divisumma18]

This is the output of the first installation on a new mac (macOS 15.1):

multipass launch jammy --name vmtest
launch failed: The following errors occurred:
vmtest: timed out waiting for response

[jlj77]

And now, for reasons that aren't at all clear to me, the shell command is working once again. 😖

And, to follow-up on the follow-up 🤦‍♂️, it is no longer working once again. In summary, using ssh directly is fine, as is visiting a VM IP address in the browser, but the shell command fails, as does socat:

% socat tcp-listen:8200,reuseaddr,fork tcp:192.168.64.9:8200
2024/11/13 11:16:30 socat[17979] E connect(5, LEN=16 AF=2 192.168.64.9:8200, 16): No route to host
2024/11/13 11:16:30 socat[17980] E connect(5, LEN=16 AF=2 192.168.64.9:8200, 16): No route to host
...

(Interestingly, to me at least, is socat only complaining as above once its tunnel is 'used', not at initial set-up.)

[jaykae]

Adding my own findings after reading others... it seems to somehow be related to permissions

user: ~ > multipass shell testvm
shell failed: ssh connection failed: 'Failed to connect: No route to host'

If I run it with sudo it works (after I setup authentication)

user: ~ > multipass set local.passphrase
Please enter passphrase:
Please re-enter passphrase:

user: ~ > sudo multipass authenticate
Please enter passphrase:
# Enter the password that I just setup

user: ~ > sudo multipass shell testvm
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-122-generic aarch64)

 * Documentation:  https://help.ubuntu.com
 ....

I also just upgraded to MacOS 15.1 this weekend, I did not have issues prior to upgrading to 15.1 (I was on 15.0)

[pshamus]

I'm also experiencing the same behavior as @jaykae. Only able to SSH with sudo.

[ricab]

Thank you for all the info. We're looking into this and we'll post here when we have developments.

[ricab]

Just a short update: we could not reproduce this yet, but we are still working on it.

[vsarunas]

Yesterday, a user encountered an issue: their VM was running but it was time for an upgrade from Jammy to Noble, so they performed a delete/purge/create procedure. Setup scripts started failing while setting up the new VM ("no route to host"). The new VM was up and running, could SSH into it; only the multipass shell command was failing. multipass list command did show the correct IP address.

Had seen such problems before; network connections are being blocked by Network Extension Control Protocol layer in macOS - golang/go#68678 (comment) ; this affected a lot of Go applications and they all had their connections blocked with "no route to host" error. With multipass the problem is slightly different but the connection is being blocked by macOS.

Start Console.app and dumping logs, reproducing 'multipass shell' issue and then searching for NEProcessInfo might show why the connection is being blocked.

In my case, simply a reboot of macOS resolved the issue and didn't dig further.

[pshamus]

Just rebooted and am able to connect without sudo. Not sure what the issue was, but the solution by @vsarunas worked.

[ricab]

Hi all, has anyone tried the suggestion in this comment? It would be interesting to know if it helps here too.

[mavwolverine]

Hi all, has anyone tried the suggestion in this comment? It would be interesting to know if it helps here too.

I can confirm the solution in comment works

go to Settings > Privacy & Security > Local Network and ensure the app you are using to run the Multipass CLI is enabled, eg. Terminal, Hyper, Ghostty, Iterm2 etc.

[Chobicus]

Hi all, has anyone tried the suggestion in #3864 (comment)? It would be interesting to know if it helps here too.

Yes, it works