Running Multiple VMs with a Single IPv4 |

Saw a thread on the Webhostingtalk forum this morning asking its members if it was possible to split a dedicated server into several virtual servers using either virtualizor or proxmox and divide them over a single ipv4 without purchasing an IP pool by bridging, or would I need multiple ipv4 addresses?

Lots of great replies from their members, so I thought I’d expand on this here. Yes — you can split a dedicated server into multiple virtual servers (VMs) using Virtualizor or Proxmox, but the way you handle networking and IPv4 addresses depends on what you want:

You’d configure NAT or a reverse proxy/load balancer on the host where each VM gets a private/internal IP (e.g., 10.x.x.x or 192.168.x.x). Outbound traffic from all VMs would be translated to the host’s single IPv4 and inbound traffic would require port forwarding or a proxy to direct connections to the right VM.

This works fine if you don’t need every VM to have its own public IP (e.g., lab, dev servers, internal apps, or web hosting with reverse proxy), but the drawback is that you can’t run identical services (like two VMs both listening on port 443) directly without adding a reverse proxy layer.

When You Need Multiple Public IPs

If each VM must be reachable on its own IPv4 address (e.g., cPanel hosting, SSL termination per VM, mail servers, etc.), then you’ll 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.

Practical Setup Differences

Proxmox VE:
- Has built-in NAT, bridge, and routing modes.
- NAT = use single IPv4, private LAN inside.
- Bridge = requires multiple IPv4s.
Virtualizor:
- Typically expects an IP pool if you want each VM exposed publicly.
- Can be made to work with NAT (but less plug-and-play than Proxmox).

✅ Bottom line:

If you only have one IPv4 and don’t want to purchase more, you can still create several VMs by using NAT and port forwarding.

If you want each VM to have its own dedicated IPv4, then you’ll need a pool of IPv4s from your host/provider.

Single IPv4 (NAT Setup)

When you only have one public IPv4 from your provider.

Internet | [ Public IPv4: 203.0.113.10 ] | Proxmox Host --------------------- | NAT / iptables | | Forwarding Rules | --------------------- / | VM1 (10.0.0.2) VM2 (10.0.0.3) VM3 (10.0.0.4) Private IPs only

Host has the only public IPv4.
Each VM sits on a private subnet (10.x.x.x or 192.168.x.x).
Outbound traffic → NAT’d to host’s IPv4.
Inbound traffic → you set port forwards (e.g., 80→VM1, 443→VM2).
Alternative: run NGINX/HAProxy on host as a reverse proxy to route based on hostname/domain.

✅ Pros: No need to buy extra IPs.
❌ Cons: Can’t easily give each VM its own independent IPv4 identity.

Multiple IPv4s (Bridged Setup)

When you purchase a block/pool of IPv4s (e.g., /29, /28).

Internet | [ IP Block: 203.0.113.8/29 ] | Proxmox Host -------------------- | vmbr0 (bridge) | -------------------- / | VM1 (203.0.113.9) VM2 (203.0.113.10) VM3 (203.0.113.11) Public IPs directly assigned

Host gets one IP from the block, rest are mapped to VMs.
VMs connect directly to the Internet with unique IPv4s.
No NAT required.
Each VM can run services independently (e.g., web, mail, SSL).

✅ Pros: Each VM has its own IPv4 — cleaner and more professional for production hosting.
❌ Cons: Requires paying for additional IPs.

👉 My thoughts

If this is for testing, dev, or internal use, go with NAT (Option 1).

If this is for production hosting (multiple websites, cPanel, mail servers), you’ll want a small IPv4 block (Option 2).

Here are clean, copy-pasteable Proxmox network examples for both approaches. I’ll use generic names you can adapt:

Public/WAN NIC on host: eno1
Private/LAN bridge for VMs (NAT case): vmbr1
Public bridge (bridged case): vmbr0
Host public IP (single-IP NAT example): 203.0.113.10/24, gateway 203.0.113.1
Private VM subnet (NAT example): 10.10.10.0/24

Single IPv4 with NAT & Port Forwarding

NAT & forwarding (run on host; make persistent)

Create /etc/network/if-up.d/99-nat and make it executable (chmod +x):

#!/bin/sh # Enable NAT from vmbr1 (10.10.10.0/24) out via public interface iptables -t nat -C POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE 2>/dev/null || iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE# Example inbound DNAT: forward ports to a VM
# HTTP (80) -> VM 10.10.10.10
iptables -t nat -C PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to-destination 10.10.10.10 2>/dev/null ||
iptables -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
iptables -t nat -C PREROUTING -i vmbr0 -p tcp –dport 443 -j DNAT –to-destination 10.10.10.11# Allow forwarding
iptables -C FORWARD -i vmbr0 -o vmbr1 -m state –state RELATED,ESTABLISHED -j ACCEPT 2>/dev/null ||
iptables -A FORWARD -i vmbr0 -o vmbr1 -m state –state RELATED,ESTABLISHED -j ACCEPT
iptables -C FORWARD -i vmbr1 -o vmbr0 -j ACCEPT 2>/dev/null ||
iptables -A FORWARD -i vmbr1 -o vmbr0 -j ACCEPT

