search

joefitzgerald / packer-windows

Windows Packer Templates
MIT License
1.63k stars 1.12k forks source link

Windows 10 and public interface cause WinRM problem with vagrant #188

Open kaltokri opened 8 years ago

kaltokri commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 6 years ago

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

jugatsu commented 6 years ago

@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"}'