How to Add Two IP Addresses to One Network Interface on Linux

How to Add Two IP Addresses to One Network Interface on Linux

I recently ran into an unexpected networking problem on one of my Linux servers. The system had two physical network adapters connected to the same network, and some applications did not consistently use the interface I expected for outbound internet traffic.

Instead of maintaining two adapters, two routes, and two physical connections, I moved both IP addresses onto a single network interface.

The result was a simpler configuration:

  • One physical network adapter
  • One network cable
  • One default gateway
  • Two independently usable IP addresses
  • Fewer routing and application-binding surprises

This approach is commonly called assigning multiple addresses to one interface, or informally, IP aliasing.

The following example uses Debian’s traditional ifupdown networking system and /etc/network/interfaces. NetworkManager, Netplan, and systemd-networkd use different configuration formats.

Why use two IP addresses?

A server does not need a separate physical adapter for every IP address. Linux can assign multiple addresses to the same interface and accept traffic for all of them.

In my case, I wanted two SSH-based services to use distinct addresses:

  • 10.0.0.2 for the server’s OpenSSH service
  • 10.0.0.3 for a containerized service such as Gitea SSH

Both addresses are on the same /24 subnet and use the same physical adapter.

This allows clients to connect to the appropriate service by destination address:

10.0.0.2:22  →  OpenSSH
10.0.0.3:22  →  Gitea SSH

The traffic arrives over the same cable, but the Linux kernel can distinguish it by destination IP address and port.

Why not use two physical adapters?

There are good reasons to use multiple adapters, including redundancy, network isolation, increased bandwidth, or connections to separate networks. However, two adapters on the same subnet can add unnecessary complexity when all you need is another address.

Potential complications include:

  • Competing default routes
  • Different route metrics
  • Unexpected source-address selection
  • Applications binding to the wrong interface
  • Replies leaving through a different interface
  • ARP behavior that is harder to troubleshoot
  • More configuration to maintain

The Linux kernel even provides special ARP settings for systems with multiple interfaces on the same subnet, illustrating that this arrangement may require additional routing and ARP planning. Linux kernel IP networking documentation

Moving both addresses to one adapter does not solve every possible networking problem, but it removes the question of which physical interface should carry ordinary outbound traffic.

Before making changes

Make sure that:

  1. Both IP addresses are available and not assigned to another device.
  2. The addresses are reserved or excluded from your DHCP pool.
  3. You know the correct interface name.
  4. You have console access in case the network configuration fails.
  5. You back up the existing configuration.

Editing networking remotely over SSH can disconnect you from the server. If possible, perform the final network restart through a local console, remote-management interface, or virtual-machine console.

Back up the configuration first:

sudo cp /etc/network/interfaces /etc/network/interfaces.backup

Find the physical interface name

Modern Linux interface names often look like:

enp4s0
eno1
ens18

To display all interfaces in a compact format, run:

ip -br address

You can also examine the hardware-backed interfaces under /sys/class/net:

for device in /sys/class/net/*/device; do
    interface="$(basename "$(dirname "$device")")"
    ip -br address show dev "$interface"
done

If you want to keep that command available, add it as a shell function in ~/.bashrc:

iphardware() {
    for device in /sys/class/net/*/device; do
        interface="$(basename "$(dirname "$device")")"
        ip -br address show dev "$interface"
    done
}

Reload the shell configuration:

source ~/.bashrc

Then run:

iphardware

The two original alias commands should not both be added because they define the same alias name. The second definition would replace the first one.

Test the secondary address temporarily

Before modifying the persistent configuration, assign the second address temporarily:

sudo ip address add 10.0.0.3/24 dev enp4s0

Verify both addresses:

ip -br address show dev enp4s0

The result should resemble:

enp4s0    UP    10.0.0.2/24 10.0.0.3/24

From another computer, test both addresses:

ping 10.0.0.2
ping 10.0.0.3

The ip address add command is the standard Linux operation for assigning another address to an interface. Linux ip-address manual

This temporary address will normally disappear after a reboot or network restart. The next step makes it persistent.

Configure both addresses permanently

Open the Debian network configuration:

sudo nano /etc/network/interfaces

My configuration looks like this:

auto lo
iface lo inet loopback

auto enp4s0
iface enp4s0 inet static
    address 10.0.0.2/24
    gateway 10.0.0.1
    dns-nameservers 1.1.1.1 8.8.8.8

    up ip address add 10.0.0.3/24 dev enp4s0
    down ip address del 10.0.0.3/24 dev enp4s0