Adjust the DNAT targets (e.g., 10.10.10.10) per VM.
Alternative: instead of port forwards, terminate NGINX/HAProxy on the host to route based on hostname—lets multiple VMs share 80/443.

VM NIC settings (NAT case)

In Proxmox VM → Hardware → Network Device:

Bridge: vmbr1
(Optional) Firewall on
Inside the VM, set a static IP like:
- IP: 10.10.10.10
- Netmask: 255.255.255.0
- Gateway: 10.10.10.1
- DNS: your preferred resolver(s)

Multiple Public IPv4s with Bridging

Assume you purchased a routed block (example /29: 203.0.113.8/29, usable .9-.14, gateway from provider, often not inside the /29). You’ll typically keep your primary host IP on the WAN and present the /29 to VMs via a bridge.

`/etc/network/interfaces`

auto lo iface lo inet loopback# Host main uplink (keeps its existing single public IP)
auto eno1
iface eno1 inet manual# Public bridge the VMs attach to
auto vmbr0
iface vmbr0 inet static
address 203.0.113.10/24 # your host’s existing IP (or whatever your provider gave for the main IP)
gateway 203.0.113.1
bridge-ports eno1
bridge-stp off
bridge-fd 0

You do not assign the /29 IPs to the host. You assign them inside the VMs.

VM NIC settings (bridged case)

Bridge: vmbr0
Inside each VM, configure one of the /29 IPs:
- VM1 IP: 203.0.113.9/29
- Gateway: use the provider’s router/gateway as instructed (some DCs require using the host’s main gateway, others route via the host—follow their handoff doc).
- DNS: your choice

Some providers deliver the additional block as routed to your host IP (no ARP). In that case, keep the VM NIC on vmbr0 but set the VM gateway to the host’s vmbr0 IP and add host routes, or use Proxmox as a router for that /29. If the DC uses MAC filtering or “one MAC per IP”, you may need to request additional MACs or use their vSwitch/VLAN.

Quick sanity checks

Enable forwarding persistently:
- Add net.ipv4.ip_forward=1 to /etc/sysctl.conf, then sysctl -p.
If using Proxmox Firewall, allow the necessary FORWARD/IN rules or disable PF while testing.
Confirm which interface actually egresses to the Internet (ip route get 1.1.1.1) and match your iptables -o device accordingly (sometimes it’s eno1, not vmbr0).

When to choose which

Single IPv4, no budget for more: NAT + (port forwards or reverse proxy).
Production hosting (mail, SSL per VM, cPanel, isolation): buy a small block (/30-/28) and bridge.

Here’s why choosing ProlimeHost to customize your servers is a smart move:

Tailored Performance

Not every workload is the same. With ProlimeHost, you can customize CPU, RAM, storage, and network configurations to match the exact requirements of your application—whether you’re running AI models, hosting high-traffic websites, streaming, or managing databases. This ensures you’re not overpaying for unused resources or underpowered when traffic spikes.

Flexibility & Control

ProlimeHost gives you full root access and the freedom to install and configure software stacks, security tools, and operating systems as you see fit. Unlike cookie-cutter hosting, customized servers let you build the environment your team actually needs.

Scalability for Growth

As your business grows, your servers can grow with you. ProlimeHost makes it easy to scale vertically (upgrading CPU cores, GPUs, or RAM) or horizontally (adding more servers), so your infrastructure adapts to future demand without downtime.

Security & Compliance

Customized servers mean you can enforce your own security policies—firewalls, encryption, compliance tools—suited to your industry (finance, healthcare, e-commerce, etc.). ProlimeHost supports hardened configurations that protect sensitive data while meeting regulatory standards.

AI & GPU Optimization

In 2025, workloads like AI, ML, and automation dominate. ProlimeHost offers GPU-powered servers that you can fine-tune for AI inference, training, or real-time analytics. A customized environment ensures maximum efficiency and cost-effectiveness for these resource-intensive tasks.

Expert Guidance & Support

Customization can be complex—but ProlimeHost’s engineers help you design, deploy, and manage a server setup that’s reliable and future-ready. Whether you need KVM, IPMI, or advanced networking setups, ProlimeHost provides hands-on support to make it smooth.

✅ Bottom line: ProlimeHost lets you transform generic hosting into a strategic infrastructure investment—fully aligned with your performance, security, and growth goals.

👉 Contact ProlimeHost today to explore dedicated server solutions designed to deliver growth, scalability, and unmatched performance.

You can reach us at sales@prolimehost.com or at 1 (877) 477-9454

Post Views: 14