Infrastructure networking
Routed /32 Networking for Proxmox VPS Hosting
Production-focused guidance for routed /32 VPS networking on Proxmox VE, including Ubuntu and Debian behaviour differences, DNS handling, cloud-init considerations and VMNexor provisioning workflows.
VMNexor documentation is actively evolving. Some features, wording, and screenshots may change during beta.
Why routed /32 networking matters
Many hosting providers use routed networking rather than bridged failover IP assignment. Correct guest networking behaviour is critical for stable VPS provisioning.
Routed networking overview
Routed /32 networking is commonly used by infrastructure providers where guest virtual machines receive individually routed addresses rather than participating directly on the upstream layer-2 network.
- Common with Hetzner and OVH failover IP workflows
- Frequently used for scalable VPS hosting environments
- Allows infrastructure isolation and cleaner routing policies
- Requires guest operating systems to correctly handle gateway routing
- Often behaves differently between Linux distributions
Ubuntu vs Debian behaviour differences
Ubuntu and Debian guests can behave differently when handling routed /32 provisioning workflows.
- Ubuntu commonly uses netplan-based networking
- Debian deployments frequently rely on interfaces.d or dhcpcd
- DNS resolution behaviour may differ between distributions
- systemd-resolved behaviour is not always identical
- Cloud-init networking generation can vary between templates
DNS handling considerations
DNS configuration failures are one of the most common causes of broken automated provisioning.
- systemd-resolved may overwrite resolv.conf
- dhcpcd may regenerate DNS configuration unexpectedly
- Cloud-init can override manual DNS configuration
- resolv.conf symlink behaviour varies by distribution
- Always validate external DNS resolution after provisioning
Cloud-init and provisioning workflows
Cloud-init templates should be validated carefully before production deployment.
- Verify static networking persistence after reboot
- Validate gateway routing behaviour
- Confirm DNS survives reprovisioning
- Test reinstall workflows repeatedly
- Avoid assuming template portability between distributions
VMNexor routed networking workflows
VMNexor provisioning workflows are designed to support provider-style routed networking environments rather than only consumer bridge-based deployments.
- Distribution-aware provisioning behaviour
- DNS configuration handling
- Template-specific networking support
- Infrastructure-oriented provisioning logic
- Production-style provisioning validation
Common failure scenarios
Many networking issues only appear after real production provisioning workloads.
- Temporary failure resolving repository domains
- Broken DNS after reboot
- Missing default workflow
- Cloud-init overwriting configuration
- Incorrect resolv.conf ownership or symlink handling
- Gateway routing inconsistencies
Production validation checklist
Every routed networking template should be repeatedly validated before production use.
- Test Ubuntu and Debian independently
- Verify outbound connectivity
- Verify DNS resolution
- Test reboot persistence
- Validate reinstall workflows
- Validate provisioning on multiple nodes
- Confirm package installation functionality
- Monitor cloud-init execution behaviour