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
Section titled “Create one”A VPC has at most one NAT gateway. It sits in any subnet of the VPC and serves all of them.
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.
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
Section titled “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.