Configuring Hyper-V Private Switches for Isolated Inter-VM Traffic

When building microservice clusters or testing database-heavy applications in Hyper-V, exposing internal traffic to the physical network or even the host OS creates an unnecessary attack surface. The most effective way to isolate this traffic is a Private Virtual Switch: a dedicated network segment accessible only by the virtual machines attached to it, completely cutting off the host operating system and the external network.

Hyper-V offers three virtual switch types: External (bridged to a physical NIC for network and internet access), Internal (allows host and VM communication), and Private (restricted to VM-to-VM only). The Private switch is the right engineering choice when sensitive data moving between services must never leave the hypervisor.

Creating the Private Switch

While switches can be created via Hyper-V Manager, PowerShell makes the configuration repeatable. Run PowerShell as an Administrator on the Hyper-V host and execute:

# Create a private switch named 'IsolatedInternal'
New-VMSwitch -Name "IsolatedInternal" -SwitchType Private

Once the switch exists, attach each VM's network adapter to it. You can do this in the VM's Settings dialog or with PowerShell:

# Attach an existing VM's adapter to the private switch
Connect-VMNetworkAdapter -VMName "App-Server-01" -SwitchName "IsolatedInternal"

Replace the VM and switch names with your own values. This changes VM configuration state, so do it while the VM is stopped or during a maintenance window if the adapter is in use.

Static Addressing Is Required

A Private switch has no DHCP service, so VMs attached to it will not receive an IP address automatically. Without manual configuration, guests fall back to APIPA link-local addresses (169.254.x.x) and communication becomes unreliable. Assign static IPs in the same subnet inside each guest OS.

Example: two-tier application test cluster

VM Name	Static IP Address	Subnet Mask	Gateway
DB-Server-01	10.0.0.10	255.255.255.0	None
App-Server-01	10.0.0.20	255.255.255.0	None

No default gateway is needed because traffic never routes off the segment. Any private RFC 1918 range that does not overlap your other networks works.

Verifying Connectivity and Isolation

Confirm the setup with three checks:

1. Check the switch type: On the host, run Get-VMSwitch and confirm the SwitchType property for your switch reads Private.
2. Test VM-to-VM connectivity: From App-Server-01, ping 10.0.0.10. Replies confirm both guests are on the same subnet and attached to the same switch.
3. Confirm host isolation: From the Hyper-V host, ping 10.0.0.10. The request must fail. If it succeeds, the VMs are attached to an Internal or External switch instead.

Limitations and Common Mistakes

• No host access: Unlike an Internal switch, the host cannot reach VMs on a Private switch. If you need RDP or file access from the host, add a second virtual NIC on an Internal switch for management traffic.
• No built-in encryption: Hyper-V does not encrypt traffic crossing the virtual switch. For sensitive data, use application-level protection such as TLS or IPsec between guests.
• Manual IP management: Forgetting static IPs is the most common cause of "the private switch doesn't work" reports. Check for 169.254.x.x addresses first when connectivity fails.
• No internet or external access: VMs on a Private switch cannot reach anything outside the segment. If a guest also needs updates or external services, it needs a second adapter on an External switch.

Used this way, a Private switch gives you a zero-exposure test bed for clustered databases, microservice east-west traffic, or any workload where the hypervisor boundary should also be the network boundary.