NAT gateways

VMs reach the internet over IPv6 out of the box. IPv4 goes through the VPC’s NAT gateway, which does two jobs:

• Outbound for the whole VPC. With a public IP of its own, the gateway sends the outbound IPv4 traffic of every VM in the VPC from that one address (source NAT). Nothing can connect in through it.
• Public IPs for single VMs. A public IP pointed at a VM is mapped to it one-to-one by the gateway. So a VPC needs a NAT gateway before any of its VMs can have a public IP, even if the gateway has no address of its own.

Create one

A VPC has at most one NAT gateway. It sits in any subnet of the VPC and serves all of them.

Console

Open Network, pick the VPC, and add a NAT gateway. Give it a public IP if the VMs without their own address should reach the internet over IPv4.

CLI

NAT_IP=$(tebib -o json public-ip allocate nat-ip --wait | jq -r .id)
NAT=$(tebib -o json nat-gateway create backend-nat --subnet "$SUBNET" --public-ip "$NAT_IP" --wait | jq -r .id)
tebib nat-gateway show "$NAT"

Leave out --public-ip for a gateway that only carries VMs’ own public IPs. You can associate an address later: tebib public-ip associate <IP ID> --nat-gateway <NAT ID>.

VMs without their own public IP then leave as the gateway’s address. A VM with its own public IP keeps using that, in both directions.

Good to know

• Billing: the gateway is included; public IPs bill as usual. Internet egress of VMs behind the gateway’s address counts per VPC, not per VM. Give a VM its own public IP if you need per-VM traffic figures.
• Availability: a gateway is a single instance. During platform maintenance it can be unreachable for a few seconds while it moves (about 11 s measured), for the VPC’s IPv4 outbound and for its VMs’ public IPs. Open connections may need to reconnect.
• Delete: disassociate the public IPs of the VPC’s VMs first. Deleting the gateway stops IPv4 outbound for the VPC; the gateway’s own address stays in your project, unattached.