Making a Static Virtual Internal NAT Switch Work with Hyper-V

Hyper-V does not natively support static IP assignment for NAT switches via New-NetNat alone. To ensure VMs retain consistent addresses, you must configure the Hyper-V virtual switch to use a specific subnet and then assign static IPs within that range inside each guest operating system. This approach bypasses DHCP instability and creates a predictable internal network.

Understanding the Limitations of Hyper-V NAT

Many administrators attempt to use the New-NetNat PowerShell cmdlet immediately after creating an internal switch, expecting automatic address stability. However, this often fails because New-NetNat requires a host NAT interface and does not inherently manage client IP allocation. Without explicit configuration, Hyper-V’s integrated DHCP service (if enabled) or the guest OS’s own DHCP client may assign random addresses on every reboot. The core issue is that "NAT" in Hyper-V refers to traffic translation, not IP persistence. You need a two-part solution: a stable virtual infrastructure and static configuration within the guests. Related article: Making a Virtual Internal NAT Switch Work for Hyper-V VMs provides background on basic switch creation, but lacks details on IP stability.

Step 1: Create a Dedicated Internal Switch

The foundation of your static network is a dedicated Hyper-V Virtual Switch. Do not reuse existing switches intended for other purposes. Open PowerShell as Administrator and execute the following command to create a new internal switch named StaticNATSwitch:

New-VMSwitch -Name StaticNATSwitch -SwitchType Internal

This command creates a logical network boundary isolated from external physical adapters. Once created, you must assign an IPv4 address to the virtual adapter on the host machine. This host IP will serve as the default gateway for your VMs. Choose a subnet that does not conflict with your physical network, such as 192.168.50.1/24.

New-NetIPAddress -InterfaceAlias "vEthernet (StaticNATSwitch)" -IPAddress 192.168.50.1 -PrefixLength 24

Verify the interface alias name using Get-NetAdapter, as it may vary slightly depending on your Windows version. Ensure the host can ping itself at this address before proceeding.

Step 2: Configure the Host NAT Instance

Now that the host has an IP on the internal network, you must tell Windows to route traffic from this subnet through the host’s external connection. Use New-NetNat to define the internal network range.

New-NetNat -Name InternalNAT -InternalIPInterfaceAddressPrefix 192.168.50.0/24

This step translates internal private addresses to the host’s public IP. It is crucial that this command succeeds without errors. If it fails, check if another NAT instance already exists for this subnet using Get-NetNat. Remove conflicting instances with Remove-NetNat before retrying.

Step 3: Assign Static IPs Inside Guest VMs

This is the most critical step for achieving your goal. Hyper-V cannot force a static IP onto a guest OS automatically. You must log into each VM and configure its network adapter manually. For Windows Guests: 1. Open Network Connections (ncpa.cpl). 2. Right-click the Hyper-V adapter and select Properties. 3. Select Internet Protocol Version 4 (TCP/IPv4) and click Properties. 4. Choose Use the following IP address. 5. Enter an IP in the 192.168.50.x range (e.g., 192.168.50.10), Subnet Mask 255.255.255.0, and Gateway 192.168.50.1. 6. Set DNS to 192.168.50.1 or your preferred external DNS server. For Linux Guests: Edit the network configuration file (e.g., /etc/netplan/*.yaml or /etc/network/interfaces) to specify a static IP, netmask, and gateway matching the host’s internal IP. Apply the changes and restart the network service. Ensure no DHCP client is running on these interfaces, as it may override your static settings upon boot.

Verifying Connectivity and Stability

After configuration, test the setup from both the host and the VMs. From the host, ping the VMs’ static IPs. From a VM, ping the host gateway (192.168.50.1) and then an external site like 8.8.8.8. Successful pings confirm that the NAT instance is correctly translating traffic. If connectivity fails, check the Windows Firewall on the host. Ensure that Private Network profiles are allowed for the internal switch. Additionally, verify that the VMs are connected to the correct switch in Hyper-V Manager. Disconnecting and reconnecting the network adapter in Hyper-V Manager can sometimes resolve stale ARP cache issues. Related article: Windows Server 2022: Hyper-V VM with Installed OS and Plesk Control Panel - Internal IP Not Public discusses similar IP persistence challenges in server environments.

Frequently Asked Questions

Can I use DHCP reservations instead of static IPs?

Yes, but Hyper-V’s built-in DHCP is limited. For robust reservation management, consider installing a dedicated DHCP server role on a separate VM or using Windows Server DHCP services. Reservations require careful maintenance to avoid conflicts if the VM moves between different virtual switches.

Why can’t my VM access the internet after configuring NAT?

This usually indicates a firewall block or incorrect routing. Verify that the host’s external adapter is shared or that New-NetNat is active. Check that the VM’s gateway points to the host’s internal IP (192.168.50.1) and not an empty field.

Does this setup work with Windows Server guests?

Absolutely. The process is identical for Windows Server VMs. Just ensure that the network adapter in Hyper-V Manager is set to the StaticNATSwitch and that the server’s TCP/IP properties are configured with the static IP details inside the OS.

What happens if I change the host’s IP address?

You must update all VMs’ gateway settings and the InternalIPInterfaceAddressPrefix in New-NetNat. Changing the host’s internal IP breaks the link unless you also update the NAT definition and guest configurations to match the new subnet.

Is this secure for production environments?

While functional, this setup relies on the host for security filtering. For production, consider adding a software firewall or a dedicated network security appliance VM between the internal switch and the external network to inspect traffic and enforce policies.