Windows 10 and public interface cause WinRM problem with vagrant

[kaltokri]

Hi, first I want to thank you for the great work!

I had the following problem with Windows10: In the created virtualbox-iso the network interface is set to public. Because of that vagrant is unable to connect the the created vm by using WinRM.

I've read the Autounattend.xml and saw the step with fixnetwork.ps1. Because I used activated updates I suspected that the network interface is switched back to private by a Windows-Udpate.

So I added this last step to Autounattend.xml:

                <SynchronousCommand wcm:action="add">
                    <CommandLine>cmd.exe /c C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -File a:\fixnetwork.ps1</CommandLine>
                    <Description>Fix public network</Description>
                    <Order>101</Order>
                    <RequiresUserInput>true</RequiresUserInput>
                </SynchronousCommand>

Now the interface is private and vagrant is happy again. Can someone else confim this?

[kaltokri]

I have the problem again. Even with the change above. It looks like every new network connection is public be default (see kb2578723). I try to find a way to change this behaviour.

[kaltokri]

If I created a vagrant base box on networkA and use it in the same network the network location in a created vm is Private. But if I use the box in a different network (e.g. a branch office) the Windows system of the vm detects this change and set the network location to Public.

This behaviour can be modified by group policies:

• Open "gpedit.msc" -> Go to Computer Configration –> Windows Settings –> Security Settings –> Network list manager
• Set "Identifying Networks" to Private.

It creates the file Registry.pol in C:\Windows\System32\GroupPolicy\Machine. I'll try to add this file to the packer build to avoid problems in other networks.

[StefanScherer]

@kaltokri That's great. I also suffered from this with Windows 7 boxes in the past. Is there a way to automate this, so we could add that to the provisioning in the packer builds?

[kaltokri]

Yes, I think it is possible. I'll try to add it for Windows 10. I hope the .pol files are compatible between differents Windows versions. At least the part which is effected here.

[kaltokri]

I've added the .pol file to the base box and verified with gpedit.msc if it is used, but the network connection still remains in location Public. Maybe some step is missing.

Now I'll try to add the registry key instead of the .pol file.

[kaltokri]

It doesn't work. No matter what I try, the network location ends up in location Public. The only reliable way to solve it is the included fixnetwork.ps1. I'm going to add this PowerShell script to the vm (e.g. copy it to C:\Windows\fixnetwork.ps1) and create a scheduled task thats runs on startup with schtasks command line tool.

[StefanScherer]

@kaltokri Thanks for trying so hard. I also thought I found a solution a year ago, but then it also didn't work in all situations.

[kaltokri]

I've added a scheduled task which is executed on system startup to Autounattend.xml, but it doesn't help:

• The task is executed before the network is found and configured. Scheduled tasks has an option to wait until a network is available, but this option can not be set by schtask or at command line options.
• Also the option to execute the task only if a power supply is attached (... AC power) is activated by default. On my tests I didn't use a power supply. This option can not be changed by schtask. If a developer with a notebook makes a vagrant up without a connected AC power supply it will fail and he will never understand why.

One option is to use autologin and add it to the autostart folder. But if you change your network "on-the-fly" the location will be adapted dynamicly by Windows. Possible scenario vagrant up at work, hibernate your notebook, start it back at home and run vagrant provision. So it is not a reliable solution to change network location only once.

For our internal use case (which is: test vm's used by vagrant with VirtualBox and NAT ONLY on developer systems, so no other network node is able to contact the vm) I've decided to disable the firewall of the vm at the moment. This solves the problem but is not viable for ANY other use case, because of the hugh impact to security!

I invest some time later and try a scheduled task which runs every 60(?) seconds to reset the location. The tasks can be configured and exported in Windows Task Scheduler and imported by schtask /XML option.

Any other idea? :o)

[sneal]

I built a new Win10 box using the packer-windows templates and I can't repro this. The network connection in my Win10 vagrant box is set to private.

[kaltokri]

@sneal Did you test the box in different networks (e.g. at work and at home)? It is a very special situation, but I can reproduce it every time.

[sneal]

@kaltokri Do you know specific setup I need to reproduce the issue? I'm running VBox 5.0.12 with packer-windows latest on an OS X Yosemite host using WiFi.

[JakeStevenson]

I can reproduce this problem as well. When I set up the box using packer at work, it is broken when I go home, and vice-versa.

At work the network connection inside windows shows as private, while at home it is public. If I use packer to create the box at home, the opposite occurs.

This is on El Capitan using wifi on both networks with latest pull from this repo and virtualbox 5.0.12

[joefitzgerald]

OK this is going to sound weird, but 1) what is the IP you're getting in each location, and 2) I'm assuming a) DNS is your Active Directory server(s) at work, and b) you don't run Active Directory at home...?

[JakeStevenson]

Yes, at work Active Directory is serving up DNS, but neither my laptop or VM is joined to the domain. At home I'm not using AD, just a generic ATT router.

In both situations the guest gets the ip 10.0.2.15. The guest VM is set for NAT, so this makes sense.

I can confirm that it will identify the network my laptop was connected to as "private" whenever packer was used, and the other network as "public", which is the cause of the connection troubles.

[psprowls]

I have the same issue. It works fine with virtualbox, but with vmware I can get a private connection on the box it was created, but otherwise I get public and Vagrant fails to connect via winrm. I am also on El Capitan/Fusion 8. I should add, that when I try and bring up the boxes they are both vmware NAT networks, but on different machines.

[psprowls]

I have tried this about 5 times now with exactly the same results. I should also note that win12r2 works fine on both VMware and VirtualBox. I am going to try to add a provisioner that will add fixnetworks.ps1 to the runonce key. I think that will run on the first vagrant boot...

[ilovemysillybanana]

Did anyone ever find a fix for this? I'm unfortunately suffering from this currently.

[jugatsu]

@ilovemysillybanana i'm using this one

winrm.ps1

if([environment]::OSVersion.version.Major -ge 6) {
  # You cannot change the network location if you are joined to a domain, so abort
  if(1,3,4,5 -contains (Get-WmiObject win32_computersystem).DomainRole) { return }

  # Get network connections
  $networkListManager = [Activator]::CreateInstance([Type]::GetTypeFromCLSID([Guid]"{DCB00C01-570F-4A9B-8D69-199FDBA5723B}"))
  $connections = $networkListManager.GetNetworkConnections()

  $connections |foreach {
  	Write-Host $_.GetNetwork().GetName()"category was previously set to"$_.GetNetwork().GetCategory()
  	$_.GetNetwork().SetCategory(1)
  	Write-Host $_.GetNetwork().GetName()"changed to category"$_.GetNetwork().GetCategory()
  }
}

Write-Output "Enabling PSRemoting"
Enable-PSRemoting -Force
winrm set winrm/config '@{MaxTimeoutms="7200000"}'
winrm set winrm/config/winrs '@{MaxShellsPerUser="100"}'
winrm set winrm/config/winrs '@{MaxConcurrentUsers="30"}'
winrm set winrm/config/winrs '@{MaxProcessesPerShell="100"}'
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="1024"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/client/auth '@{Basic="true"}'