Although it’s been around for a while, the Hyper-V Default Switch is often misused or not given the credit it actually deserves. Let’s take a quick look at what it does, how it works and when you should use it.


Starting with the Windows 10 Creators Update (build 1709), Hyper-V includes a special virtual switch — the Default Switch. It’s called this because it’s the only switch installed automatically… ummm…. by ‘Default’. This was done to bring Hyper-V (kinda) in-line with simple NAT network sharing offerings from competing virtualization platforms like VirtualBox. This is not something you need to set up (you can’t, actually) or install — it’s just available and ready for you to use.

How it works (briefly)

The Default Switch leverages Internet Connection Sharing (ICS) and gives it a whole new purpose. It creates a dynamic private address space for any connected VMs, provides a rudimentary DHCP server to automatically assign addresses within that space and then NATs traffic to and from connected VMs so they can share your host’s physical network card. Pretty cool, right? In other words, it turns you host machine into a very very very simple router and allows the VMs to access the host and the internet.

Interestingly, it also carries forward a few other features from the old ICS days, namely the hosts.ics file. This file is automatically generated and maintained by the Default Switch. What this means is that it creates a mapping between the assigned address given to your VM and it’s reported hostname with a domain appended. So, you can access your VMs simply by That’s very cool. Nothing to maintain, nothing to set up. You can check this out yourself by opening %systemroot%\system32\drivers\etc\hosts.ics. I should note though, this does not replace or act like a real DNS system — the host can use this file to resolve by name, but the guest VMs cannot use that file to look each other up by name.

Top 3 Drawbacks

Although this feature is pretty great, it does have some drawbacks.

1. Dynamic IP assignment

The built-in pseudo DHCP server that assigns addresses definitely makes life easier in many cases, however, it cannot be disabled and cannot be customized. You have no control over the assigned address and cannot set a static IP on your VM. This is detrimental if you wanted to set up a server or something else that requires a predictable address for port forwarding.

2. Fixed domain assignment

I know, you thought was dead… I know I certainly hoped it was. But, in this case, it’s very much alive. While it’s very cool that you can fire up a VM and access it by name seconds later via this domain name, it really sucks that you cannot change that domain name! This spells trouble for situations where you have domain-specific test-setups, providing domain services, certificates, and so many many other issues.

3. Port forwarding does not work

This is, if you think about it, a natural extension of point 1 above. If you have a dynamic address, how would you setup the networking rules to forward ports? Forward to where? It’s a moving target. This is a huge problem especially for working with Linux systems where SSH tunnels are just about the only way to work with a GUI when running within Hyper-V. In fact, no form of SSH tunnelling works properly as far as I can tell. It just cannot be done, it will fail with obscure error messages… don’t even waste your time trying. If someone has figured a way around this, by the way, PLEASE let me know in the comments!!!

When to use the Default Switch

Briefly: Use the default switch whenever the above 3 drawbacks don’t apply to your usage scenario! Seriously, the Default Switch is super simple and such a quick way to provide internet/network access to your VM. Really, anytime that the domain name doesn’t matter to you and you do not need to forward ports, the Default Switch is a great candidate for quick setup. If you need control over the network in question, the assigned IP address or the domain name, then set up a dedicated NAT network (I did an article on how to do that with just 3 PowerShell commands!) and save yourself a ton of time and head-scratching.

Final thoughts

I could go much more in-depth into this issue, but I think this covers the main points. As long as you keep the 3 points outlined in this article in mind, you should have no problem deciding when you can save time and use the Default Switch versus when it’s worth the extra effort to set up your own NAT network in Hyper-V. Thanks for reading my techie-thoughts on this issue. Have any comments? Suggestions? Want to add your tips? Things you want me to cover in a future article? Comment below!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu