How to Set Up an SDN Simple Zone in Proxmox VE (Isolated Network With NAT and DHCP)

If you've poked around Proxmox VE's networking options, you've probably found VLANs and VXLAN overlays. Both are useful, and both assume you already have a managed switch or multiple nodes talking to each other. But what if you just want a private network that lives entirely inside your Proxmox host, hands out its own IP addresses, and still lets your VMs reach the internet? That's what an SDN Simple zone is for, and almost nobody covers it because it looks unglamorous next to VXLAN. It's also one of the fastest ways to spin up an isolated lab network without touching a single switch port.

What You Will Learn

• What an SDN Simple zone actually is and how it's different from a regular Linux bridge
• Why you'd use one instead of just plugging everything into vmbr0
• How to create a Simple zone, a VNet, and a subnet with DHCP and NAT enabled
• How to attach a VM or LXC container to your new network
• The errors people run into most often, and how to fix them

What Is This Feature?

SDN stands for Software-Defined Networking. In Proxmox VE, it's a system built into the Datacenter view that lets you define networks in software instead of wiring them together by hand on each node. Before SDN existed, if you wanted a new network you'd edit /etc/network/interfaces directly and hope you didn't typo a bridge name. SDN gives you a GUI for the same job, plus a few network types that plain bridges can't do on their own.

A Simple zone is the most basic of those types. It creates a bridge that isn't tied to any physical network card. Nothing about it touches your LAN, your switch, or your router. Every VM or container you plug into it lands on the same private subnet, and if you enable NAT (more on that below), that subnet gets internet access routed through the Proxmox host itself.

This is different from the VLAN-aware bridge setup, which tags traffic and depends on a switch that understands VLAN tags. It's also different from VXLAN, which builds tunnels between multiple Proxmox nodes over your existing network. A Simple zone doesn't need any of that. It stays local to one host, which is exactly why it's the easiest one to start with.

Why Would You Use It?

The honest answer: most homelab users reach for this the first time they want to isolate something. Say you're testing a piece of software you don't trust, or running a batch of VMs for a course where you don't want them anywhere near your real LAN. Plugging them into vmbr0 puts them on the same network as your NAS, your router, and everything else. A Simple zone keeps them behind their own private subnet instead.

There's a second, more practical reason: DHCP. If you've ever built a lab network the old-fashioned way, you know the pain of manually setting a static IP on every single VM. A Simple zone with DHCP enabled hands out addresses automatically, the same way your home router does. Boot ten VMs and all ten come up networked, no console typing required.

It's also worth being clear about what it's not for. If you need VMs on two different Proxmox nodes to talk to each other over this network, Simple zones won't do that — traffic stays local to each host. For that you'd want a VXLAN zone instead. And if you're trying to segment an existing physical LAN by department or VLAN ID, a VLAN-aware bridge is the right tool, not this one.

Prerequisites

Before you start, make sure you have:

• Proxmox VE 8.1 or newer. SDN ships installed by default from 8.1 onward — on older 7.x or early 8.0 installs you'd need libpve-network-perl and ifupdown2 added manually, but there's little reason to still be on those versions.
• Root or admin access to the Proxmox web interface (https://your-server-ip:8006).
• The dnsmasq package, which is what actually hands out DHCP leases and does the NAT translation. We'll install it in Step 1.
• A rough idea of what private subnet you want to use. 10.0.0.0/24 works fine unless it collides with something else on your network — it won't, since this subnet never actually leaves the host.

Step-by-Step Tutorial

Step 1: Install and disable the system dnsmasq service

Proxmox VE's SDN uses its own instance of dnsmasq per zone, so the system-wide one needs to be installed but not running on its own. SSH into your Proxmox host and run:

apt update
apt install dnsmasq
systemctl disable --now dnsmasq

That last command stops the default dnsmasq service and keeps it from starting again on boot. Don't skip this — if the system service is still running, it'll fight with the per-zone instance SDN creates later, and you'll get DHCP leases that don't match what you configured.

Step 2: Create the Simple zone

In the Proxmox web interface, go to Datacenter → SDN → Zones, then click Add → Simple. Give it an ID — something short like simple1 is fine, since this is just an internal label. Leave the rest of the defaults alone for now and click Create.

You'll notice the zone doesn't do much by itself yet. That's expected. A zone on its own is just a container for the networks you're about to build inside it.

Step 3: Create a VNet inside the zone

Switch to the VNets tab and click Create. Give it a name — VNet names are limited to 8 characters, so something like vnet0 works well. Select the zone you just created from the dropdown, then save.

A VNet is the actual virtual network your VMs will plug into, similar to how a VM plugs into vmbr0 today. The zone defines the type of network; the VNet is the specific instance of it you're going to use.

Step 4: Add a subnet with DHCP and NAT

Click on your new VNet, then go to its Subnets tab and click Create. Fill in:

• Subnet: 10.0.0.0/24
• Gateway: 10.0.0.1

Tick the SNAT checkbox — this is what lets your isolated VMs reach the internet by routing their outbound traffic through the Proxmox host's own IP. Then open the DHCP Ranges tab in the same dialog and add a range, for example a start address of 10.0.0.50 and an end address of 10.0.0.200. That leaves 10.0.0.2 through 10.0.0.49 free if you ever want to hand out static addresses by hand.

Step 5: Apply the configuration

Go back to the main SDN panel (the top-level entry in the SDN menu, not Zones or VNets) and click Apply. This is the step people forget. Everything you've done so far is just a pending configuration — nothing is actually live until you apply it. Watch the task log that pops up; it should finish with a green "OK" status within a few seconds.

Step 6: Allow DHCP and DNS through the firewall (if you use it)

If you have the Proxmox firewall enabled at the datacenter level, dnsmasq's traffic will get blocked by default. Go to Datacenter → Firewall and add two rules:

• Direction in, Action ACCEPT, Macro DHCPfwd, Interface set to your VNet name (vnet0)
• Direction in, Action ACCEPT, Macro DNS, Interface set to your VNet name, destination address set to your gateway IP (10.0.0.1)

Skip this step if you don't run the datacenter firewall — plenty of homelab setups don't.

Step 7: Attach a VM or container and test it

Open a VM's hardware settings (or a container's network settings), edit the network device, and change the bridge from vmbr0 to your VNet name, vnet0. For an LXC container, set IPv4 to DHCP on that same screen. For a VM, boot it and set the guest OS network config to DHCP as you normally would.

