Introduction
If you have ever opened your Proxmox VE network settings and stared at the empty IPv6 fields wondering whether you should bother, you are not alone. Most homelab guides skip IPv6 entirely, and Proxmox's own web interface doesn't hold your hand through it the way it does for a plain static IPv4 address.
That's a shame, because a lot of home internet connections and nearly every dedicated server now ship with usable IPv6 out of the box. Leaving it unconfigured means your VMs can't be reached over IPv6, your host doesn't advertise itself properly on modern networks, and you end up troubleshooting "why can't I ping this from my phone on 5G" issues that have nothing to do with Proxmox and everything to do with a missing address family.
This guide walks through getting IPv6 working on a Proxmox VE host, and then extending it down to your virtual machines and containers, using the two setups you'll actually run into: a home connection where your router hands out addresses automatically, and a routed block from a hosting provider where you configure everything by hand.
What You Will Learn
- What IPv6 actually changes about how your Proxmox host talks to the network
- The difference between SLAAC (automatic addressing) and a static IPv6 assignment
- How to edit
/etc/network/interfacesto add IPv6 to yourvmbr0bridge - How to apply the change without a reboot
- How to get IPv6 working inside VMs and LXC containers, including the NDP proxy trick that dedicated server users almost always need
- The errors people run into most often, and how to actually fix them
What Is This Feature?
IPv6 is the successor to the IPv4 addressing you already know, the one that looks like 192.168.1.10. An IPv6 address looks like 2001:db8:abcd:1234::2 instead, and there are so many possible addresses that running out is not a practical concern the way it is with IPv4. Most networks today run "dual stack," meaning both IPv4 and IPv6 work at the same time on the same interface.
There are two ways a device typically gets an IPv6 address:
| Method | How it works | Where you'll see it |
|---|---|---|
| SLAAC (Stateless Address Autoconfiguration) | Your router sends out periodic Router Advertisements (RAs), and devices build their own address from that information automatically | Home routers, most consumer ISPs |
| Static assignment | You are handed a fixed address or block and type it in yourself | Dedicated servers, VPS providers, some business ISPs |
Proxmox VE's bridge interface, vmbr0, is just a virtual network switch running on your host. It already carries your IPv4 traffic to your VMs, and it can carry IPv6 the exact same way once you tell it to.
Why Would You Use It?
Honestly, plenty of homelabbers get by fine on IPv4 and NAT for years. But there are a few concrete reasons to bother with IPv6:
- Your ISP may be phasing out IPv4, or already giving you a CGNAT address that makes inbound IPv4 connections impossible without a VPN or tunnel
- Dedicated server providers like Hetzner and OVH route a full IPv6 /64 to every server for free, and it's wasted if you never use it
- You want each VM to be individually reachable from the internet without juggling port forwards
- Some modern services and mobile carriers prefer or require IPv6 for certain features
If none of that applies to you and your network is a straightforward home LAN behind a router doing NAT, you can absolutely skip this and your Proxmox box will run fine. This isn't one of those "you must do this" settings.
Prerequisites
Before you start, you'll want:
- A working Proxmox VE installation (this guide applies to 8.x and 9.x) with root or SSH access
- Knowledge of what kind of IPv6 you have — check your router's status page for a "SLAAC" or "IPv6" section, or check your hosting provider's control panel for a routed IPv6 block
- Comfort editing a plain text file over SSH, since the GUI only covers static addressing, not SLAAC
- A few minutes where a brief network hiccup on the host is acceptable, in case a typo needs correcting
Step-by-Step Tutorial
Step 1: Back up your current network config
Before touching anything, make a copy. This one file controls whether your host is reachable at all, so a backup costs you nothing and saves you a trip to the physical console later.
cp /etc/network/interfaces /etc/network/interfaces.bakStep 2: Figure out which path applies to you
Log into your router's admin page (commonly at 192.168.1.1 or similar) and look for an IPv6 status page. If it lists a delegated prefix and shows "SLAAC" or "Router Advertisement" as enabled, use Path A below. If your provider emailed you a fixed IPv6 address and gateway when you signed up, or your hosting control panel shows a routed /64, use Path B.
Step 3 (Path A): SLAAC on a home network
Open /etc/network/interfaces with your editor of choice:
nano /etc/network/interfacesFind your bridge and add an inet6 line underneath the existing IPv4 configuration:
auto vmbr0
iface vmbr0 inet static
address 192.168.1.50/24
gateway 192.168.1.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
iface vmbr0 inet6 auto
accept_ra 2The accept_ra 2 line matters more than it looks. By default, Linux disables Router Advertisement processing on interfaces that are also acting as a router (which a Proxmox bridge technically is), so without this line, SLAAC often silently does nothing.
Step 4 (Path B): Static IPv6 on a dedicated server
For a routed block, add a static inet6 stanza instead. Most providers use a link-local gateway, which looks unusual if you've never seen one, but it's normal:
iface vmbr0 inet6 static
address 2001:db8:abcd:1234::2
netmask 64
gateway fe80::1Replace the address with the one your provider assigned you, and double check the gateway. Some providers use a real global address as the gateway instead of a link-local one, so read your welcome email carefully rather than assuming.
Step 5: Apply the change
Because Proxmox VE ships with ifupdown2 by default, you don't need to reboot. Run:
ifreload -aThis re-reads the interfaces file and applies only what changed. If something is badly malformed, ifreload will usually tell you immediately instead of leaving you locked out.
Step 6: Verify the host has an address
ip -6 addr show vmbr0
ip -6 route showYou're looking for a global address (starts with 2 or 3, not fe80) and a default route. If you only see an fe80:: link-local address, IPv6 routing hasn't come up yet — jump to the Troubleshooting section below.
Step 7: Extend IPv6 down to a VM
For a Linux guest, the simplest path is Cloud-Init, which is a small program that runs on first boot to configure a VM's network, hostname, and SSH keys automatically, so you don't have to console into every new VM by hand. In the VM's Cloud-Init tab, set the IPv6 field to auto for SLAAC or a specific address for static, matching whatever you did on the host.
For a VM you're configuring manually, edit its network config the same way you would on any Debian or Ubuntu box — add an inet6 block to /etc/network/interfaces inside the guest, or the equivalent in Netplan if that's what the distro uses.
Step 8: Handle NDP proxying for routed blocks
This step trips up almost everyone on a dedicated server, so pay attention here. If your provider routes a /64 to your server's single MAC address, your VMs technically have valid addresses from that block, but the upstream router has no idea those addresses live behind your host — it only knows about your physical NIC's MAC. The fix is to enable NDP proxying so your host answers neighbor discovery requests on behalf of its VMs:
sysctl -w net.ipv6.conf.all.proxy_ndp=1
ip -6 neigh add proxy 2001:db8:abcd:1234::10 dev vmbr0Run that second command once per VM address, or automate it with ndppd if you're managing more than a handful of VMs. Skip this step and your VMs will have an IPv6 address that looks correct but simply can't be reached from outside.
Commands Explained
| Command | What it does |
|---|---|
ifreload -a | Applies changes in /etc/network/interfaces live, without a reboot (requires ifupdown2) |
ip -6 addr show vmbr0 | Lists the IPv6 addresses currently bound to the bridge |
ip -6 route show | Shows the IPv6 routing table, including whether a default route exists |
sysctl -w net.ipv6.conf.all.proxy_ndp=1 | Turns on NDP proxying so the host can answer neighbor discovery on behalf of VMs |
ip -6 neigh add proxy <address> dev vmbr0 | Registers a specific VM address for NDP proxying |
ping -6 address | Tests basic IPv6 reachability, the v6 equivalent of a normal ping |
Common Errors
"RTNETLINK answers: File exists" during ifreload -a usually means you left a duplicate address or route defined twice, often from copying an example without removing an old line underneath it.
VM shows an IPv6 address but has zero connectivity is almost always the NDP proxy problem described in Step 8, not a firewall issue. People spend hours checking firewall rules before realizing the upstream router simply doesn't know the VM exists.
Only a link-local fe80:: address appears, no global address typically means accept_ra is still at its default value of 0 on the bridge, which blocks SLAAC from doing anything even though the interfaces file looks correct.
"Duplicate address detected" in the system log means two devices on the network are claiming the same address — check whether you copy-pasted a static address from a guide instead of using the one actually assigned to you.
Troubleshooting
Start by confirming Router Advertisements are actually reaching the host at all:
tcpdump -i vmbr0 icmp6 and ip6[40] == 134If you see packets flowing while this runs, RAs are arriving and the problem is on your config side. If nothing shows up after 30 seconds or so, the problem is upstream — check that your router has SLAAC or "IPv6 delegation" actually turned on, since a surprising number of consumer routers ship with it disabled.
Next, check the live sysctl value rather than trusting what's in the file:
cat /proc/sys/net/ipv6/conf/vmbr0/accept_raA value of 0 here, even after adding accept_ra 2 to your interfaces file, usually means the change hasn't been applied yet — run ifreload -a again and recheck.
For VMs that can reach the host but nothing beyond it, run ip -6 route get pointed at an external address like 2606:4700:4700::1111 from inside the guest. If it fails immediately, the guest's own default route is missing rather than anything on the Proxmox side.
Best Practices
Keep IPv4 configured alongside IPv6 rather than switching over entirely. Dual stack is the standard for a reason — plenty of services, VPNs, and monitoring tools still assume IPv4 exists, and you don't want your Proxmox host unreachable because one upstream link had a bad day.
If you enable the Proxmox firewall, remember that IPv6 rules are separate from IPv4 ones. A firewall configured only for IPv4 will leave your IPv6 addresses either fully open or fully blocked depending on your default policy, neither of which is what you want without checking first.
Write down your allocation somewhere outside the server itself. I've seen people lock themselves out of a dedicated server by fat-fingering an IPv6 address with no record of the correct one to fall back on, and providers can take a while to respond to a support ticket for something this specific.
Give your Proxmox host's own management address a static assignment even if you use SLAAC for VMs. You don't want the address of your web interface changing after a reboot.
Frequently Asked Questions
Do I need IPv6 for Proxmox VE to work?
No. Proxmox runs fine on IPv4 only, and most homelabs never touch IPv6 at all.
Can I use IPv6 for cluster communication between Proxmox nodes?
Yes, Corosync (the service that keeps cluster nodes in sync with each other) supports IPv6 links, but most people stick with IPv4 for cluster traffic since it's simpler to keep stable.
Why does my phone see the VM over IPv6 but my laptop doesn't?
This is almost always a caching issue on one device, or one of them is on a network that doesn't yet route IPv6 to that host. Try flushing the neighbor cache with ip -6 neigh flush all on the client before assuming Proxmox is at fault.
Does every VM need its own IPv6 address, or can they share the host's?
Each VM should get its own address from your allocation. Sharing the host's single address defeats the point of having a routed block in the first place.
Will removing IPv6 later break anything?
Not usually. You can delete the inet6 stanza and run ifreload -a to fall back to IPv4 only, as long as nothing you set up specifically depends on the v6 address.
Conclusion
IPv6 on Proxmox VE isn't complicated once you know which of the two paths applies to your setup — SLAAC for most home connections, static for routed provider blocks. The part that actually trips people up isn't the syntax, it's the NDP proxy step that dedicated server users need and homelabbers never even hear about.
Take it one bridge at a time: get the host itself working first, confirm a global address and a default route, and only then move on to VMs. Skipping straight to guest configuration before the host is solid just multiplies the number of places something can be wrong.