> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.ibee.ai/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.ibee.ai/docs/_mcp/server.

# Networking for VMs

> How public IPs, bandwidth, firewalls, and DNS work for IBEE Solutions VMs.

Every Cloud VM ships with networking ready to use: a public IPv4 address, a metered outbound bandwidth allowance, and DHCP on the primary interface. This page explains the defaults and the controls available to you.

## Default network setup

| Property           | Default                                                                                  |
| ------------------ | ---------------------------------------------------------------------------------------- |
| Public IPv4        | One address assigned at deploy time                                                      |
| IPv6               | Available where the region supports it                                                   |
| DHCP               | Enabled on the primary interface (`eth0` / `ens3`)                                       |
| Reverse DNS        | Defaults to a generic `*.ibee.cloud` hostname; can be customized                         |
| Inbound bandwidth  | Unmetered                                                                                |
| Outbound bandwidth | Per-plan allowance (see [Instance types](/docs/infrastructure/cloud-vms/instance-types)) |

The VM list shows the assigned public IP under the **IP Address** column once provisioning completes (for example `103.149.10.116`).

## Inside the guest

The primary NIC uses `virtio-net`. Most cloud images bring the interface up automatically via DHCP at boot. To check:

```bash
ip -4 addr show
ip route
```

You should see a public IP on the primary interface and a default route via the IBEE gateway.

## Firewalls

Cloud VMs deploy with no firewall attached — all traffic is allowed unless your guest OS enforces it. To restrict traffic at the platform level, attach an [IBEE firewall](/docs/network-security/firewalls):

* Define **inbound rules** for ports/protocols you want to expose (SSH, HTTP/HTTPS, custom).
* Define **outbound rules** if you need to constrain egress.
* Attach the firewall to one or more VMs from the firewall detail page.

Inside the guest, you can also run `ufw`, `firewalld`, or Windows Defender Firewall — they stack with platform firewalls.

## DNS

Use [IBEE DNS](/docs/network-security/dns) (or any external DNS provider) to point a domain at your VM:

1. Create a zone for your domain.
2. Add an `A` record for the VM's public IP, or an `AAAA` record for its IPv6.
3. Add a `CNAME` for `www` if needed.

For TLS, IBEE issues and renews [SSL certificates](/docs/network-security/ssl-certificates) once your DNS resolves.

## Bandwidth and overage

Each plan includes a monthly outbound bandwidth allowance (for example **2 TB** on `std.1.c2.m8`). The Monitoring tab's **Network** chart shows current inbound and outbound throughput.

* Inbound traffic is unmetered.
* Outbound usage above the included allowance is billed per GB; see your plan summary for the rate.

## Load balancing

To put a load balancer in front of multiple VMs, use [Load Balancer](/docs/network-security/load-balancer):

* Create the load balancer in the same region as your VMs.
* Attach the VMs as backends and configure a health check.
* Optionally terminate TLS at the load balancer.

## Private networking

VMs in the same region share a regional backplane and can communicate using their public IPs without traversing the internet (traffic stays within the IBEE network). Private VPCs and dedicated subnets are on the roadmap; check the changelog or [Networking](/docs/network-security) overview for the current state.

## Troubleshooting

**VM has no public IP after deploy**
Refresh the VM list — the column updates after provisioning completes. If it stays blank for more than a few minutes, open the [Activity feed](/docs/infrastructure/cloud-vms/monitoring#activity-feed); a failed `VM create` will surface here.

**Can't SSH but the VM is Running**

* Confirm a firewall isn't blocking port 22.
* Use the [Console](/docs/infrastructure/cloud-vms/power-actions#console) to log in and check `sshd` status, then verify your SSH key was injected (`~/.ssh/authorized_keys`).
* If the wrong key was added at deploy time, replace it via the console and add the right one.

**Bandwidth chart looks flat or empty**
The chart smooths over its time range. Switch to **30m** for short-window detail.

## Related pages

* [Create a VM](/docs/infrastructure/cloud-vms/create-a-vm)
* [Firewalls](/docs/network-security/firewalls)
* [DNS](/docs/network-security/dns)
* [Load Balancer](/docs/network-security/load-balancer)
* [SSL Certificates](/docs/network-security/ssl-certificates)