{"slug":"networking-private","title":"Private Networks","description":"Private networks are isolated, RFC1918 layer-2 segments that connect your VPS instances over a private link. Traffic between attached VPS instances stays inside our infrastructure — it never traverses...","section":"Features","url":"https://docs.danubedata.ro/networking-private","markdown_url":"https://docs.danubedata.ro/networking-private.md","breadcrumbs":[{"title":"Features","slug":null},{"title":"Networking","slug":"networking-overview"},{"title":"Private Networks","slug":"networking-private"}],"headings":[{"level":1,"title":"Private Networks","id":"private-networks"},{"level":2,"title":"When to use a private network","id":"when-to-use-a-private-network"},{"level":2,"title":"Create a network","id":"create-a-network"},{"level":2,"title":"Attach a VPS","id":"attach-a-vps"},{"level":2,"title":"Verify connectivity","id":"verify-connectivity"},{"level":2,"title":"Detach","id":"detach"},{"level":2,"title":"Delete a network","id":"delete-a-network"},{"level":2,"title":"Limits and notes","id":"limits-and-notes"},{"level":2,"title":"Security model","id":"security-model"},{"level":3,"title":"Tenant isolation","id":"tenant-isolation"},{"level":3,"title":"Inside one network","id":"inside-one-network"},{"level":3,"title":"Encryption","id":"encryption"},{"level":3,"title":"Audit","id":"audit"},{"level":2,"title":"Related Documentation","id":"related-documentation"}],"format":"markdown","word_count":1376,"content":"# Private Networks\n\n> **Beta.** Private networks are rolling out behind a feature flag. If you don't yet see \"Private Networks\" in your dashboard sidebar, [email support](mailto:support@danubedata.ro) and we'll enable it for your team.\n\nPrivate networks are isolated, RFC1918 layer-2 segments that connect your VPS instances over a private link. Traffic between attached VPS instances stays inside our infrastructure — it never traverses the public internet, doesn't count against your VPS bandwidth allowance, and isn't reachable from the outside.\n\nEach network you create gets:\n\n- Its own CIDR block (you pick) from any RFC1918 range — `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16`.\n- A dedicated bridge on every VPS host you attach a VM to, glued together with VXLAN so VMs on different physical hosts behave as if they were on one switched LAN.\n- Per-attachment MAC and IP, attached as an extra NIC inside the guest with no reboot required.\n\n## When to use a private network\n\n| You want to…                                                                | Use a private network         |\n| --------------------------------------------------------------------------- | ----------------------------- |\n| Wire VPS instances together with addresses you control                      | Yes                           |\n| Dedicate a CIDR block for a tier (e.g. `10.10.0.0/24` for app, `10.20.0.0/24` for db) | Yes |\n| Reach a managed database, cache, or queue                                   | No — those already expose private endpoints in the [Networking page](https://docs.danubedata.ro/networking-overview) |\n| Connect resources across two of *your own* teams (staging ↔ prod)           | No — use [Network Peering](https://docs.danubedata.ro/networking-peering) |\n| Restrict which VMs in your team can reach a service                         | Combine with a [firewall rule](https://docs.danubedata.ro/networking-firewalls) |\n\n## Create a network\n\n1. Open **Networking → Private Networks** in the sidebar and click **New private network**.\n2. Pick a name (lowercase letters, digits, and hyphens; must start and end with an alphanumeric character).\n3. Choose an IP range in CIDR notation. Rules:\n   - RFC1918 only: `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16`.\n   - Prefix between `/16` and `/24`.\n   - The first **10 addresses** of the range are reserved for the platform (e.g. `10.0.0.0`–`10.0.0.9` in a `10.0.0.0/24` network); your VPS instances start at `.10`.\n   - The range cannot overlap with another private network you already own.\n4. (Optional) Add a description so your teammates know what the network is for.\n\nThe network goes **active** within a few seconds of creation. Behind the scenes, the platform allocates a VXLAN ID, writes the bridge configuration to every VPS host, and registers a Multus network attachment in your tenant namespace.\n\n## Attach a VPS\n\nFrom the network's detail page (or directly from the index using **Attach VPS** on each row), pick the VPS you want to attach.\n\n- **Auto-allocated IP** — leave the *Requested IP* field blank and the platform picks the next available address from the network's range.\n- **Specific IP** — type one in (e.g. `10.0.0.42`). It must be inside the network's CIDR, outside the reserved first-10 block, and not already taken.\n\nThe new interface comes up **live** — no reboot. Within a few seconds:\n\n- Inside the guest, you see a new NIC with the assigned IP and a deterministic MAC of the form `02:00:01:xx:xx:xx`.\n- Cloud-init has dropped a netplan file at `/etc/netplan/60-private-<vni>.yaml` so the address survives reboots.\n- The MTU on the new interface is **1450** to leave room for VXLAN encapsulation.\n\nThe attachment status is reflected in the UI:\n\n| Status            | Meaning                                                                                       |\n| ----------------- | --------------------------------------------------------------------------------------------- |\n| `pending`         | Allocation in progress; gitops sync hasn't completed yet.                                     |\n| `active`          | Interface is up in the guest, IP configured.                                                  |\n| `pending-reboot`  | Live attach didn't complete (e.g. guest agent unreachable). The interface will appear on next reboot, or you can hit **Retry** to re-run the live push. |\n\n## Verify connectivity\n\nAfter attaching two VPS instances, ping between them using the private IPs:\n\n```bash\n# On 10.0.0.10\nping -c 4 10.0.0.11\nip -br addr show\nip route get 10.0.0.11\n```\n\nYou should see sub-millisecond RTT between VPS instances on the same physical host, and a few hundred microseconds across hosts (VXLAN-encapsulated over our internal datacenter network).\n\nThe private IPs are **not reachable from outside** the network — a public-internet host pinging `10.0.0.10` will time out. Only VPS instances attached to the same private network can reach each other.\n\n## Detach\n\nFrom the network's detail page, click the trash icon on an attachment row and confirm. The platform:\n\n1. Pushes the netplan removal to the running guest (when the agent is reachable) so the IP comes off live.\n2. Updates the VM manifest to drop the NIC.\n3. Frees the IP back to the pool.\n\nIf the guest agent isn't reachable at the moment of detach, the netplan file lingers until the next reboot — but the host stops forwarding to the IP immediately, so peers can't reach it regardless.\n\n## Delete a network\n\nA network can only be deleted when **no VPS instances are still attached** to it. Detach all VPSes first, then click **Delete network** on the network's detail page. The bridge and VXLAN tunnel are removed from every host within the next reconcile cycle.\n\n## Limits and notes\n\n- **MTU is 1450** on the in-guest interface. If you tunnel further (WireGuard, VPN), keep the inner MTU below this.\n- **No DHCP** — IPs are assigned at attach time and configured statically via netplan. There is no DHCP server on the network.\n- **No NAT, no gateway** — a private network is L2-flat. There is no router providing internet access via the private IP. VPS instances still use their public NIC for internet traffic; the private network is purely for east-west traffic.\n- **Free** — east-west traffic on a private network does not count against your VPS bandwidth allowance.\n\n## Security model\n\nA few things to know before treating a private network as a security boundary.\n\n### Tenant isolation\n\n- **Per-team isolation is enforced at the platform layer.** Networks are scoped to your team, allocated a distinct VXLAN ID, and the host kernel decapsulates packets onto your bridge only when the VXLAN ID matches yours.\n- **Host-level firewall** restricts which underlay IPs can send VXLAN traffic to the platform — the kernel only accepts UDP/4789 from VPS hosts in our internal whitelist. External attempts to inject crafted VXLAN frames are logged and dropped.\n- **Two teams using the same CIDR** (e.g. both `10.0.0.0/24`) are completely isolated — they live on different bridges with different VXLAN IDs.\n\n### Inside one network\n\nA private network is a layer-2 LAN segment between attached VPS instances. That means:\n\n- **Anti-spoofing is enforced by the platform.** Each VM is pinned to its assigned (MAC, IP) pair via host-level ebtables rules. A VPS attempting to ARP-spoof or IP-spoof another VPS on the same network has those frames dropped on the bridge before they reach any peer.\n- We do not inspect or filter your application-layer traffic between VMs that use their legitimate IPs.\n- If you run **untrusted workloads** (multiple users / multiple apps with different trust levels), still prefer separate private networks per trust boundary as defense in depth — anti-spoofing prevents impersonation, not application-level abuse from a legitimate VM.\n- **The per-VPS firewall applies to private-network traffic, but in \"explicit-allow\" mode.** Any `allow` rule you define (e.g. *allow TCP/22 from anywhere*) is matched on the public IP **and** on every private-network IP attached to the VPS. However, unlike on the public NIC, traffic on the private network is **not** denied by default — anything not explicitly allowed simply passes through. This means:\n  - Adding `allow TCP/22 from anywhere` opens SSH on both public and private IPs.\n  - Service-to-service ports between attached VPS instances (e.g. an internal API on TCP/9000) keep working without a matching rule.\n  - To restrict which VPSes can reach which ports **on the private network**, add explicit `deny` rules with a private-network source — those are honored verbatim.\n- For wire-tight isolation between workloads on the same private network, complement the per-VPS firewall with an **in-guest firewall** (ufw / firewalld / iptables).\n\n### Encryption\n\nVXLAN traffic between VPS hosts is **not encrypted on the wire**. The underlay traverses our internal datacenter network, which is not exposed publicly, but if you have a regulatory requirement for wire-level confidentiality (HIPAA, certain GDPR data classes, internal compliance), you should terminate **TLS** or **WireGuard** between your VPSes on top of the private network. The private network gives you a clean addressing plane to do that on.\n\n### Audit\n\nCreate / delete / attach / detach actions are written to your team's audit log. You can review them from your [account settings](https://docs.danubedata.ro/account-settings).\n\n## Related Documentation\n\n- [Networking Overview](https://docs.danubedata.ro/networking-overview)\n- [Firewalls](https://docs.danubedata.ro/networking-firewalls)\n- [Network Peering](https://docs.danubedata.ro/networking-peering)\n","prev":{"title":"Firewalls","slug":"networking-firewalls","url":"https://docs.danubedata.ro/networking-firewalls","markdown_url":"https://docs.danubedata.ro/networking-firewalls.md","json_url":"https://docs.danubedata.ro/networking-firewalls.json"},"next":{"title":"Network Peering","slug":"networking-peering","url":"https://docs.danubedata.ro/networking-peering","markdown_url":"https://docs.danubedata.ro/networking-peering.md","json_url":"https://docs.danubedata.ro/networking-peering.json"},"index_url":"https://docs.danubedata.ro/index.json"}