---
description: What the guest OS sees on a private network — addressing, DHCP, metadata, DNS
revision_date: 19.10.2026
---

# Inside the instance

!!! warning "Draft — pilot feature"
    Private Networks is in a limited pilot and this page is a work in progress.

This page describes what an instance on a private network sees from the inside.
It matters most when you are debugging connectivity, writing automation that
reads its own address, or assessing the instance's attack surface.

## Addressing

The instance's network interface is configured over DHCP with:

| | |
|---|---|
| **Address** | Its private IP, from the subnet's CIDR |
| **Default gateway** | `169.254.0.1`, a synthetic, link-local gateway. It is not an instance. |
| **MTU** | 8950 |

**The public IP never appears inside the instance.** It is applied as 1:1 NAT
outside the guest, so `ip addr` shows only the private address. Anything that
needs to know its own public address (a service advertising an endpoint, a
TLS certificate workflow, a cluster member list) must read it from the
metadata service, not from the interface.

Ports are not translated: a connection arriving at the public IP on port 443
arrives at the instance on port 443, from the remote client's real source
address.

## Metadata service

An EC2-style metadata service is served at the conventional link-local address:

```bash
curl http://169.254.169.254/latest/meta-data/
```

Available keys:

| Key | Value |
|-----|-------|
| `instance-id` | The instance's id |
| `local-ipv4` | The private IP |
| `public-ipv4` | The public IP, only when the instance has one |

Other EC2 keys (`hostname`, `local-hostname`, `public-hostname`,
`instance-type`) are deliberately not served: they are absent from the directory
listing and return 404 individually.

!!! warning "The metadata service is unauthenticated"
    It has no authentication: any process in the instance can read it.

    If your workload runs untrusted code, block HTTP (TCP port 80) to
    `169.254.169.254` with a guest firewall. Leave UDP port 53 open, the same
    address also serves [DNS](#dns).

## DNS

A resolver is served on UDP port 53 at the same `169.254.169.254` address. It
answers internal Verda zones authoritatively and forwards everything else
upstream, so ordinary public names resolve normally.

## Things that do not work the way they did on legacy instances

- Binding a listener to the public IP fails, the address is not on the
  interface. Bind to the private IP or to `0.0.0.0`.
- Software that discovers its own public address from the interface (some
  cluster managers, some VPN daemons) needs to be told the address explicitly.
- An instance with no public IP has no outbound internet, so package managers,
  `pip`, `docker pull`, and license checks all fail until you set up
  [internet access](https://docs.verda.com/private-networks/internet-access/).