Replace the following values with those appropriate for your network:

  • enp4s0
  • 10.0.0.2/24
  • 10.0.0.3/24
  • 10.0.0.1
  • The DNS server addresses

If your system manages DNS through another service, preserve its existing DNS configuration instead of copying this example verbatim.

What the up and down commands do

The primary address is configured here:

address 10.0.0.2/24

After ifupdown brings the interface online, it executes:

up ip address add 10.0.0.3/24 dev enp4s0

That adds the secondary address to the running interface.

Internally, the result looks like this:

enp4s0
├── 10.0.0.2/24
└── 10.0.0.3/24

When the interface is taken down, this command removes the secondary address:

down ip address del 10.0.0.3/24 dev enp4s0

Debian’s interfaces file supports commands that run during the interface lifecycle, as well as multiple configurations associated with an interface. Debian interfaces(5) documentation

Apply the configuration

Restarting an interface will interrupt its network connections. Do this from a console when possible:

sudo ifdown enp4s0
sudo ifup enp4s0

Alternatively, reboot during an appropriate maintenance window:

sudo reboot

After the system returns, confirm the addresses:

ip address show dev enp4s0

Or use the brief view:

ip -br address show dev enp4s0

You should see both:

10.0.0.2/24
10.0.0.3/24

How Linux directs the traffic

Suppose a client connects to:

10.0.0.2:22

The packet arrives through enp4s0. The kernel sees that its destination is 10.0.0.2 and passes it to the service listening on that address and port.

Now suppose a client connects to:

10.0.0.3:22

That packet arrives through the same interface and cable. The destination is different, so the kernel can pass it to a service bound to 10.0.0.3:22.

The interface does not decide which application receives the packet. The destination IP address, destination port, firewall rules, and listening sockets determine where it goes.

Bind each service to the correct address

Assigning two addresses does not automatically separate the services. Each service should listen on the intended address.

For example, OpenSSH can be configured to listen only on the primary address:

ListenAddress 10.0.0.2

Depending on the distribution, this setting may be placed in /etc/ssh/sshd_config or a file under /etc/ssh/sshd_config.d/.

Validate the SSH configuration before restarting it:

sudo sshd -t

A Docker service can publish a port on only the secondary address:

ports:
  - "10.0.0.3:22:22"

The exact internal container port depends on the application.

This distinction matters. If two services both try to listen on every address using 0.0.0.0:22, they can still conflict even though the server has two IP addresses.

A simple analogy

Think of the network adapter as one driveway:

enp4s0

The two IP addresses are two mailboxes beside that driveway:

10.0.0.2
10.0.0.3

The mail carrier uses the same driveway for every delivery. The address on each envelope determines which mailbox receives it.

A second mailbox does not require a second driveway.

Benefits of one adapter with two addresses

This configuration offers several advantages when both addresses are on the same network:

  • Only one default route is necessary.
  • Applications have fewer interface choices for outbound traffic.
  • There is no second same-subnet adapter to complicate ARP behavior.
  • Services can use distinct addresses while keeping the same port.
  • Cabling and switch configuration remain simple.
  • Firewall rules can target each destination address separately.
  • Additional addresses can be added without installing hardware.
  • The configuration is easier to understand and troubleshoot.

Multiple addresses are commonly useful for:

  • Separating services
  • Hosting multiple websites
  • Running multiple TLS services
  • Giving containers dedicated addresses
  • Migrating a service to a new address
  • High-availability virtual addresses
  • Testing network configurations

What this configuration does not provide

Two addresses on one interface do not provide:

  • Network-adapter redundancy
  • Additional physical bandwidth
  • Failover if the adapter or cable fails
  • Isolation between separate physical networks
  • Load balancing by themselves

If you need those features, consider bonding, teaming, VLANs, multiple routing tables, or physically separate networks instead.

Final thoughts

My final configuration keeps the benefit I wanted—distinct IP addresses for separate SSH services—while removing the complexity introduced by two physical interfaces on the same subnet.

Instead of asking applications and the routing table to choose between two adapters, the server now has one clear path to the network and two addresses on that path:

One adapter
One cable
One gateway
Two IP addresses

For a server that needs multiple service addresses but not multiple physical network paths, this is often the simpler and more predictable design.