Proxmox SDN: A Complete Guide to Setup and Usage

In Proxmox VE, SDN (Software Defined Networking) is a subsystem for managing virtual networks that was added starting with version 7. It simplifies working with network infrastructure inside a cluster and lets you build flexible, isolated, and scalable networks for virtual machines and containers.

Key Points About SDN in Proxmox

#

1. Why You Need SDN

#

• Simplifies creating private networks inside a Proxmox cluster.
• Lets you isolate traffic between different users or projects.
• Enables scaling the network across multiple cluster nodes.
• Automates the configuration of routing, NAT, DHCP, and DNS.

2. SDN Components in Proxmox

#

• Zones - logical network segments (for example, for different projects or clients).
• VNet (virtual networks) - created within zones and define L2/L3 topology.
• Controllers - manage network settings (for example, via EVPN, VXLAN, BGP).
• IPAM/DNS - a built-in system for managing IP addresses and names.

3. Supported Zone Types

#

• Simple (VLAN-aware bridge) - a regular network based on bridge + VLAN.
• VXLAN - an overlay network with tunneling over IP.
• EVPN - an advanced option for integrating with a “datacenter-style” network via BGP.
• QoS zones - support for bandwidth limits.

4. Example Use Case

#

1. You have a Proxmox cluster with 3 nodes.
2. You create an SDN zone of type VXLAN so that VMs on different hosts end up on the same L2 network.
3. Proxmox automatically brings up tunnels between the nodes, and the VMs/containers see each other as if they were on the same local network.

Competitors

#

SDN in Proxmox lets you build cloud-like scenarios similar to OpenStack/VMware NSX, but in a much simpler form.

About This Article

#

In this article, which serves as a companion to the video at the top of the page, I’ll try to cover a basic SDN configuration that will give us an understanding of how SDN works in Proxmox.

Prerequisites

#

SDN has been available in Proxmox by default starting with Proxmox 8.1. If your system is older, you’ll first need to run the following command in your node’s shell to install the required packages:

apt update
apt install libpve-network-perl

After installation, make sure the following line is present at the end of the /etc/network/interfaces configuration file on all nodes (if you have a cluster), so that the SDN configuration is included and activated:

source /etc/network/interfaces.d/*

DHCP integration into PVE’s built-in IP address management stack currently uses dnsmasq to hand out DHCP leases. To use this feature, you need to install the dnsmasq package on each node.

apt update
apt install dnsmasq
# disable default instance
systemctl disable --now dnsmasq #disable the dhcp server so it doesn't conflict with your router

Initial SDN Configuration

#

In the Datacenter menu, click the SDN tab. There you’ll see a list of networks that currently exist. The number of networks will depend on the number of nodes. In my case there’s only one local network.

Now let’s create our first (well, technically second) local network. Go to the Zones section, click add, and you’ll see that you can choose from different zone types.

Since we’re going with a basic/simple configuration, we’ll choose simple.

For the ID I’ll use youtube. I’ll leave the MTU value at its default. Note that in some regions there can be issues with the default MTU value of 1500. You can try a value of 1460 as an alternative. In the same menu, I select automatic configuration for DHCP. Click add.

In the final window we see the settings for our zone. Now let’s go to the VNET section and click create.

Choose the name and alias you want. Now select the newly created zone. Leave everything else at its default, because as mentioned above, in this article we’re doing only a basic setup - no VLANs or anything like that.

We’ve now created our first virtual network. After creating it, a new subnet menu appeared. In the vnet menu, select our newly created network and go to the subnet menu. Click create. Now we’ll create our subnet, which will be isolated from our home network.

Let’s set the address of our subnet. I like odd numbers, so I’ll use 11.11.11.0/24 (though this isn’t really correct for production use). The gateway address is 11.11.11.1. We need to check the snat box. This lets all devices on the subnet share a single external IP address so they can reach the outside world. We won’t touch DNS.

Now we need to set the address range in the DHCP menu. No need to reinvent the wheel - let’s set a range from 100 to 199. Click create.

We’ve now created a zone, vnet, and subnet. Now, to apply the changes, go to the SDN menu and click apply. Now, when you go to the network list of your node, you’ll see that a newly created network has appeared alongside localnetwork. That’s it - we’ve taken the first steps toward building the foundation of our small SDN.

To test how it all actually works, let’s create a simple, empty Ubuntu-based LXC container for testing purposes. We’ll do everything as usual, except for one small but very important detail. When we choose the bridge that our container will use, in the bridge section

we select not vmbr0, which we’re used to, but our newly created network. Leave everything else as usual. You can now go back to Datacenter, and in the IPAM submenu you’ll see the network data for the newly created container.

In our case, it now has the IP address 11.11.11.100. After creating and starting the container, we should check whether it has access to the outside world. You could do this with a simple ping <some resource> command, but it’s enough to just run apt update - if everything’s fine, the container will check for updates and give you a result. That alone confirms that your container is fully functional and has access to the outside world. Now let’s confirm that our container is not accessible from the outside world. From any machine on your local network - but not from the Proxmox shell - ping our container: ping 11.11.11.100, and the response will be silence. That’s because, as I mentioned at the start of the article, our container sits on a network (SDN) that’s isolated from the outside world. Note that if you ping the container from your node’s shell, it will actually respond. That’s because the network was created inside our node, and we haven’t configured any firewall rules yet, so the container pings just fine from the node. However, configuring the firewall inside Proxmox is a topic for another article.