How to Add a Second Network Interface to a Virtual Machine in Proxmox VE

Introduction

One network card on a VM is fine right up until it isn't. Maybe you're building a router VM like OPNsense that needs a WAN side and a LAN side. Maybe you want to put your NAS VM on a dedicated storage network so backups don't choke your regular traffic. Or maybe a piece of software you're running just expects two interfaces and won't start without them.

Whatever the reason, adding a second network interface to a VM in Proxmox VE is a five-minute job in the GUI. Getting the guest operating system to actually notice and use that new interface is the part that trips people up, and that's really what this guide is about.

Everything below was tested on Proxmox VE 9.2, but the same steps work on 8.x too — the VM hardware panel hasn't changed in any way that matters here.

What You Will Learn

• What a virtual network interface actually is inside a VM
• How to add a second NIC through the Proxmox web GUI
• How to attach it to the right bridge, VLAN, or firewall setting
• How to bring the new interface up inside Linux and Windows guests
• The errors people hit most often, and how to fix them

What Is This Feature?

Every VM in Proxmox gets at least one virtual network interface card, usually shown as net0 in the hardware list. That's the thing that connects your VM to a bridge on the host, which in turn connects it to your physical network. A second NIC — net1 — is just another one of these, wired to whatever bridge you tell it to use.

The important part: net0 and net1 don't have to go to the same place. net0 might connect to vmbr0, your regular LAN bridge, while net1 connects to vmbr1, an isolated bridge with no physical NIC attached at all. From the VM's point of view, it just sees two network cards. It has no idea one of them leads nowhere outside the host.

This is exactly how router VMs work. OPNsense or pfSense running inside Proxmox usually has one NIC facing your actual internet connection (WAN) and a second NIC facing an internal, isolated bridge that all your other VMs plug into (LAN). The router VM does the routing between the two; Proxmox just provides the wiring.

Why Would You Use It?

A few situations come up again and again:

• Router or firewall VMs — OPNsense, pfSense, or a plain Linux box doing routing needs at least two interfaces to separate WAN from LAN.
• Storage or backup traffic separation — giving a NAS VM a second NIC on its own bridge keeps large file transfers off your management network.
• VLAN segmentation without extra hardware — you can hand a VM two interfaces on two different VLANs instead of trunking everything through one NIC and fighting with the guest's VLAN configuration.
• Testing network-dependent software — some applications (load balancers, VPN gateways, certain monitoring tools) genuinely expect to see multiple interfaces.

Honestly, if you're just running a Plex server or a Home Assistant instance, you'll never need this. One NIC is enough for the vast majority of VMs. This is a tool for a specific job, not something to bolt onto every VM "just in case."

Prerequisites

Before you start, make sure you've got:

