Renters connect to your machine from the open internet, and most GPU hosts run behind a home or small office router doing NAT. That router drops every unsolicited inbound connection by default, which means your machine is invisible until you explicitly forward its port range. Getting this right once, and making it survive reboots, is the difference between a machine that verifies on the first try and weeks of intermittent port errors.
How traffic actually reaches your machine
When a renter (or the Vast.ai verification probe) connects to your machine, the packet goes to your public IP address, which belongs to your router, not your host. The router has to know that a connection arriving on, say, port 40012 should be handed to the GPU machine at a specific LAN address. That mapping is the forwarding rule. No rule, no connection, and the marketplace reports your ports as unreachable even though the machine itself is perfectly healthy.
Vast.ai assigns each machine a block of ports, not a single one, because every rental container gets its own mapped ports for SSH and services. Your forwarding rule must cover the whole block shown on your host dashboard.
Step 1: Pin the machine to a static LAN address
A forwarding rule points at a LAN address. If your host gets its address from DHCP, a lease renewal or a reboot can silently move it, and your rule now forwards traffic into the void. This is the single most common cause of "it worked for weeks and then broke." Fix it before touching the router:
- Preferred: DHCP reservation. In your router's DHCP settings, bind the host's MAC address to a fixed LAN address. The machine keeps normal DHCP config and always gets the same address.
- Alternative: static address on the host. On Ubuntu server this means a netplan config. Be careful here: a malformed netplan file can take the machine off the network entirely, and on 22.04 there is a known upgrade pitfall documented in the 22.04 netplan issue writeup.
Confirm the machine's current address with ip a before and after, so you know exactly what the forwarding rule should target.
Step 2: Forward the full port range on the router
Router interfaces differ, but the rule you are creating is the same everywhere. Find the section called Port Forwarding, Virtual Server, or NAT rules, and create one entry:
| Field | Value |
|---|---|
| External ports | The full range from your Vast.ai host dashboard, e.g. 40000 to 40100 |
| Internal ports | The same range (no translation) |
| Internal address | The host's static LAN address from step 1 |
| Protocol | TCP (add UDP too if your router bundles them) |
Three mistakes account for most broken setups:
- Forwarding one port instead of the range. Verification may pass on the probe port while rentals fail on the rest of the block.
- Translating ports (external 40000 to internal 22, for example). Vast.ai expects the range mapped straight through.
- Double NAT. If your ISP modem also routes, and your own router sits behind it, you need the rule on both devices, or bridge mode on the modem. A WAN address on your router starting with 100.64 through 100.127, 10, or 192.168 is the giveaway that another NAT layer sits above you.
CGNAT: when forwarding cannot work
Step 3: Open the host firewall to match
The router now delivers packets to the machine, but the local firewall has its own opinion. If ufw is active, allow the same range:
sudo ufw allow 40000:40100/tcp
sudo ufw status numberedKeep the rule tight: the assigned range plus SSH, nothing more. A rental host is a public server, and the rest of your Ubuntu server setup should treat it that way.
Step 4: Verify from outside your network
Testing from your own LAN proves almost nothing, because many routers cannot loop traffic back to their own public IP. Verify from a genuinely external point: a phone on mobile data with a port checker app, a cheap VPS, or a friend running:
nmap -Pn -p 40000-40100 YOUR_PUBLIC_IPYou want open on every port where a service is listening. filtered means a firewall or NAT layer is still dropping packets. closed means the path works but nothing is bound on the machine, which is a service problem, not a forwarding problem. The port check guide in our open source Linux tools collection walks through interpreting each result.
Make it survive the next reboot
A setup that works today and dies at the next power cut is not done. Run through this once before you call it finished:
- 1Reboot the router and the host, then rerun the external nmap check. The DHCP reservation and firewall rules should hold without you touching anything.
- 2Save or export the router config if your firmware allows it, so a factory reset does not erase an hour of work.
- 3Write down the LAN address, port range, and router rule location somewhere you will find them at 2 AM. Future you is the person most likely to debug this next.
If the ports still refuse to answer after all of this, the fault is somewhere subtler, and the systematic layer-by-layer hunt in our port not listening diagnosis guide is your next stop.