Unable to access internet in VM on using Zscaler

[sinhaashish-netapp]

Describe the bug
Describe what your problem is.

We had Zscaler installed on our machines, and since then, Multipass has stopped working due to network connectivity issues. When launching a Multipass VM, it starts successfully but has no outbound internet access — pinging external addresses (e.g., 8.8.8.8) results in 100% packet loss. Although the DNS search domains are present, traffic from the VM is not being routed to the internet. This appears to be a routing conflict between Zscaler and the Multipass VM’s network layer.

We rely on Multipass for our local development environment, so this issue is blocking our workflow.

As a workaround, we shut down the VM, change its network adapter to Bridged Mode, and then restart it, but of no use.

Raised the issue with zscaler
This is their response

Issue: ZCC running on macOS using Multipass does not allow the guest VM to connect to the internet.
During the call, we collected ZCC logs to investigate the issue. After reviewing the packet captures, I observed that a RST is being sent from the client on port 9093. In the PCAP where the first RST appears, the packet dump shows the interface as utun4 and the IP as 192.168.2.56. The capture indicates utun4 (the ZCC virtual interface), but we do not see corresponding entries in our tunnel logs.
Specifically:
In packet 9967, a SYN is sent to port 80 of an internet server.
In packet 9968, the same traffic appears to be redirected to port 9093 on the local default interface, after swapping the source and destination IP addresses.
This behavior suggests the traffic is being incorrectly handled by Multipass networking. Since there is no listener on port 9093 on the local interface, the host responds with a RST, which causes the connection to drop.
Could you please check with the Multipass team regarding this networking issue?

To Reproduce
How, and what happened?

1. Start a multipass vm with Zscaler installed.
2. ssh to VM and ping google or do a apt update

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 Tahoe 26.3]
• CPU architecture or model: [Apple M4 Pro]
• multipass version

❯  multipass --version
multipass   1.16.1+mac
multipassd  1.16.1+mac

• multipass info
• multipass get local.driver

❯ multipass get local.driver
qemu

Additional context
Add any other context about the problem here.

[ricab]

Hi @sinhaashish-netapp, Multipass uses QEMU with Apple's vmnet for this. We use it in two modes:

• vmnet-shared for a NATed connection (isolated subnet with its own DHCP)
• vmnet-bridged for a bridged connection (the one you get when you toggle bridging in the GUI, which connects directly through a physical interface to the same subnet as the host)

Here's the code. All we do is specify those command line parameters to QEMU and let Apple take care of the rest. Internally, macOS creates virtual interfaces that QEMU connects VMs to.

In no place does Multipass listen on, send traffic to, or otherwise use port 9093. I don't know if you have a workload using port 9093 in the VM, but we wouldn't touch it.

On macOS, Multipass does not redirect any traffic, install any firewall rules, mess with packet headers, swap IPs, or anything of the sort. It's hands-off network traffic.

It sounds to me like Zscaler is interfering with the vmnet API in some way. Zscaler provides tools or services that gate or manipulate network traffic, right? Verifies everything against established policies, no? Remove it from the picture, and traffic flows, correct? Whatever they are doing is preventing the virtual connections from working as intended. Probably some policies need updating to account for virtual interfaces and networking?

If you do find any evidence Multipass doing something wrong or poorly, please share.

[ricab]

Not sure if it matters, but if you bridge with a wireless card, I believe macOS internally swaps the VM's MAC address with the WiFi card's. Otherwise the AP would drop packets.

[sinhaashish-netapp]

Hi @ricab Thanks for your response .
Can you please share the documentation for configuring the multipass in NAT and Bridged mode?

Zscaler is a proxy solution where it will pass all the traffic from the system through multiple security policies before it gets pass the traffic to internet. So traffic from the VM while going to internet will pass through the Zscaler.

We have raised a case with Zscaler vendor and as per them they are suspecting multipass is dropping connections, RST is being sent from the client on port 9093.

[ricab]

Hi @sinhaashish-netapp, have a look through these. The gist is:

• All instances are created with a default NAT network, you don't need to do anything for that. Each instance gets an IP in a shared subnet that is only available within your host. They can use it to reach each other and to go online, but they can't be independently reached from the outside. The exact mechanism varies, but in your case it's based on the vmnet API I mentioned.
• Additionally, you can add a bridged interface to a VM. The default NAT setup remains, but the VM gets another network interface that is bridged to your physical card, i.e. linked to it at the network layer. That allows the VM to participate directly in your network (the one your host is attached to). The VM requests DHCP on this interface too, just like any other device on the network. The IP it gets is in the same subnet as the host and can be used to address the VM directly from another endpoint.

If you cut one of those links or otherwise interfere with the setup, it will likely not work. Same as if a cable got cut or unplugged between your host and your router.

Zscaler is a proxy solution where it will pass all the traffic from the system through multiple security policies before it gets pass the traffic to internet. So traffic from the VM while going to internet will pass through the Zscaler.

Right. And you can imagine Zscaler is not letting traffic just flow freely... It's blocking or somehow interceding in the communication in ways that break the setup. There is nothing Multipass can do about that.

[github-actions]

This issue was marked stale because it has been labelled with "question" for 30 days.