Packer: communicator/WinRM: Proxy support

[pearcec]

I set our proxy via $env:https_proxy and $env:http_proxy. It works fine for everything except the WinRM provisioner. I tried setting the netsh winhttp import proxy source=ie and successfully connect via Test-WSMan. I found this issue indicating it should work with RoundTripper. Has anyone been able to make this work?

https://github.com/masterzen/winrm/issues/61

[pearcec]

Here is the error message. I did validate via WireShark the calls are not going out through the proxy.

2017/01/17 13:00:38 packer.exe: 2017/01/17 13:00:38 [INFO] Attempting WinRM connection...
2017/01/17 13:00:38 packer.exe: 2017/01/17 13:00:38 [DEBUG] connecting to remote shell using WinRM
2017/01/17 13:00:59 packer.exe: 2017/01/17 13:00:59 [ERROR] connection error: unknown error Post https://13.90.94.107:5986/wsman: dial tcp 13.90.94.107:5986: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
2017/01/17 13:00:59 packer.exe: 2017/01/17 13:00:59 [ERROR] WinRM connection err: unknown error Post https://13.90.94.107:5986/wsman: dial tcp 13.90.94.107:5986: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

[pearcec]

I wonder if it isn't working. I tried just connecting. Is there something that needs to be prepped during the build?

Enter-PSSession -ComputerName 13.92.188.213 -Credential packer -UseSSL -SessionOption $options
Enter-PSSession : Connecting to remote server 13.92.188.213 failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ Enter-PSSession -ComputerName 13.92.188.213 -Credential packer -UseSS ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (13.92.188.213:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

I built this with an azure-arm resource

2017/01/18 15:44:18 packer.exe: 2017/01/18 15:44:18 [INFO] Packer version: 0.12.1
2017/01/18 15:44:18 packer.exe: 2017/01/18 15:44:18 Packer Target OS/Arch: windows amd64
2017/01/18 15:44:18 packer.exe: 2017/01/18 15:44:18 Built with Go Version: go1.7.3

Here is a snip of the template.

  "builders": [{
    "type": "azure-arm",

    "client_id": "{{user `client_id`}}",
    "client_secret": "{{user `client_secret`}}",
    "resource_group_name": "{{user `resource_group`}}",
    "storage_account": "{{user `storage_account`}}",
    "subscription_id": "{{user `subscription_id`}}",
    "object_id": "{{user `object_id`}}",
    "tenant_id": "{{user `tenant_id`}}",

    "capture_container_name": "images",
    "capture_name_prefix": "packer-Windows-2012-R2",

    "os_type": "Windows",
    "image_publisher": "MicrosoftWindowsServer",
    "image_offer": "WindowsServer-HUB",
    "image_sku": "2012-R2-Datacenter-HUB",

    "communicator": "winrm",
    "winrm_use_ssl": "true",
    "winrm_insecure": "true",
    "winrm_timeout": "5m",
    "winrm_username": "packer",
    "winrm_password": "packer",

    "location": "East US",
    "vm_size": "Standard_A2"
    }],

[pearcec]

I was definitely able to connect through the local proxy. It seems the winrm_password didn't get set. So I dug it out of the deployment parameter passed to the azure-template. My best guess is the winrm is using the https_proxy.

Enter-PSSession -ComputerName 13.90.97.46 -Credential packer -UseSSL -SessionOption $options
[13.90.97.46]: PS C:\Users\packer\Documents>

[mwhooker]

I don't believe we support winrm over proxy. It should be fairly simple to implement, though.

Either need to change masterzen/winrm so it passes Proxy: http.ProxyFromEnvironment to the http transport here

https://github.com/masterzen/winrm/blob/ab3c4024d17ac6647c4d0ecbbb12de72c272e64c/http.go#L43-L47

(not sure how ntlm works)

or make our own transport that wraps https://github.com/masterzen/winrm/blob/HEAD/http.go#L42

I think probably changing masterzen is best. This is a non-invasive change and should benefit others.

any volunteers?

[mwhooker]

there's a PR to masterzen here https://github.com/masterzen/winrm/pull/66/files

If you want to try to update the dep in packer and test that the change works, that would help move this forward

[pearcec]

@mwhooker Thanks for the patch. I had the same line of code. I was actually in the middle of testing it yesterday. I can confirm it works. I see @masterzen already merged it.

==> azure-arm: Waiting for WinRM to become available...
2017/01/26 07:25:07 packer.exe: 2017/01/26 07:25:07 [INFO] Attempting WinRM connection...
2017/01/26 07:25:07 packer.exe: 2017/01/26 07:25:07 [DEBUG] connecting to remote shell using WinRM
2017/01/26 07:25:11 ui: ==> azure-arm: Connected to WinRM!
==> azure-arm: Connected to WinRM!
2017/01/26 07:25:11 packer.exe: 2017/01/26 07:25:11 Running the provision hook
2017/01/26 07:25:11 ui: ==> azure-arm: Provisioning with Powershell...
==> azure-arm: Provisioning with Powershell...