Windows Server not listening to radius port after vmware migration

acebmxer

After migrating our windows server that host our Duo Proxy manager having an issue.

[info] Testing section 'radius_client' with configuration:
[info] {'host': '192.168.20.16', 'pass_through_all': 'true', 'secret': '*****'}
[error] Host 192.168.20.16 is not listening for RADIUS traffic on port 1812
[debug] Exception: [WinError 10054] An existing connection was forcibly closed by the remote host

After the migration I did have to reset the IP address and I did install the Xen tools via windows update.

Any suggestions? I am thinking I may have the same issue if i spin up the old vm as the vmware tools were removed which i think effected that nic as well....

acebmxer

It seams after another restart or two of the server and repallying the latest update (same version that was installed) and restarting its services a few times. It appears to be working...

I now have a fear I might have issues when i go to migrate our Windows Active Directory master. I have moved over our backup dc (dc2) which runs our DHCP server and backup DNS. That appears to be working.

Is there any particular precautions i should be taking prior to moving that server? Previous steps followed were

remove vmware tools and reboot server.
once back up shut down server.
remove any old snapshots(none to remove)
take a snapshot
start the migration process.
adjust cpu topology.
start vm log in adjust date and time and IP address as needed.
shut down vm enable vm tools via windows update and attach iso made with management tools.
Power on vm let it reboot as needed for driver installs
install management tools (let windows update handle drivers).
Run windows updates until all updates applied.

Should I take the 1 / final snapshot prior to removing vmware tools? Incase of issue i can spin up old vm? Open to ideas and suggestions.

DustinB

@acebmxer Yeah why wouldn't you take a snapshot before altering your production workloads?

As a heads up, XO Backups are not application aware, so backing up a DC or Database Server can cause you to lose data if the database is in the middle of a write operation.

But yeah, absolutely make a backup before you migrate a workload so you have a perfect system state to restore too should something go sideways. Of course the VMware/XCP-ng Drives aren't critical to the VM operating, they do offer better performance.

acebmxer

@DustinB

I was following the directions stated here - https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/

Which states to remove tools then take a fresh snapshot.

VMFS 6 (6.7 and newer)
For VMFS 6, the VM needs to be shut down. Follow these steps:

Uninstall VMware tools before migration.
Remove all snapshots attached to the VM.
Ensure no ISO files are mounted to the VM.
Shut down the VM.
Take a fresh snapshot.
Start the migration process.

Also I am aware of the XO backups are not application aware. We use Veeam for that backup data. And i still have Veeam backups from the Servers to fall back onto. I just wasn't sure if there were any other precautions i should be taking or thinking about.

DustinB

@acebmxer Right, before you migrate from ESXi to XCP-ng, you must remove the VMWare tools.

Before doing that though, take a snapshot (or proper backup) ahead of any changes this way you have a way to rotate back if something isn't working.

nikade

@acebmxer said in Windows Server not listening to radius port after vmware migration:

After migrating our windows server that host our Duo Proxy manager having an issue.

[info] Testing section 'radius_client' with configuration:
[info] {'host': '192.168.20.16', 'pass_through_all': 'true', 'secret': '*****'}
[error] Host 192.168.20.16 is not listening for RADIUS traffic on port 1812
[debug] Exception: [WinError 10054] An existing connection was forcibly closed by the remote host

After the migration I did have to reset the IP address and I did install the Xen tools via windows update.

Any suggestions? I am thinking I may have the same issue if i spin up the old vm as the vmware tools were removed which i think effected that nic as well....

On your VM that runs the Duo Auth Proxy service, check if the service is actually listening on the external IP or if its just listening on 127.0.0.1
If its just listening on 127.0.0.1 you can try to repair the Duo Auth Proxy service, take a snapshot before doing so.

Also, if you're using encrypted passwords in your Duo Auth Proxy configuration you probably need to re-encrypt them, just a heads up, since I just had to do so after migrating one of ours.

Edit:
Do you have the "interface" option specified in your Duo Auth Proxy configuration?