• A Proxmox VE 8.x or 9.x host with at least one VM already created
• Root or a user account with the VM.Config.Network permission
• At least one bridge already configured for the new NIC to attach to — this can be your existing vmbr0, or a separate bridge like vmbr1 if you want the new interface isolated
• The VM shut down (you can add a NIC to a running VM, but the guest won't see it until it's rebooted or you hot-add it manually, which we'll cover)

If you don't have a second bridge yet and you want one, go to Datacenter → your node → System → Network, click Create → Linux Bridge, and leave Bridge ports blank if you want it fully isolated with no physical NIC attached. Apply the configuration and you're set.

Step-by-Step Tutorial

Step 1: Open the VM's Hardware tab

In the Proxmox web interface, click your VM in the left-hand tree, then open the Hardware tab. You'll see your existing network device listed as Network Device (net0).

Step 2: Add the new network device

Click Add at the top of the Hardware panel and choose Network Device. A dialog box opens with a handful of fields:

• Bridge — pick which bridge this NIC connects to. This is the field people get wrong most often; double-check it before clicking Add.
• Model — leave this on VirtIO (paravirtualized) unless you have a specific reason not to. It's faster and lighter on CPU than emulating a real network card.
• VLAN Tag — only fill this in if the bridge is a VLAN-aware trunk and you need this NIC on a specific VLAN. Leave it blank otherwise.
• Firewall — checked by default. This enables the per-VM firewall on that interface, which you can configure separately under the VM's Firewall tab.
• MAC Address — leave on auto unless you need a specific MAC for a DHCP reservation.

Click Add. You'll now see both net0 and net1 listed in the Hardware tab.

Step 3: Start (or restart) the VM

If the VM was already running, it needs a reboot for most guest operating systems to notice the new hardware. Shut it down properly (don't just hard-stop it) and start it back up.

Step 4: Configure the interface inside a Linux guest

This is the step everyone forgets, and it's the reason people end up thinking "the second NIC doesn't work" when it actually does — the guest OS just hasn't been told to use it.

SSH into the guest and check what the kernel sees:

ip a

You should now see a second interface, usually named ens19 or eth1 depending on the distro and naming scheme. It'll show as DOWN because nothing has configured it yet.

On Debian or Ubuntu using netplan (the default on modern Ubuntu Server), edit /etc/netplan/50-cloud-init.yaml or create a new file in /etc/netplan/ and add the second interface:

network:
  version: 2
  ethernets:
    ens19:
      dhcp4: true

Then apply it:

sudo netplan apply

On older Debian-style systems using /etc/network/interfaces, add:

auto ens19
iface ens19 inet dhcp

Swap dhcp for a static block with address, netmask, and gateway lines if the second network doesn't have a DHCP server — which is common on an isolated bridge with nothing else attached.

Step 5: Configure the interface inside a Windows guest

Windows is easier here. Open Network Connections (right-click the network icon in the system tray, or run ncpa.cpl) and you'll see a second adapter, usually named Ethernet 2. If it doesn't get an IP automatically, right-click it, go to Properties → Internet Protocol Version 4, and set a static address manually.

If the adapter doesn't show up at all, you're almost certainly missing the VirtIO network driver. Install the VirtIO driver package from the ISO Proxmox provides (virtio-win.iso), then rescan for hardware changes in Device Manager.

Step 6: Verify connectivity

From the guest, ping something reachable only through the new interface's network. From the Proxmox host, you can also confirm the NIC is attached correctly by running:

qm config <vmid>

and checking that net1 shows the bridge and model you expect.

Commands Explained

Command	What It Does
ip a	Lists all network interfaces the guest kernel currently sees, along with their IP addresses and up/down state.
sudo netplan apply	Applies any changes made to netplan YAML config files without needing a reboot.
qm config <vmid>	Prints the full hardware configuration of a VM from the Proxmox host, including every network device and which bridge it's attached to.
ip link show	Run on the Proxmox host itself, this shows all bridges and physical NICs, useful for confirming a bridge actually exists before you attach a VM to it.

Common Errors

"Bridge 'vmbrX' does not exist" — you tried to attach a NIC to a bridge that hasn't been created yet, or you mistyped the name. Go check Datacenter → Node → System → Network and confirm the exact bridge name.

Second interface shows up in ip a but never gets an IP — the interface exists at the hardware level but nothing has configured it in netplan or /etc/network/interfaces. This is the single most common issue, and it's not a Proxmox problem at all — it's a guest OS configuration step people skip.

Windows guest doesn't show a second adapter — almost always a missing VirtIO driver. Mount virtio-win.iso as a second CD-ROM drive on the VM and install the NetKVM driver from it.

Both NICs get a default route and traffic goes out the wrong one — if both interfaces get an IP via DHCP, Linux and Windows will both try to set a default gateway, and routing gets unpredictable. Only let one interface hold the default route; configure the second one without a gateway if it's meant purely for a private network.

Troubleshooting

If the new NIC isn't behaving, work through it in this order:

1. Confirm the hardware exists: check the VM's Hardware tab in Proxmox for net1.
2. Confirm the guest kernel sees it: run ip a (Linux) or check Device Manager (Windows).
3. Confirm the bridge itself is up on the host: ip link show vmbr1 should show state UP.
4. Confirm the guest's network config actually references the right interface name — a copy-pasted netplan config from another machine sometimes references the wrong interface.
5. Check the per-VM firewall isn't silently blocking traffic on that NIC. It's easy to forget the Firewall tab exists per-interface, not just per-VM.

One more thing that catches people out: cloning a VM that already has two NICs. Proxmox generates new MAC addresses on clone, which is correct, but if your guest OS or DHCP server was doing anything based on the old MAC (a static lease, for example), that mapping breaks silently.

Best Practices

• Stick with VirtIO for the network model unless a guest OS specifically lacks driver support for it (some old legacy operating systems don't).
• Name your bridges something you'll actually remember six months from now — vmbr1 tells you nothing; a comment in your own notes saying "vmbr1 = isolated LAN for router VM" saves a lot of head-scratching later.
• Only let one interface carry the default gateway. Two default routes is how you end up debugging "intermittent" connectivity that isn't intermittent at all — it's just alternating.
• Leave the firewall checkbox enabled unless you have a specific reason to disable it, and actually go configure rules on the Firewall tab rather than leaving it enabled with no rules (which does nothing useful).
• For router VMs specifically, keep WAN and LAN on separate bridges rather than using VLAN tags on a single bridge — it's simpler to reason about and harder to misconfigure.

Frequently Asked Questions

Do I need to shut down the VM to add a second NIC?
Not to add it in Proxmox — you can add the hardware to a running VM. But most guest operating systems won't detect it until you reboot the guest.

Can two network interfaces on the same VM use the same bridge?
Yes, though there's rarely a reason to. It's normally done to separate traffic types (management vs. VLAN-tagged, for example) rather than for redundancy — Proxmox doesn't do NIC bonding at the VM level the way it does on the host.

Will adding a second NIC slow down my VM?
No, an unused or lightly used VirtIO NIC has negligible overhead. The cost only shows up if you're actually pushing heavy traffic through both interfaces at once.

My VM already has a static IP on net0 — will adding net1 break it?
No. net0's configuration is untouched. The new interface is entirely separate and won't interfere with existing network settings unless you explicitly reconfigure the guest's routing.

Can I remove a second NIC later if I don't need it anymore?
Yes — go to the Hardware tab, select the network device, and click Remove. Just clean up the guest OS's network config afterward so it doesn't sit around referencing an interface that no longer exists.

Conclusion

Adding a second network interface in Proxmox is genuinely one of the simpler hardware changes you can make — the GUI part takes about thirty seconds. The part worth remembering is that Proxmox handing the VM a new virtual NIC and the guest operating system actually using it are two separate things, and almost every "it's not working" report traces back to skipping the guest-side configuration in Step 4 or 5.

Once you've done it once, on a router VM or a storage-segregated server, it becomes second nature — and it opens up a lot of network designs that just aren't possible with a single interface per VM.