After 24H2 update, the host's SMB shares stopped being reachable through the Default Switch network

Hi all, first time posting.

After updating to 24H2, my VMs lost access to the host's network shares.

Please note: this is different from other problems I found discussed in other places. This is not related to the problem with authentication and general network problems (169.x.x.x addresses and such).

Hours of painful troubleshooting and monitoring revealed that the host doesn't even seem to listen to SMB ports on the vEthernet (Default Switch). These ports look closed from the VMs. It's either that the server doesn't even bind to these virtual adapters, or (doubtfully) there's some extra firewall, that is not Windows Firewall, blocking access.

I can (1) reach the Internet from VMs, and (2) my shares on the host are still available to other hosts in the local network, and (3) the shares of the other hosts on the local network are still available to my VMs. The problem is specifically with the VMs connected to the Default Switch vEthernet unable to access the host's shares. Everything else works as it worked before. The Windows Firewall doesn't have to do anything with this, too (disabling it on both the host and the guest doesn't help).

For now, my workaround is connecting all my VMs to a custom External virtual switch (connected to one of my host PC's NICs). This is cumbersome, as I have to change the network every time I switch from Ethernet to Wi-Fi and back, and I'm not comfortable exposing everything to the VMs, and exposing my VMs like that. I'd much prefer NATting everything through the Default Switch as before.
WSL and Docker VMs that connect through their own Internal network vswitch, can't access host SMB shares as well.

Has anyone else encountered this? Is there a solution to make the host expose SMB through the default vEthernet again?

dsent said:

The problem is specifically with the VMs connected to the Default Switch vEthernet unable to access the host's shares.

Click to expand...

Welcome to Eleven Forum.

Is the guest VM running 24H2? Do you use a blank password for your accounts on the VM and/or the host machine? If so that would explain it. 24H2 has tighter security by default and won't let you connect without a password. I use accounts without passwords for my host and my Hyper-V VMs. When I got my first 24H2 VM I had to create a local account on the host and give it a password, then set up credentials in the 24H2 VM so that it would connect using that account name and password.

Bree said:

There are two ways to connect. The first is to create a Windows Credential for an account with a password on that other PC.

The second is to turn off the restriction on insecure logins.

Click to expand...

Thanks for the welcome!

The guest runs 23H2. The security is not the problem. I can connect to the host just fine using a custom virtual switch bound to the host's Ethernet. Actually, I've succeeded in connecting to the host's shares through the default switch. I can connect if I add a line to my hosts file, like this:
where 192.168.1.20 is my host's external Ethernet address.

Previously (before 24H2), I was able to connect to the host through its internal address, e.g. 172.23.96.1. I see this address as the default gateway if I run ipconfig /all on the guest. Now it seems that something has changed, almost like this address doesn't belong to the host anymore, but to some actual router that routes packages from the guest to the host and beyond.

It'd be okay, but the annoying consequence is that local network discovery doesn't work. I can connect to the hosts I know addresses in advance, but the DHCP server inside the Default Switch/NAT won't resolve these names. It kinda makes sense, but why it resolves the outside Internet addresses then?

I'm trying to figure out the details of this default DHCP/DNS/NAT thingy that runs automatically when I connect VMs to the default switch, but it's not very straightforward.

Are you using accounts with no password? If so the host will by default refuse to accept an incoming insecure connection after the host has been upgraded to 24H2. You could enable insecure guest logons for the host's 24H2.

Microsoft said:

1. Select Start, type gpedit.msc, and select Edit group policy.
2. In the left pane under Local Computer Policy, navigate to Computer Configuration\Administrative Templates\Network\Lanman Workstation.
3. Open Enable insecure guest logons, select Enabled, then select OK.

Click to expand...

With all due respect, this has NOTHING to do with security. I don't use accounts with no passwords, and I can connect to the server using the host's external address. The problem is completely different and has no connection whatsoever with the changes in security (I haven't used SMB1 or accounts with no passwords in years, so the changes didn't affect me at all).

The changes I'm trying to figure out are the changes to how virtual switches work in Hyper-V, especially NAT, DHCP and DNS in the Default Switch. Something has changed in these after the update, but I'm not sure yet, what exactly.

dsent said:

The changes I'm trying to figure out are the changes to how virtual switches work in Hyper-V, especially NAT, DHCP and DNS in the Default Switch. Something has changed in these after the update, but I'm not sure yet, what exactly.

Click to expand...

My host machine is still on 23H2. It hasn't been offered 24H2 yet. Only its guests are on 24H2. I'm in no hurry to force the 24H2 update onto it, others who have a 24H2 host may be able to help.

The changes to security in 24H2 are very real. I've had to cope with them on all my other machines, both physical and VM, that now have 24H2.

Bree said:

The changes to security in 24H2 are very real. I've had to cope with them on all my other machines, both physical and VM, that now have 24H2.

Click to expand...

I know the changes are real, it's just that they are not relevant to me specifically. I'm trying to stay up-to-date with the security stuff, and it's been about at least 15 years since I used passwordless accounts for anything.

I've pinpointed the problem to the implementation of DHCP and DNS in the default vEthernet switch, but still can't fully figure out if it's even possible to revert to the old behavior.

Anyway, thanks for trying to help! I guess it will be helpful to other people who can't connect to the shares because of the security changes.