Hyper-V Default switch IP address range change. Ver 1809 Build 17763.1

Brass Contributor

Can one confirm IP address range changed to 192.168.X.Y Subnet from 172.X.X.X


Also changes the subnet randomly on every Hyper-V services startup. 192.168.X.Y . X can change from 51 thru 180.


Although this is working on DHCP based IP assignment on guests, It is causing issues on static IP as it keeps changing after every boot




135 Replies

@southernprogrammer Thanks, gived myself permission to tweak a litlle you script to update all my vmdomains's ip also, work like a charm.

I also think the behavior of the default adapter is not logical, and i personaly see it as a bug, i hope it get fixed since i am migrating from VmWare to Hypre-V, streamlining my setup accross multiple device is better without scripts...

@Remon li it's a bug.


Use case:  VPN that conflicts with 172.17.x.x network range.  Win10 client boots; does network conflict detection; see's free address and makes the default nat adapter 172.17.109.x and ads route On-link 172.17.109.x 5256...  Note: 5k metric.  now VPN client is connected.  on connect; route for is added with a metric of 2.  the hyper-v VM is now unreachable.  We need to be able to control a "safe" network pool for the default nat network to pull from.

I am on Windows Pro 10 Version 1909.
I followed below link instructions to get around the issue with default switch static IP address in VM. The work around is create a new switch


@@Bala Sundara 


-This is not a solution but a workaround for people wanting to bypass Win 10's normal operation. If you are running important workloads, I suggest running Windows Server version of Hyper-v and not Windows 10.  I was in a pinch and needed some workaround while I was in-between servers. Once those were up and running I migrated back off onto Win Server Hyper-v. Anyway, good luck out there. 


1. Strip off any static IPs you have on all hardware NICs

2. Run the following commands

Get-HNSNetwork | ? Name -Like "Default Switch" | Remove-HNSNetwork
New-VMSwitch -SwitchName "Default Switch" -SwitchType internal -Verbose


3. Open Hyper-v Manager and open Virtual Switch Manager 

4. Default switch is still there, but now setting are no longer greyed out and can be adjusted from internal to external; move to external and verify it's assigned the correct hardware NIC. Verify it has "Allow management operating system to share this network adapter" checked. 

5. Watch the new NIC and bridge get created in Network and Sharing Center 'Change adapter settings'.

6. On the new Hyper-v NIC, adjust your IP settings to be static if you want.


I tried multiple reboots and VMs can still connect out while maintaining the static assignment on the Hyper-v NIC. 


Hope it helps!





It just helped me !

You're the hero of this thread

Kudos !

Excellent! Hope it stays working! I still haven't tested after Windows updates.
I guess we'll see!


I was so happy when I found your "solution" for this default switch nightmare...

Unfortunately it didn't help. The default switch just don't want to be deleted. As far as I'm aware it cannot be deleted. Though your solution did create another default switch. So what if I just change the priority and then lower the "grey"/unmodifiable default switch to be the lowest priority?

But anyway anyone can get this work?


My original issue is kind of the same as the original topic.

I would like to create an internal network of Servers on one laptop for testing / migration purposes.

Main connection to internet Wifi Network.

Default Switch would provide internet connection. Currently unable to set IP or fix address, just doesn't work if you move your laptop, connect to another WIFI network. So this cannot be touched, I have t leave it on automatic.

I have to create 2-3 separate Servers, with their own internal network card.

The problem is that as soon as I would like to set static ip for internal network, I'm unable to get internet connection. Default Switch constantly changing ip address/range (really silly ranges every computer restart even). Targeting the default switch as default gateway doesn't work.

What should be the proper topology/setup for this please? I really don't even know how others do this, in data centers, with hundreds of VMs, with different ip addresses, ranges, etc. when I'm struggling with 2-3 lousy server emulation. :D I might have very limited knowledge.

All help appreciated.

@Peter_H0 This is getting a little off topic, but I hope this helps:


The 'default switch' is an internal network inside hyper-v on your machine that changes every reboot (but that should not matter for your use case) which has NAT access to the "real" network via your wifi card.  The VM's on your machine on the default switch should be able to talk to one another, and again have internet access via network address translation to your machines wifi address.


If you want your VM's to have addresses on the wifi network, you need to add a new switch in the Hyper-V Virtual Switch Manager, and set it to 'external' - this will make the servers you build act like real clients with their own IP addresses on the same network as your wifi card.  So now instead of having 1 IP address for your machine, you will need 3 to run your machine and the two servers.


If you absolutely want the servers to have their own private (but fixed IP address range) network; that is NOT part of the "real" network; but you want that network to have a route to the internet, you will need to make a new switch in the Hyper-V Virtual Switch Manager, and set it to 'internal' and add those servers to that new network switch.  You will also need a separate external virtual switch, and a 3rd VM attached to both the internal and the external virtual networks, and you'll have to install and manage a (free) virtual firewall appliance (or OS with routing capabilities) on that 3rd VM and set it up to do NAT or routing between the networks.  In this scenario you will need 2 IP addresses on the "real" wifi network no matter how many VM's you add to your internal virtual switch, and their IP's can be static on that private internal network.

I found this topic because I had exactly the same frustration with the default switch.
I was thinking I was stupid because it kept changing subnet after every reboot.
Turns out, it works as designed(by an idiot, no doubt)
So fine, I figured: I will just use the external switch, shees.
So I did.
Suddenly, my internet speed dropped to 1 megabit/second
Turns out, on some network cards, that's a bug.
So... I have a completely unusable network-stack on hyper-v now. Thanks Microsoft.

@SoulChild112 I don't recall if I cross posted to this thread before.  here is my temporary workaround to control the default switch hyper-v and WSL network segments from reboot to reboot.



@Ethan_CIt wasn't aimed specifically at you, apologies if I made it seem so :)

No worries. I didn't feel singled out; but did have additional information that could help.

The workaround posted to github will solve your performance issue if you go back to the default switch and use the janky workaround to manage what network it resides on. I still feel that this is something MS should fix by adding some built in control; but until they do you may want to take a look at that other thread. :)
Yeah, I feel I have another solution nearby that suits me better

It starts with a V and ends in Mware ^^

@Ethan_C Hi,

Yes I've solved this issue in a way. I've set up a nat, that works well with multiple VMs.

However not perfect, since I have issues via Wifi still. Namely, OpenVPN game me silly errors, had to disable virtual network in order to use through Wifi, etc. Kind of a nuisance but well, hyper-v is "free" vs. the other solution that others mentioned above. :)

Not to mention if you want to know better the azure cloud you should know hyper-v better too so thats my other reason why I muck around with Hyper-v.


Exactly, the reason I wanted to go to hyperV from other solution is because it's a very performant hypervisor that's included with windows.


It would be nearly perfect, if it weren't for this silly and very unnecesairy "feature".


Cross posting this from the GitHub thread linked in the @Ethan_C post...


I have been struggling with this since WSL2 was released. Even before that, really, since the same problems crop up when running Linux VMs on Windows 10 Hyper-V.


The workaround suggested by @Ethan_C is the first one that I have tried that actually works consistently. What would make it better? Automation!


I just developed a script to automate the outlined process. I did this for some of my teammates who would rather not bother with loopback adapters and the Windows task scheduler, but I think the script should work for pretty much anyone who is capable of running a PowerShell script: