ENGINEERING INSIGHTS
Why VLAN Segmentation Alone May Not Be Enough for VPS Security
Understanding the limits of VLANs in multi-tenant VPS hosting—and how virtual-switch controls, tenant firewall policies, and operating-system hardening create stronger isolation.
Key Takeaway
VLANs are useful for separating different network segments, but they do not automatically block communication between VPS customers sharing the same VLAN. A multi-tenant hosting environment needs deliberate tenant-to-tenant controls at the virtual switch, distributed firewall, or guest operating system.
Introduction
Virtual LANs (VLANs) are widely used to separate enterprise networks and manage broadcast domains. However, providers hosting several Virtual Private Server (VPS) customers on a shared hypervisor need a stronger question: can one customer’s virtual machine reach another customer’s machine, and which device can enforce that restriction?
When tenants use the same VLAN and subnet, their VM-to-VM traffic may be switched locally inside VMware ESXi or Proxmox without passing through the physical switch or FortiGate. An otherwise well-configured perimeter firewall therefore may not see or filter that east–west traffic.
This article explains the networking distinction, typical exposure points, and a practical, staged approach to VPS network isolation for hosting environments in Nepal and elsewhere.
The Limitations of VLANs in VPS Environments
Shared Broadcast
VMs in the same VLAN share a Layer 2 segment. A normal VLAN tag does not isolate one customer from another.
East–West Traffic
VM-to-VM communication can remain inside a hypervisor switch, bypassing perimeter firewall inspection.
Shared Resources
Tenants share underlying hypervisor and switching infrastructure, which needs additional hardening and access controls.
Configuration Errors
Permissive port-group policies, poorly scoped firewall rules, and unmanaged RDP access increase exposure.
How VPS Traffic Actually Flows
Consider three Windows VPS instances attached to the same port group and VLAN. When VPS A communicates with VPS B in the same subnet, traffic may remain within the virtual switch. It does not need to travel to the FortiGate simply because a FortiGate is the default gateway for that subnet.
Important: assigning separate port-group names while retaining the same unfiltered Layer 2 VLAN is not, by itself, a security boundary. Isolation depends on enforcement capabilities and the actual traffic path.
A Layered Security Approach for VPS Isolation
01. Network Design
Define tenant trust boundaries, allowed services, and necessary shared resources.
02. Virtual Switch Controls
Apply a supported per-port or distributed security control rather than relying only on VLAN tags.
03. Firewall Policies
Restrict tenant-to-tenant traffic at a point that actually sees it.
04. Guest Hardening
Protect Windows/Linux guests with local firewalls, patching, and account security.
05. Continuous Review
Monitor blocked attempts, audit exceptions, and test isolation after changes.
Principle: an isolation design must be validated with connectivity tests between tenants—not simply inferred from the presence of a VLAN, a firewall, or separate public NAT rules.
Choosing the Right Controls for ESXi, Proxmox & FortiGate
VMware ESXi standard vSwitch
Validate VLAN and port-group security settings. Review promiscuous mode, MAC address changes, and forged transmits; their recommended defaults address spoofing risk, but do not alone provide tenant-level traffic isolation.
VMware distributed switching
Where supported and licensed, evaluate private VLANs and distributed/microsegmentation controls. Compatibility and upstream switching behavior must be tested before rollout.
Proxmox VE
Evaluate the platform’s VM-level firewall features, Linux bridge/SDN design, and any permitted inter-VM communication. Confirm rule ordering and behavior on the actual deployed version.
FortiGate and physical switching
Use firewall policies for traffic routed or redirected through the firewall. Same-VLAN host-to-host packets do not automatically reach FortiGate; specialized intra-VLAN designs require compatible topology and features.
Windows or Linux guest firewall
Apply a default-deny stance to unnecessary inbound services; allow customer administration and application ports only from approved sources. Assume a tenant administrator can change their guest firewall.
Practical Implementation Plan
01. Discover
Inventory ESXi/Proxmox hosts, vSwitches or bridges, VLANs, guest IPs, upstream trunks, NAT rules and necessary customer-to-service access.
02. Define permitted traffic
List required flows such as DNS, backup, management, application connectivity, and RDP from approved addresses; identify tenant-to-tenant paths that should be denied.
03. Choose a pilot
Select two non-critical tenant VMs, confirm console or out-of-band access, back up network configuration, and prepare a rollback procedure.
04. Enforce & test
Apply the chosen supported isolation controls. Test allowed business flows and denied tenant-to-tenant access in both directions, on the same and different hypervisor hosts.
05. Roll out in stages
Expand by tenant groups during maintenance windows; validate operations and document exceptions and policy ownership.
06. Monitor & maintain
Retest after VM moves, switch changes or firewall updates; keep logs, configuration backups, security reviews and incident procedures current.
VPS Security Considerations for Hosting Providers in Nepal
Hosting providers in Kathmandu Valley and across Nepal often need to improve isolation while retaining customer IP addresses, remote administration access, existing Cisco switch trunks, and deployed firewall policies. Any proposed control must therefore be assessed for its effect on current services and maintenance constraints.
Where VPS users have full administrator access to their Windows guest, guest firewall rules provide helpful defense in depth but are not a substitute for provider-controlled tenant isolation. Prefer a network or hypervisor-level enforcement point that the customer cannot modify.
For older standalone ESXi deployments, do not assume that features available with vCenter, distributed switching, or a particular VMware license are present. Similarly, Proxmox firewall behavior and bridge integration should be confirmed against the exact installed release. Test everything before changing production network paths.
Frequently Asked Questions
It separates traffic between different VLANs, but if multiple customers share one VLAN, it normally does not block their direct Layer 2 communication. Add an explicit enforcement mechanism and verify the result.
No. When two VMs exchange frames locally on the same virtual switch or Layer 2 segment, those frames may never reach the FortiGate. Traffic must traverse an appropriate inspection point before its firewall policies can apply.
Sometimes. Solutions such as supported port-level restrictions, private VLAN or microsegmentation designs, and selected firewall enforcement models may preserve addresses. The answer depends on your hypervisor licensing, switch topology, routing, and service dependencies.
Not automatically. Two port groups mapped to the same VLAN can still allow communication. Review whether a specific security feature actually prevents lateral traffic.
They are useful defense in depth but not a trustworthy sole isolation boundary when customers can alter their own rules. Provider-managed virtual-network controls are preferable.
Verify DNS, application ports, RDP access, backup operations, required shared services, denied cross-tenant traffic, VM migration behavior, monitoring, and rollback access.
Conclusion
VLANs remain essential for organizing networks, but multi-tenant VPS security is ultimately about where access policy is enforced. A secure architecture combines deliberate tenant boundaries with supported virtual-switch controls, appropriate firewall policy, host and guest hardening, and continuous verification.
Whether a provider uses standalone VMware ESXi, vCenter-managed infrastructure, Proxmox VE, Cisco networking, or FortiGate security, the safest design is the one that demonstrably blocks unauthorized tenant-to-tenant paths while preserving approved customer services.
Further Reading
Broadcom: Security implications of ESXi vSwitch security policies
Broadcom: Isolated private VLAN behavior on distributed switches
Fortinet: Secured LAN and intra-VLAN considerations
Discuss VPS Isolation & Network Security
Need to review a VMware, Proxmox, Cisco, or FortiGate-based hosting environment? I welcome conversations about secure design, migration planning, and practical tenant isolation.
At a Glance
Focus
VPS network isolation and multi-tenant security
Core problem
Same-VLAN east–west traffic may bypass a perimeter firewall
Technology
ESXi, Proxmox VE, virtual switches, FortiGate, Cisco
Outcome
Verifiable, provider-controlled tenant boundaries
Related Project
Enterprise Network Security & Infrastructure Modernization
Explore firewall design, VLAN segmentation, secure VPN and resilient network architecture.
What You’ll Learn
Where VLANs stop
Understand the difference between segmentation and isolation.
Common exposure points
Inspect east–west paths, switch settings and VM privileges.
Defensible controls
Compare hypervisor, firewall and guest safeguards.
Implementation checks
Test tenant boundaries before production rollout.
