# Connect your guest
Choose offline operation, shared NAT, or a bridged LAN connection. Keep the guest process and the network service distinct.

## Start without guest networking
Use --net none for a direct cube launch with an existing kernel and matching image:

```sh
cube --freebsd /path/to/kernel \
  --disk /path/to/mini-memstick.img --net none
```

Replace both paths. This disables guest networking; downloading media on the host still requires internet access. Shared folders can work without a guest network interface.

## Start the app service
Open Cube.app, select the network mode, and click Start Service. Guests use vmnet-proxy. Stop the service before changing between NAT and bridging.

## CLI service with NAT
As an alternative to the app service, an administrator can start the CLI service from a normal user shell. Use the full path resolved by your shell so sudo can find the installed command:

```sh
sudo "$(command -v cube)" --vmnet-service
```

Confirm cube --help works first. This elevates only the service; launch guests as your normal user with vmnet-proxy. Keep the service terminal running, and do not start a second service on the same socket.

## Signed menu bar app
Cube.app can launch its bundled networking helper as the logged-in user without sudo or a root daemon. That path requires an Apple-granted com.apple.vm.networking entitlement and matching provisioning profile. An ordinary ad-hoc development build does not supply them.

Rebuilding replaces the helper and clears previous provisioning, so the app must be signed again for that networking path. Keep the bundle intact. The [app signing guide](https://github.com/darcyliu/cube/blob/main/docs/cube_app.md) has the signing command and requirements.

## Bridged LAN
Stop the NAT service before starting the bridged service. The service has one active mode per socket. Specify a suitable host interface for your network:

```sh
sudo "$(command -v cube)" --vmnet-service --bridge en7
```

Here en7 is an example: use your actual interface. Guests continue to use vmnet-proxy and obtain a LAN address. Stopping or restarting the service disconnects attached guests.

## SSH forwarding and addresses
The --ssh-port option learns the guest IPv4 address from DHCP. Static guest addresses require an explicit forwarding rule. A running VM with no learned DHCP address may show a null IP in status; this does not prove the guest is stopped.

Guest IP configuration depends on the boot workflow. See the [networking runbook](https://github.com/darcyliu/cube/blob/main/docs/networking.md) for DHCP, routes, DNS, explicit forwarding, and diagnostics.

## When the service will not start
In Cube.app, open the service log from the app. Confirm the helper was signed after the most recent rebuild. In the CLI, confirm the binary was built and that another service is not already using the socket. Do not remove the socket of a running service.

App logs and its socket are under ~/Library/Application Support/cube/. Custom NAT subnets are not available through the unprivileged app; the separately administered CLI service has different privileges and setup requirements.