Boot the guest and check what it picked up. On Linux, ip a should show an address somewhere in your 10.0.0.50–200 range. Try ping -c 4 1.1.1.1 — if SNAT is working, you'll get replies even though this VM has never touched your actual LAN.

Commands Explained

You generally won't need to touch the underlying config files, but it helps to know they exist. Proxmox stores your Simple zone in /etc/pve/sdn/zones.cfg and your subnet, including the DHCP range and SNAT flag, in /etc/pve/sdn/subnets.cfg. Both are plain text and get rewritten automatically whenever you click Apply in the GUI, so there's rarely a reason to hand-edit them unless you're adding something the interface doesn't expose yet, like a custom DNS server for the zone.

Common Errors

VM gets no IP address at all. Almost always this means Step 5 got skipped — the configuration was saved but never applied. Go back to the SDN panel and click Apply, then reboot the guest's network interface.

"dnsmasq[xxxx]: failed to create listening socket" in the system log. This is the classic symptom of the system dnsmasq service still running alongside the SDN-managed one. Run systemctl status dnsmasq — if it shows active, go back to Step 1 and disable it.

DHCP works but the VM can't reach the internet. Double check that SNAT is actually ticked on the subnet, not just configured. It's easy to fill in the DHCP range and forget the checkbox above it. Also confirm the firewall rules from Step 6 are in place if the datacenter firewall is on.

"unable to find sdn config" or a red X after clicking Apply. This usually points to a leftover reference — for example a VNet that's still assigned to a VM but was deleted from the zone. Check the SDN task log for the specific error line; it names the offending object directly.

Troubleshooting

When something isn't working, work from the host outward instead of guessing. First, confirm the bridge actually exists on the Proxmox host itself with ip a show vnet0. If it's not listed, the Apply step didn't go through cleanly — check Datacenter → SDN for a pending or failed task.

If the bridge exists but the guest still isn't getting an address, check that the VM or container's network device is actually pointed at vnet0 and not still sitting on vmbr0. This is the single most common mistake, and it's an easy one to make if you edited the wrong VM in a multi-VM lab.

For containers specifically, a stopped-and-restarted container sometimes caches its old network config. Stop it fully (not just reboot from inside the guest) and start it again from the Proxmox GUI.

If none of that turns anything up, tail the system log while you apply the SDN config: journalctl -f in one terminal, then hit Apply in the GUI from another browser tab. You'll usually see dnsmasq or the ifupdown2 network reload complain about the exact thing that's wrong.

Best Practices

Keep your Simple zone subnets out of the address range your physical LAN uses. If your home network is already 10.0.0.0/24, pick something else for the zone, like 10.50.0.0/24, so there's no confusion later if you ever bridge the two.

Name VNets by purpose, not by number. testlab tells you more six months from now than vnet3 does — and remember you're limited to 8 characters, so short and specific beats generic.

Don't enable SNAT on a zone you're deliberately trying to keep offline. If the whole point is an air-gapped test network, skip the SNAT checkbox entirely and the VMs simply won't have a route out, which is often exactly what you want.

Finally, document your DHCP range somewhere outside Proxmox itself, even just a text note. It's a small thing, but six months later you won't remember whether you left .2 through .49 free for static assignments or not.

Frequently Asked Questions

Do I need a managed switch for this?

No. That's the entire point of a Simple zone — it never touches physical network hardware. VLAN-aware bridges and VXLAN zones need switch support; Simple zones don't.

Can VMs on two different Proxmox nodes share a Simple zone?

No, and this trips people up. Simple zones are local to each node. If you need cross-node connectivity in the same virtual network, you want a VXLAN zone instead.

Is this the same thing as NAT networking in VirtualBox or VMware?

Conceptually, yes — it's a private subnet with outbound access via the host. The mechanics are different under the hood, but if you've used NAT mode in a desktop hypervisor before, the behavior will feel familiar.

What happens if I don't tick SNAT?

You get an isolated network with no route to the internet or your LAN. VMs on it can talk to each other and get DHCP leases, but nothing gets in or out. That's useful for security testing or air-gapped labs.

Can I run DHCP without SNAT, or SNAT without DHCP?

Yes, they're independent settings. Some people run SNAT-only zones and assign static IPs by hand instead of using DHCP at all.

Conclusion

A Simple zone won't show up on any feature comparison chart next to Ceph or HA clustering, and that's kind of the point — it's not trying to impress anyone. It solves a genuinely common problem: "I want a private network for my VMs that just works," without a switch, a second node, or a pile of manual IP configuration. Once you've set one up, you'll probably find yourself reaching for it constantly, for test labs, throwaway VMs, and anything you'd rather keep off your main LAN.