Troubleshooting GOAD on Windows with VMware: VMnet routing and WinRM 5986 issues

[daviosardinha]

# Troubleshooting GOAD on Windows with VMware: VMnet routing and WinRM 5986 issues

## Context

When installing GOAD on a Windows host using VMware, the lab machines may boot correctly, but Ansible can later fail during provisioning with errors such as:


UNREACHABLE! => ssl: HTTPSConnectionPool(host='192.168.100.x', port=5986)
Failed to establish a new connection
Connection refused
Read timed out

This does not always mean WinRM is broken immediately. In some cases, the Windows host is routing traffic to the wrong interface, usually WiFi, instead of the VMware host-only adapter.

The troubleshooting should be done in this order:

1. First validate the Windows host routing and VMware VMnet configuration.
2. Only after routing is correct, repair WinRM HTTPS inside the affected Windows VMs.

The expected GOAD IP mapping is usually:

DC01  -> 192.168.100.10
DC02  -> 192.168.100.11
DC03  -> 192.168.100.12
SRV02 -> 192.168.100.22
SRV03 -> 192.168.100.23

---

1. Check the Windows host routing first

From the Windows host, test WinRM HTTPS reachability:

Test-NetConnection 192.168.100.10 -Port 5986
Test-NetConnection 192.168.100.11 -Port 5986
Test-NetConnection 192.168.100.12 -Port 5986
Test-NetConnection 192.168.100.22 -Port 5986
Test-NetConnection 192.168.100.23 -Port 5986

A healthy result should look like this:

InterfaceAlias   : VMware Network Adapter VMnet2
SourceAddress    : 192.168.100.1
TcpTestSucceeded : True

If the result shows something like this:

InterfaceAlias   : WiFi
SourceAddress    : 172.20.10.x
TcpTestSucceeded : False

then the issue is not WinRM yet. The Windows host is routing traffic through WiFi instead of the VMware host-only adapter.

---

2. Validate VMware VMnet configuration

Open VMware Virtual Network Editor as Administrator.

Make sure the VMnet used by GOAD is configured as:

Type:          Host-only
Subnet IP:     192.168.100.0
Subnet mask:   255.255.255.0
Host adapter:  Connected / enabled
DHCP:          Disabled preferred

Example:

VMnet2 -> Host-only -> 192.168.100.0/24

Also make sure the GOAD VMs are attached to this same VMnet on their lab/internal adapter.

---

3. Check the VMware host adapter on Windows

Run PowerShell as Administrator:

Get-NetAdapter | Where-Object {
    $_.Name -like "*VMware*" -or $_.InterfaceDescription -like "*VMware*"
}

Get-NetIPAddress | Where-Object {
    $_.IPAddress -like "192.168.100.*"
}

route print -4

The Windows host should have a VMware adapter with:

IPAddress: 192.168.100.1
Prefix:    /24

And the route table should contain something equivalent to:

192.168.100.0/24 -> On-link -> 192.168.100.1

If 192.168.100.1 is missing, assign it manually.

Replace the interface index if needed. In this example, VMnet2 had interface index 4.

Set-NetIPInterface -InterfaceIndex 4 -Dhcp Disabled

Get-NetIPAddress -InterfaceIndex 4 -AddressFamily IPv4 |
Remove-NetIPAddress -Confirm:$false

New-NetIPAddress `
  -InterfaceIndex 4 `
  -IPAddress 192.168.100.1 `
  -PrefixLength 24

Then confirm again:

Get-NetIPAddress -InterfaceIndex 4 -AddressFamily IPv4
route print -4

Now retest the GOAD machines:

Test-NetConnection 192.168.100.10 -Port 5986
Test-NetConnection 192.168.100.11 -Port 5986
Test-NetConnection 192.168.100.12 -Port 5986
Test-NetConnection 192.168.100.22 -Port 5986
Test-NetConnection 192.168.100.23 -Port 5986

If the output now shows:

InterfaceAlias   : VMware Network Adapter VMnet2
SourceAddress    : 192.168.100.1

then the host routing issue is fixed.

---

4. Repair WinRM HTTPS inside affected Windows VMs

After the VMware routing is correct, some VMs may still fail on port 5986.

If the VM has the correct GOAD IP but Test-NetConnection <VM-IP> -Port 5986 fails with Connection refused or timeout, repair WinRM HTTPS inside that VM.

Open PowerShell as Administrator inside the affected VM and run:

Set-Service WinRM -StartupType Automatic
Start-Service WinRM

$cert = New-SelfSignedCertificate `
  -DnsName $env:COMPUTERNAME `
  -CertStoreLocation Cert:\LocalMachine\My

winrm delete winrm/config/Listener?Address=*+Transport=HTTPS 2>$null

winrm create winrm/config/Listener?Address=*+Transport=HTTPS "@{Hostname=`"$env:COMPUTERNAME`";CertificateThumbprint=`"$($cert.Thumbprint)`"}"

New-NetFirewallRule `
  -DisplayName "WinRM HTTPS 5986" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 5986 `
  -Action Allow `
  -Profile Any

Restart-Service WinRM

Then verify inside the VM:

winrm enumerate winrm/config/listener
Get-NetTCPConnection -LocalPort 5986 -State Listen

The HTTPS listener should show:

Transport = HTTPS
Port = 5986
Enabled = true
ListeningOn = 192.168.100.x

---

5. Final validation from the Windows host

From the Windows host, run:

Test-NetConnection 192.168.100.10 -Port 5986
Test-NetConnection 192.168.100.11 -Port 5986
Test-NetConnection 192.168.100.12 -Port 5986
Test-NetConnection 192.168.100.22 -Port 5986
Test-NetConnection 192.168.100.23 -Port 5986

All machines should return:

InterfaceAlias   : VMware Network Adapter VMnet2
SourceAddress    : 192.168.100.1
TcpTestSucceeded : True

Once all machines are reachable on 5986, rerun the GOAD install/provisioning step.

---

Summary

If Test-NetConnection shows InterfaceAlias : WiFi, fix VMware VMnet/routing first.

If Test-NetConnection uses the correct VMware VMnet adapter but 5986 still fails, repair the WinRM HTTPS listener inside the affected VM.

The correct final state is:

192.168.100.10:5986 -> True via VMware Network Adapter VMnet2
192.168.100.11:5986 -> True via VMware Network Adapter VMnet2
192.168.100.12:5986 -> True via VMware Network Adapter VMnet2
192.168.100.22:5986 -> True via VMware Network Adapter VMnet2
192.168.100.23:5986 -> True via VMware Network Adapter VMnet2