<\/span><\/h3>\nIf each VM must be reachable on its own IPv4 address<\/strong> (e.g., cPanel hosting, SSL termination per VM, mail servers, etc.), then you\u2019ll need an IP pool from your provider. However, with bridged networking, you simply assign different IPv4s to each VM. Proxmox and Virtualizor both support this directly.<\/p>\n<\/span>Practical Setup Differences<\/span><\/h3>\n\n- \n
Proxmox VE<\/strong>:<\/p>\n\n- \n
Has built-in NAT, bridge, and routing modes.<\/p>\n<\/li>\n
- \n
NAT = use single IPv4, private LAN inside.<\/p>\n<\/li>\n
- \n
Bridge = requires multiple IPv4s.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n
- \n
Virtualizor<\/strong>:<\/p>\n\n- \n
Typically expects an IP pool if you want each VM exposed publicly.<\/p>\n<\/li>\n
- \n
Can be made to work with NAT (but less plug-and-play than Proxmox).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\u2705 Bottom line:<\/strong><\/p>\nIf you only have one IPv4 and don\u2019t want to purchase more, you can still create several VMs by using NAT and port forwarding.<\/p>\n
If you want each VM to have its own dedicated IPv4, then you\u2019ll need a pool of IPv4s from your host\/provider.<\/p>\n\n<\/span>Single IPv4 (NAT Setup)<\/span><\/h3>\nWhen you only have one public IPv4<\/strong> from your provider.<\/p>\nInternet
\n|
\n[ Public IPv4: 203.0.113.10 ]
\n|
\nProxmox Host
\n---------------------
\n| NAT \/ iptables |
\n| Forwarding Rules |
\n---------------------
\n\/ |
\nVM1 (10.0.0.2) VM2 (10.0.0.3) VM3 (10.0.0.4)
\nPrivate IPs only
\n<\/code><\/p>\n\n- \n
Host has the only public IPv4.<\/p>\n<\/li>\n
- \n
Each VM sits on a private subnet<\/strong> (10.x.x.x or 192.168.x.x).<\/p>\n<\/li>\n- \n
Outbound traffic \u2192 NAT\u2019d to host\u2019s IPv4.<\/p>\n<\/li>\n
- \n
Inbound traffic \u2192 you set port forwards<\/strong> (e.g., 80\u2192VM1, 443\u2192VM2).<\/p>\n<\/li>\n- \n
Alternative: run NGINX\/HAProxy<\/strong> on host as a reverse proxy to route based on hostname\/domain.<\/p>\n<\/li>\n<\/ul>\n\u2705 Pros: No need to buy extra IPs.
\u274c Cons: Can\u2019t easily give each VM its own independent IPv4 identity.<\/p>\n
<\/span>Multiple IPv4s (Bridged Setup)<\/span><\/h3>\nWhen you purchase a block\/pool of IPv4s<\/strong> (e.g., \/29, \/28).<\/p>\nInternet
\n|
\n[ IP Block: 203.0.113.8\/29 ]
\n|
\nProxmox Host
\n--------------------
\n| vmbr0 (bridge) |
\n--------------------
\n\/ |
\nVM1 (203.0.113.9) VM2 (203.0.113.10) VM3 (203.0.113.11)
\nPublic IPs directly assigned
\n<\/code><\/p>\n\n- \n
Host gets one IP from the block, rest are mapped to VMs.<\/p>\n<\/li>\n
- \n
VMs connect directly to the Internet with unique IPv4s<\/strong>.<\/p>\n<\/li>\n- \n
No NAT required.<\/p>\n<\/li>\n
- \n
Each VM can run services independently (e.g., web, mail, SSL).<\/p>\n<\/li>\n<\/ul>\n
\u2705 Pros: Each VM has its own IPv4 \u2014 cleaner and more professional for production hosting.
\u274c Cons: Requires paying for additional IPs.<\/p>\n
\ud83d\udc49 My thoughts<\/strong><\/p>\nIf this is for testing, dev, or internal use, go with NAT (Option 1).<\/p>\n
If this is for production hosting (multiple websites, cPanel, mail servers), you\u2019ll want a small IPv4 block (Option 2).<\/p>\n
<\/span>Here are clean, copy-pasteable Proxmox<\/strong> network examples for both approaches. I\u2019ll use generic names you can adapt:<\/span><\/h4>\n<\/article>\n\n\n- \n
Public\/WAN NIC on host: eno1<\/code><\/p>\n<\/li>\n- \n
Private\/LAN bridge for VMs (NAT case): vmbr1<\/code><\/p>\n<\/li>\n- \n
Public bridge (bridged case): vmbr0<\/code><\/p>\n<\/li>\n- \n
Host public IP (single-IP NAT example): 203.0.113.10\/24<\/code>, gateway 203.0.113.1<\/code><\/p>\n<\/li>\n- \n
Private VM subnet (NAT example): 10.10.10.0\/24<\/code><\/p>\n<\/li>\n<\/ul>\n<\/span>Single IPv4 with NAT & Port Forwarding<\/span><\/h3>\n<\/span>\/etc\/network\/interfaces<\/code> (Proxmox host)<\/span><\/h3>\nauto lo
\niface lo inet loopback<\/code><\/code># ===== WAN: host’s one public IP =====
\nauto eno1
\niface eno1 inet manualauto vmbr0
\niface vmbr0 inet static
\naddress 203.0.113.10\/24
\ngateway 203.0.113.1
\nbridge-ports eno1
\nbridge-stp off
\nbridge-fd 0# ===== LAN bridge for VMs (private subnet) =====
\nauto vmbr1
\niface vmbr1 inet static
\naddress 10.10.10.1\/24
\nbridge-ports none
\nbridge-stp off
\nbridge-fd 0
\npost-up echo 1 > \/proc\/sys\/net\/ipv4\/ip_forwardReboot networking or the node after saving (or use ifupdown2 if installed).<\/p>\n<\/span>NAT & forwarding (run on host; make persistent)<\/span><\/h3>\nCreate \/etc\/network\/if-up.d\/99-nat<\/code> and make it executable (chmod +x<\/code>):<\/p>\n#!\/bin\/sh
\n# Enable NAT from vmbr1 (10.10.10.0\/24) out via public interface
\niptables -t nat -C POSTROUTING -s 10.10.10.0\/24 -o vmbr0 -j MASQUERADE 2>\/dev\/null ||
\niptables -t nat -A POSTROUTING -s 10.10.10.0\/24 -o vmbr0 -j MASQUERADE<\/code><\/code># Example inbound DNAT: forward ports to a VM
\n# HTTP (80) -> VM 10.10.10.10
\niptables -t nat -C PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to-destination 10.10.10.10 2>\/dev\/null ||
\niptables -t nat -A PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to-destination 10.10.10.10# HTTPS (443) -> VM 10.10.10.11
\niptables -t nat -C PREROUTING -i vmbr0 -p tcp –dport 443 -j DNAT –to-destination 10.10.10.11# Allow forwarding
\niptables -C FORWARD -i vmbr0 -o vmbr1 -m state –state RELATED,ESTABLISHED -j ACCEPT 2>\/dev\/null ||
\niptables -A FORWARD -i vmbr0 -o vmbr1 -m state –state RELATED,ESTABLISHED -j ACCEPT
\niptables -C FORWARD -i vmbr1 -o vmbr0 -j ACCEPT 2>\/dev\/null ||
\niptables -A FORWARD -i vmbr1 -o vmbr0 -j ACCEPT<\/p>\n\nAdjust the DNAT targets (e.g., 10.10.10.10<\/code>) per VM.
Alternative: instead of port forwards, terminate NGINX\/HAProxy<\/strong> on the host to route based on hostname\u2014lets multiple VMs share 80\/443.<\/p>\n<\/blockquote>\n<\/span>VM NIC settings (NAT case)<\/span><\/h3>\nIn Proxmox VM \u2192 Hardware \u2192 Network Device:<\/p>\n
\n- \n
Bridge: vmbr1<\/code><\/p>\n<\/li>\n- \n
(Optional) Firewall on<\/p>\n<\/li>\n
- \n
Inside the VM, set a static IP like:<\/p>\n
\n- \n
IP: 10.10.10.10<\/code><\/p>\n<\/li>\n- \n
Netmask: 255.255.255.0<\/code><\/p>\n<\/li>\n- \n
Gateway: 10.10.10.1<\/code><\/p>\n<\/li>\n- \n
DNS: your preferred resolver(s)<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/span>Multiple Public IPv4s with Bridging<\/span><\/h3>\nAssume you purchased a routed block (example \/29<\/code>: 203.0.113.8\/29<\/code>, usable .9-.14<\/code>, gateway from provider, often not inside<\/strong> the \/29). You\u2019ll typically keep your primary host IP<\/strong> on the WAN and present the \/29 to VMs via a bridge.<\/p>\n<\/span>\/etc\/network\/interfaces<\/code><\/span><\/h2>\nauto lo
\niface lo inet loopback<\/code><\/code># Host main uplink (keeps its existing single public IP)
\nauto eno1
\niface eno1 inet manual# Public bridge the VMs attach to
\nauto vmbr0
\niface vmbr0 inet static
\naddress 203.0.113.10\/24 # your host\u2019s existing IP (or whatever your provider gave for the main IP)
\ngateway 203.0.113.1
\nbridge-ports eno1
\nbridge-stp off
\nbridge-fd 0<\/p>\n\nYou do not<\/strong> assign the \/29 IPs to the host. You assign them inside the VMs<\/em>.<\/p>\n<\/blockquote>\n<\/span>VM NIC settings (bridged case)<\/span><\/h3>\n\n- \n
Bridge: vmbr0<\/code><\/p>\n<\/li>\n- \n
Inside each VM, configure one of the \/29 IPs:<\/p>\n
\n- \n
VM1 IP: 203.0.113.9\/29<\/code><\/p>\n<\/li>\n- \n
Gateway: use the provider\u2019s router\/gateway<\/strong> as instructed (some DCs require using the host\u2019s main gateway, others route via the host\u2014follow their handoff doc).<\/p>\n<\/li>\n- \n
DNS: your choice<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\nSome providers deliver the additional block as routed to your host IP (no ARP). In that case, keep the VM NIC on vmbr0<\/code> but set the VM gateway to the host\u2019s vmbr0 IP and add host routes, or use Proxmox as a router for that \/29. If the DC uses MAC filtering<\/strong> or \u201cone MAC per IP\u201d, you may need to request additional MACs or use their vSwitch\/VLAN.<\/p>\n<\/blockquote>\n<\/span>Quick sanity checks<\/span><\/h3>\n