# Add an extra IPv4 address to your server

> Set up an extra IPv4 address so it works now and after a reboot, with netplan or NetworkManager, without losing SSH. Tested on Ubuntu, Debian and AlmaLinux.

Source: https://rack4.io/help/configure-extra-ipv4 · Updated: 2026-11-06

Once an extra IPv4 address has been added on your server's **Add-ons** page (its **Settings** tab, then **Add-ons**), it's routed to the server, but the server doesn't use it until you configure it. Add it for now with one command, test it, then save it in the network settings so it survives a reboot.

Have the **Console** tab open and logged in before you change network settings. If a mistake drops the network, SSH goes with it, and the serial console is how you get back in. It needs a root password; if you don't have one, [set one](https://rack4.io/help/root-password) first.

The examples use a main address of `203.0.113.42` and an extra address of `203.0.113.20/24`. The add-ons page shows the real address and its prefix (the number after the `/`); use exactly those.

## 1. Add it until the next reboot

Find the network interface's name:

```bash
ip -br link
```

It's the one that isn't `lo`: `enp1s0` on our Ubuntu and Debian images, `eth0` on AlmaLinux. Then add the address:

```bash
sudo ip addr add 203.0.113.20/24 dev enp1s0
```

## 2. Test it from outside

From your own computer (not the server):

```bash
ping 203.0.113.20
```

If it doesn't answer at once, wait a minute and try again: on one of our tests the first replies took about a minute to start. To check that traffic can also *leave* from the new address, run this on the server:

```bash
curl --interface 203.0.113.20 https://api.ipify.org
```

It should print the extra address. If ping still fails after a few minutes, check that a firewall isn't blocking it: the [panel firewall](https://rack4.io/help/server-firewall) and `ufw` or `firewalld` on the server apply to every address.

## 3. Keep it after a reboot

Which tool to use depends on what manages the network on your server. Check:

```bash
ls /etc/netplan
```

If that lists a file, use netplan. If it says `No such file or directory`, run `nmcli general`; if that answers, use NetworkManager.

### netplan (Ubuntu, Debian)

Back up the file first, then open it:

```bash
sudo cp /etc/netplan/50-cloud-init.yaml /root/50-cloud-init.yaml.bak
sudo nano /etc/netplan/50-cloud-init.yaml
```

Find the `addresses:` list with the server's main address, and add the extra one as a new line **with exactly the same indentation and quoting as the line above it**:

```yaml
      addresses:
      - "203.0.113.42/24"
      - "203.0.113.20/24"
```

Indentation matters in this file. A line indented further than the one above it makes netplan reject the whole file, with `Invalid YAML: inconsistent indentation`. Check the file before applying it; no output means it's fine:

```bash
sudo netplan generate
```

Then apply it with a safety net:

```bash
sudo netplan try
```

It applies the change and asks you to press **Enter** within 120 seconds. If you can still type, press Enter and you're done. If the network broke and you can't, it puts the old network settings back by itself. One catch we saw on our Ubuntu 24.04 test: after rolling back, the edited file was still in place, so the same mistake would come back at the next reboot. If `netplan try` rolled back, restore your copy before doing anything else:

```bash
sudo cp /root/50-cloud-init.yaml.bak /etc/netplan/50-cloud-init.yaml
```

### NetworkManager (AlmaLinux, Rocky Linux, Fedora)

Find the connection that carries the default route, add the address to it, and bring it up again:

```bash
DEV=$(ip route show default | awk '{print $5; exit}')
CON=$(nmcli -g GENERAL.CONNECTION device show "$DEV")
echo "$CON"
sudo nmcli con mod "$CON" +ipv4.addresses 203.0.113.20/24
sudo nmcli con up "$CON"
```

On our AlmaLinux 10 image the connection is called `cloud-init eth0`. `nmcli con up` re-applies the connection; SSH stays connected through it.

### Anything else

Arch Linux uses systemd-networkd: add an `Address=203.0.113.20/24` line to the `[Network]` section of the `.network` file in `/etc/systemd/network/`, then run `networkctl reload`. For any other setup, add the address the way your tool expects, and test it from the console first.

## 4. Reboot once and check

Restart the server from the panel, then check that **both** addresses answer:

```bash
ip -br addr
```

and `ping` each address from your computer. Doing this now, while you're watching, is better than finding out after an unplanned restart.

## Removing an extra address

Take it out of the server's settings first, then lower the count on the Add-ons page:

- **netplan**: delete its line from the `addresses:` list, then `sudo netplan apply`. The address goes from the interface straight away.
- **NetworkManager**: `sudo nmcli con mod "$CON" -ipv4.addresses 203.0.113.20/24`, then `sudo nmcli con up "$CON"`.

The newest extra address is the one taken away at your next renewal. Move anything that uses it, such as a website or DNS record, to another address before then.

## Good to know

- A [reinstall](https://rack4.io/help/reinstall-a-server) configures every address the server has, extra ones included.
- Outbound port 25 is blocked on extra addresses as it is on the main one; see [open port 25](https://rack4.io/help/open-port-25).
- [Reverse DNS](https://rack4.io/help/reverse-dns) can be set for the main address.

We tested these steps on 6 November 2026 on Rack4 servers running our Ubuntu 24.04, Debian 13 and AlmaLinux 10 images: each address answered from outside, sent traffic out, and was still there after a restart from the panel. The Arch Linux lines weren't part of that test.