# Unusual WinRM connection issue **URL:** \ **Category:** Ansible Project\ **Tags:** windows\ **Created:** [May 27, 2016, 2:26pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582 "2016-05-27T14:26:32Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [May 27, 2016, 2:26pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/1 "2016-05-27T14:26:32Z")
I have a selected few workgroup Windows server 2012 R2 servers that give the following error: \<10.128.44.37\> ESTABLISH WINRM CONNECTION FOR USER: ansible\_user on PORT 5986 TO 10.128.44.37 server\_101 | UNREACHABLE! =\> { “changed”: false, “msg”: “ntlm: (‘Connection aborted.’, error(104, ‘Connection reset by peer’))”, “unreachable”: true } I am using ntlm with Ansible 2.1.0.0 and pywinrm [kerberos] 2RC4. I have tested the port is open, recreated the listeners, run a curl to the server which delivers a successful 411 response. Any ideas on further troubleshooting? ---
**Author:** ![Matt\_Davis](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matt\_Davis](https://forum.ansible.com/u/Matt_Davis)\ **Post date:** [May 27, 2016, 5:48pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/2 "2016-05-27T17:48:53Z")
Hey Mike, Unfortunately pywinrm currently has _zero_ logging/diagnostic capabilities (something I’d like to correct for troubleshooting stuff like this). Meantime… A couple of things to try: - Does it work with Basic auth and a local user on that same box? - Any chance you could run with Fiddler in the middle? Just run Fiddler on some Windows box, configure it to capture/decrypt HTTPS and to allow external connection, then on your Ansible controller, export HTTPS\_PROXY=http://(ip-of-fiddler-box):8888/ and go watch the fun. I’m mostly just curious where the connection reset is occurring, as there are numerous round-trips involved here (eg, is it NTLM auth failure, resource issue, or something else?). Thanks, -Matt ---
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [May 30, 2016, 7:45am UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/3 "2016-05-30T07:45:48Z")
For testing locally I’m assuming you mean Test-WSMan -Authentication Basic -Credential ? I am currently connecting on 5986 with ignore certificate validation turned on. So in that case I would add -UseSSL switch on the Test-WSMan. Currently running Test-WSMan -Authentication Basic -Credential gives: Test-WSMAN : \\The WinRM client cannot process the request. Unencrypted traffic is currently disabled in the client configuration. Change the client configuration and try the request again. \\ At line:1 char:1 Normally I would say that would mean mean configuring AllowUnencrypted on Winrm Client, however the other working systems do not have this configured. Running Test-WSMAN -Authentication Negotiate -Credential “” -ComputerName localhost returns: wsmid : [http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd](http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd) ProtocolVersion : [http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd](http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd) ProductVendor : Microsoft Corporation ProductVersion : OS: 6.3.9600 SP: 0.0 Stack: 3.0 I will try the Fiddler method shortly and return the results. ---
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [May 31, 2016, 4:16pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/4 "2016-05-31T16:16:09Z")
Seems a little odd but having set the HTTPS\_PROXY to the fiddler box, when I run a win\_ping to the problem server it does not register any connection in fiddler. ---
**Author:** ![Matt\_Davis](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matt\_Davis](https://forum.ansible.com/u/Matt_Davis)\ **Post date:** [June 1, 2016, 5:41pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/5 "2016-06-01T17:41:50Z")
Sorry, by “local user” I just meant using a non-domain user via pywinrm/Ansible. But yeah, for Basic to work, you’d have to (temporarily) enable unencrypted auth with something like: Set-Item WSMan:\localhost\Service\AllowUnencrypted $true The HTTPS\_PROXY not working seems odd- I use it dozens of times a day… Sure you’ve got it exported? The problem is almost certainly on the control-machine side, as it’d just hang if the envvar worked and Fiddler wasn’t configured properly. ---
**Author:** ![Jonathan\_Anderson](https://avatars.discourse-cdn.com/v4/letter/j/45deac/32.png) [@Jonathan\_Anderson](https://forum.ansible.com/u/Jonathan_Anderson)\ **Post date:** [June 1, 2016, 10:43pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/6 "2016-06-01T22:43:50Z")
Actually I had to type winrm set winrm/config/service ‘@{AllowUnencrypted=“true”}’ before it would work for me. ---
**Author:** ![gdelgado2](https://avatars.discourse-cdn.com/v4/letter/g/cdc98d/32.png) [@gdelgado2](https://forum.ansible.com/u/gdelgado2)\ **Post date:** [June 4, 2016, 3:09am UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/7 "2016-06-04T03:09:53Z")
You can also try to run the below PS script on the hosts to ensure all the WinRm options have been taken care of to allow Ansible to connect to it. [https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1](https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1) ---
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [June 6, 2016, 12:20pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/8 "2016-06-06T12:20:20Z")
I’m beginning to think this might be as a result of the problem servers being templated in VMWare perhaps? ---
**Author:** ![j.r.hawkesworth](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@j.r.hawkesworth](https://forum.ansible.com/u/j.r.hawkesworth)\ **Post date:** [June 6, 2016, 12:35pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/9 "2016-06-06T12:35:39Z")
Interesting. This change was recently added so you can force the ConfigureRemotingForAnsible.ps1 to generate a new self-signed cert by running like this: .\ConfigureRemotingForAnsible.ps1 -ForceNewSSLCert true [https://github.com/ansible/ansible/pull/15275](https://github.com/ansible/ansible/pull/15275) As its says in the PR ‘This is necessary when a CN name changes and the self-signed cert is no longer valid and winRM is not allowing a connection because of winRM SSL validation errors.’ Hope this helps, Jon ---
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [June 6, 2016, 12:48pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/10 "2016-06-06T12:48:10Z")
Thanks Jon, good to see it’s being well maintained. Had already gone down the route of the self-signed cert via Powershell unfortunately. I ran the ConfigureForAnsible.ps1 just in case I had missed something. Seems like the same issue though: \ ESTABLISH WINRM CONNECTION FOR USER: ansible\_user@DOMAIN on PORT 5986 TO xx.xx.xx.xx Server.domain | UNREACHABLE! =\> { “changed”: false, “msg”: “ntlm: (‘Connection aborted.’, error(104, ‘Connection reset by peer’))”, “unreachable”: true } ---
**Author:** ![j.r.hawkesworth](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@j.r.hawkesworth](https://forum.ansible.com/u/j.r.hawkesworth)\ **Post date:** [June 6, 2016, 11:09pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/11 "2016-06-06T23:09:12Z")
Anything in the event logs? Since it seems to be a connection reset, I’d hope there might be a message on the windows machine to say why. ---
**Author:** ![Christoph\_Wegener](https://avatars.discourse-cdn.com/v4/letter/c/57b2e6/32.png) [@Christoph\_Wegener](https://forum.ansible.com/u/Christoph_Wegener)\ **Post date:** [June 7, 2016, 2:04pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/12 "2016-06-07T14:04:41Z")
If you are referring to cloning a Windows machine without proper sysprep usage then that’s very well possible. I remember seeing some WinRM blogs where people had problems due to duplicate SIDs … not 100% sure though. ---
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [June 7, 2016, 3:32pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/13 "2016-06-07T15:32:09Z")
Yes have seen the articles but this was a properly sysprepped template. Have recreated listeners, changed self-signed cert and still seems to yield the same result. Jon any particular logs I should focus on? The Windows Remote Management and security logs don’t seem to show anything out of the ordinary. ---
**Author:** ![j.r.hawkesworth](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@j.r.hawkesworth](https://forum.ansible.com/u/j.r.hawkesworth)\ **Post date:** [June 7, 2016, 4:18pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/14 "2016-06-07T16:18:42Z")
Sorry, I don’t have a specific suggestion where to look. Sometimes I toss all the event logs and then poke things rather than filter for a specific event category. One of my colleagues tells me there’s an rc6 for pywinrm 0.2 - might be worth trying that if you aren’t on it already. ---
**Author:** ![Matt\_Davis](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matt\_Davis](https://forum.ansible.com/u/Matt_Davis)\ **Post date:** [June 7, 2016, 5:03pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/15 "2016-06-07T17:03:03Z")
Seriously- best thing you could do is figure out why Fiddler isn’t working for you and get a trace… Knowing where it’s failing in the process can really narrow some things down. ---
**Author:** ![Trond\_Hindenes](https://avatars.discourse-cdn.com/v4/letter/t/96bed5/32.png) [@Trond\_Hindenes](https://forum.ansible.com/u/Trond_Hindenes)\ **Post date:** [June 7, 2016, 9:03pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/16 "2016-06-07T21:03:21Z")
I would troubleshoot the windows side first. Are you able to psremote from a windows node to the “problem” node using 5986 (ssl)? ---
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [June 24, 2016, 12:48pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/17 "2016-06-24T12:48:18Z")
09:12:58:4855 fiddler.network.https\> HTTPS handshake to 10.128.44.38 (for #2) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm 09:13:34:4067 fiddler.network.https\> HTTPS handshake to 10.128.44.38 (for #3) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm 09:17:40:7434 fiddler.network.https\> HTTPS handshake to 10.128.44.38 (for #4) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm 09:18:08:8209 fiddler.network.https\> HTTPS handshake to 10.128.44.38 (for #5) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm 09:21:23:7477 fiddler.network.https\> HTTPS handshake to 10.128.44.38 (for #6) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm 14:38:02:7271 fiddler.network.https\> HTTPS handshake to 10.128.44.37 (for #2) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm I should probably add that to be FIPS 140-2 compliant the server have the following: Protocols: TLS 1.0, TLS 1.1, TLS 1.2 Ciphers Enabled: Triple DES 168, AES 128/128, AES 256/256 Hashes Enabled: SHA, SHA 256, SHA 384, SHA 512 Key Exchanges: PKCS, ECDH SSL Cipher Suite Order changed: TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384\_P521,TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384\_P384,TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384\_P256,TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA\_P521,TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA\_P384,TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA\_P256,TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256\_P521,TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA\_P521,TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256\_P384,TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256\_P256,TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA\_P384,TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA\_P256,TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384\_P521,TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384\_P384,TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256\_P521,TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256\_P384,TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256\_P256,TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384\_P521,TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384\_P384,TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA\_P521,TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA\_P384,TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA\_P256,TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA256\_P521,TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA256\_P384,TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA256\_P256,TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA\_P521,TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA\_P384,TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA\_P256,TLS\_DHE\_DSS\_WITH\_AES\_256\_CBC\_SHA256,TLS\_DHE\_DSS\_WITH\_AES\_256\_CBC\_SHA,TLS\_DHE\_DSS\_WITH\_AES\_128\_CBC\_SHA256,TLS\_DHE\_DSS\_WITH\_AES\_128\_CBC\_SHA,TLS\_DHE\_DSS\_WITH\_3DES\_EDE\_CBC\_SHA,TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA256,TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA,TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256,TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA,TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA ---
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [June 24, 2016, 1:45pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/18 "2016-06-24T13:45:26Z")
It might also help to add that all the servers it seems to be failing on are Windows Server 2012 R2 with IIS installed and a few sites with different SSL Certificates installed. ---
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [September 1, 2016, 3:55pm UTC](https://forum.ansible.com/t/unusual-winrm-connection-issue/21582/19 "2016-09-01T15:55:25Z")
So courtesy of a few colleagues we have a solution. By specifying the fqdn in the inventory rather than the ip, and making sure the Ansible control machine could resolve the fqdn to the ip, the connection is now successful.