Connection timeout to VM with Windows 10/11 with opened ports

Question

Connection timeout to VM with Windows 10/11 with opened ports

Alejandro Fernández 0

At my company, we are setting up VMs with Windows 10/11 as agents to remote-compile Unreal builds from our local machines. The communication channel always times out without a descriptive error message.

Our VMs are using a Network Security Group associated with the respective network interfaces for each VM (affecting 0 subnets, 4 network interfaces). This NSG has all ports opened inbound/outbound, proper priority, no firewall or extra network protection included.

But still, Unreal Horde can't maintain a connection with the VM agents for some reason. We set up some VMs in AWS in a couple minutes, opened the respective ports and they worked from the start no issues no additional config. This means we are missing something within our Azure config or there is some internal config we are not aware of.

Unreal horde uses ports: 13340,13342, 5000, 50002 and the range 7000-7010.

Any ideas?

Alejandro Fernández 0 Reputation points

2025-03-13T09:42:58.1166667+00:00
Hi Pramidha,

Appreciate your answer. We have tried without success all the previously mentioned steps:

Windows firewall is turned off

Connecting through public IP, so no VPN needed

NSG is added both to the subnet and to the individual VM's interface

Using netstat works and service is listening and running

Test-NetConnection PowerSell command works, connection is healthy

Still the Unreal Horde connection times out and we cannot figure out a reason why. As I mentioned, we tested the same setup but just the agent deployed to AWS VM and no issues found. We also deployed the agent on-premises and worked too.

There is nothing we could find about Unreal Horde specific settings needed to be adjusted for Azure VMs. Using Wireshark, we found lots of errors of the type "TCP reassembly error, new fragment overlaps old data" that were not showing up with the AWS VM.

Could it be some specific TPC packet transmission configuration within Azure VMs or internal networks?
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-17T04:56:47.6566667+00:00
Hi Alejandro Fernández,

The problem is almost certainly related to how Azure handles networking rather than Unreal Horde itself. The “TCP reassembly error, new fragment overlaps old data” message in Wireshark. That suggests something is messing with packet transmission

Azure VMs typically use an MTU of 1400 bytes, whereas AWS and most on-prem setups use 1500. If Unreal Horde is expecting larger packets and Azure is fragmenting them, that could explain the reassembly errors.

netsh interface ipv4 show subinterfaces

If MTU is lower than 1400, set it to 1400:

netsh interface ipv4 set subinterface "<INTERFACE_NAME>" mtu=1400 store=persistent

Then restart the VM and test again.

Since AWS and on-prem work fine, check if Unreal Horde is binding only to specific interfaces in Azure.

Run this inside the Azure VM:

netstat -an | findstr LISTEN

Make sure it’s listening on 0.0.0.0 (all interfaces), not just localhost (127.0.0.1). If it’s bound to the wrong interface, update its configuration.

Azure VMs sit behind an implicit Azure Load Balancer, which has a default TCP idle timeout of 4 minutes. If Unreal Horde is sensitive to connection drops, this could be a factor.

Try increasing it to 30 minutes:

az network lb rule update --resource-group <RESOURCE_GROUP> --name <RULE_NAME> --idle-timeout 30

Please refer the documents below.

https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning

https://learn.microsoft.com/en-us/cli/azure/network/lb/rule?view=azure-cli-latest

If the comment was helpful, please don't forget to click "Upvote".

If you have any further queries, please let us know we are glad to help you.

Thank You.
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-18T06:41:25.57+00:00

Hi Alejandro Fernández,

Just checking in to see if you had a chance to review the answer on your question. Feel free to reach out if you have any further queries.

If you found the information useful, please click "Upvote" on the post to let us know.

Thank You.
Alejandro Fernández 0 Reputation points

2025-03-18T09:36:31.21+00:00

Hi @Pramidha Yathipathi ,

We have already went through your answer above with no luck.

MTUs on both AWS EC2 machine and Azure VM are 1500 bytes. Unreal Horde is listening on all interfaces (0.0.0.0), and finally we updated TCP idle timeout to 30 minutes.

I'm running out of ideas, as I reviewed the components (VM, NSG, Interface, Public IP, Network and subnet) and can't see a setting that could be affecting the connexion. Still something is happening with the packets as seen in Wireshark.

What could you suggest at this point to continue investigating forward?
Alejandro.
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-19T08:24:54.66+00:00
Hi Alejandro Fernández,

As MTU 1500 bytes try by MTU is lower than 1400, set it to 1400 or 1450:

netsh interface ipv4 set subinterface "<INTERFACE_NAME>" mtu=1400 store=persistent

restart the VM and test again.

If not, Since Wireshark shows TCP reassembly errors, use TCPDump on the Azure VM to capture real-time packet data:

tcpdump -i eth0 -nn port 13340 or port 13342 or port 5000 or port 50002 or portrange 7000-7010 -vvv

Compare this to the AWS VM’s output to identify any Azure-specific packet manipulation.

Even though NSG allows traffic, Azure DDoS Protection or network intrusion prevention systems might still be interfering. If you have DDoS Protection enabled, try disabling it temporarily and test the connection

Steps to check DDoS Protection:

Go to Azure Portal → Networking → DDoS Protection Plans.

See if your VM’s network is linked to a protection plan.

If it is, try removing it and test again.

If the Unreal Horde agents are communicating with multiple services, Azure might be blocking asymmetric routing (when packets go out through one path but return via another). To allow it:

az network nic update --name <NIC_NAME> --resource-group <RESOURCE_GROUP> --enable-ip-forwarding true

If not, try deploying a virtual machine in a different Azure region, preferably one nearer to your local network, to investigate any possible regional network issues, latency, or routing inconsistencies.

If the comment was helpful, please don't forget to click "Upvote".

If the issue still persist and having any further queries, please let us know we are glad to help you.

Thank You.
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-20T04:44:47.1733333+00:00

Hi Alejandro Fernández,

Just checking in to see if you had a chance to review the comment on your question. Feel free to reach out if you have any further queries.

If you found the information useful, please click "Upvote" on the post to let us know.

Thank You.
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-21T04:24:54.9533333+00:00

Hi Alejandro Fernández,

Just checking in to see if you had a chance to review the comment on your question. Feel free to reach out if you have any further queries.

If you found the information useful, please click "Upvote" on the post to let us know.

Thank You.
Alejandro Fernández 0 Reputation points

2025-03-21T11:18:43.0166667+00:00
Hi @Pramidha Yathipathi

We tried changing MTU to 1400 and 1450, restarting VM and still the same.

The "tcpdump" is a bash command in Linux, we are using Windows machine for the Unreal Horde agent. We can capture tcp packets with Wireshark in AWS EC2 and Azure VM and share it with you here if that's an option.

No DDoS enabled in our Azure subscription.

Regarding the last command:

az network nic update --accelerated-networking true --name MyNic --resource-group MyResourceGroup

It does not work. Either way, that is an option we have already tried from the Azure UI, both enabled/disabled accelerated networking, restarting the VM, and still nothing seems to fix this issue.
Vinay B 500 Reputation points Microsoft External Staff Moderator

2025-03-24T09:06:29.25+00:00
Hello Alejandro Fernández

I understand that you tried Standard Network and Security Checks & Network Analysis and Packet Behavior as part of the troubleshooting, but yet to address the issue.

Since the issue, Unreal Horde agents on Azure VMs experience connection timeouts, despite all required ports being open and network configurations correctly applied.

You also specified that the same setup works on AWS and on-premises, suggesting an Azure-specific networking issue & logs show TCP reassembly errors possible packet fragmentation.

Azure VMs utilize network optimization features like TCP Chimney Offload, Receive Side Scaling (RSS), and Large Send Offload (LSO). Disabling these can help resolve packet fragmentation and reassembly issues.

netsh int tcp set global chimney=disabled netsh int tcp set global rss=disabled

Disabling LSO can be achieved using the following command

Disable-NetAdapterLso -Name "<AdapterName>"

You can also try enabling TCP Keep-Alive can help maintain idle connections and prevent timeouts.

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime /t REG_DWORD /d 300000 /f reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveInterval /t REG_DWORD /d 10000 /f

This will set the KeepAliveTime to 5 minutes and the KeepAliveInterval to 10 seconds.

Sometimes If regional network issues might also cause the issue, deploying your VM in a different Azure region can help identify if the problem is region-specific.

Please let us know if it was helpful, and feel free to reach out if you have any further queries.
Vinay B 500 Reputation points Microsoft External Staff Moderator

2025-03-25T03:24:00.8633333+00:00

Hi Alejandro Fernández,

Just checking in to see if you had a chance to review the comment on your question. Feel free to reach out if you have any further queries.

If you found the information useful, please click "Upvote" on the post to let us know.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-03-25T12:48:39.93+00:00

Following up on this case. Kindly confirm if the steps provided by Vinay B was useful.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-03-26T06:28:23.57+00:00

Hi Alejandro Fernández, from what I understood from the entire conversation here is Wireshark revealed the error:

"TCP reassembly error, new fragment overlaps old data"

This strongly points to issues with Azure's virtual NIC offloading or segmentation behavior.

The root cause is most likely related to Azure's NIC offloading or segmentation behavior, which differs subtly from AWS or on-prem environments. Disabling offloading and adjusting TCP/IP stack settings resolves similar packet overlap issues in many cases. Could you kindly share the logs with us once over private message. Since Wireshark has indicated TCP reassembly errors, we can conduct an analysis of the packet flow between your local machines and the Azure VMs. This might help identify anomalies or patterns that could point to the root cause.
Alfred 0 Reputation points

2025-03-26T10:22:01.2333333+00:00

Hello Arko.

I am Alfred Barbero an Unreal Engine programmer working with Alejandro.

We have modified the registry entries KeepAliveTime and KeepAliveInterval, disabled LSO and RSS but could not disable Chimney offload (does not appear as a valid command option).

After these modifications the problem still persists.

Currently Alejandro is on holidays until the 10th of April.

We can either wait until he comes back as he is our only backend programmer or I can send you the Wireshark packet capture files from both my machine and the VM sides and go from here. If you need any other logs or modifications in the Azure environment it would be really helpful if you can guide me on how to perform these actions step by step as my knowledge outside a Windows or Linux machine is limited.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-03-27T07:10:07.3333333+00:00

Hello Alfred, due to security reasons, would request you not to share the wireshark packet capture data on the public forum. There is a private chat box with Alejandro which you won't be able to access. If the matter requires urgent attention then would request you to create a fresh case for the same issue from your end and we can continue there.
Alfred 0 Reputation points

2025-03-27T08:48:38.5933333+00:00

Hello Arko.

We will wait for Alejandro to come back then.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-03-28T13:44:07.58+00:00

Would request Alejandro to open a fresh case once he returns from his leave with same content of this question. We can follow up from there. Thanks

1 answer

Your answer

Alejandro Fernández 0 Reputation points

2025-03-13T09:42:58.1166667+00:00

Hi Pramidha,

Appreciate your answer. We have tried without success all the previously mentioned steps:

Windows firewall is turned off

Connecting through public IP, so no VPN needed

NSG is added both to the subnet and to the individual VM's interface

Using netstat works and service is listening and running

Test-NetConnection PowerSell command works, connection is healthy

Still the Unreal Horde connection times out and we cannot figure out a reason why. As I mentioned, we tested the same setup but just the agent deployed to AWS VM and no issues found. We also deployed the agent on-premises and worked too.

There is nothing we could find about Unreal Horde specific settings needed to be adjusted for Azure VMs. Using Wireshark, we found lots of errors of the type "TCP reassembly error, new fragment overlaps old data" that were not showing up with the AWS VM.

Could it be some specific TPC packet transmission configuration within Azure VMs or internal networks?
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-17T04:56:47.6566667+00:00

Hi Alejandro Fernández,

The problem is almost certainly related to how Azure handles networking rather than Unreal Horde itself. The “TCP reassembly error, new fragment overlaps old data” message in Wireshark. That suggests something is messing with packet transmission

Azure VMs typically use an MTU of 1400 bytes, whereas AWS and most on-prem setups use 1500. If Unreal Horde is expecting larger packets and Azure is fragmenting them, that could explain the reassembly errors.

netsh interface ipv4 show subinterfaces

If MTU is lower than 1400, set it to 1400:

netsh interface ipv4 set subinterface "<INTERFACE_NAME>" mtu=1400 store=persistent

Then restart the VM and test again.

Since AWS and on-prem work fine, check if Unreal Horde is binding only to specific interfaces in Azure.

Run this inside the Azure VM:

netstat -an | findstr LISTEN

Make sure it’s listening on 0.0.0.0 (all interfaces), not just localhost (127.0.0.1). If it’s bound to the wrong interface, update its configuration.

Azure VMs sit behind an implicit Azure Load Balancer, which has a default TCP idle timeout of 4 minutes. If Unreal Horde is sensitive to connection drops, this could be a factor.

Try increasing it to 30 minutes:

az network lb rule update --resource-group <RESOURCE_GROUP> --name <RULE_NAME> --idle-timeout 30

Please refer the documents below.

https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning

https://learn.microsoft.com/en-us/cli/azure/network/lb/rule?view=azure-cli-latest

If the comment was helpful, please don't forget to click "Upvote".

If you have any further queries, please let us know we are glad to help you.

Thank You.
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-18T06:41:25.57+00:00

Hi Alejandro Fernández,

Just checking in to see if you had a chance to review the answer on your question. Feel free to reach out if you have any further queries.

If you found the information useful, please click "Upvote" on the post to let us know.

Thank You.
Alejandro Fernández 0 Reputation points

2025-03-18T09:36:31.21+00:00

Hi @Pramidha Yathipathi ,

We have already went through your answer above with no luck.

MTUs on both AWS EC2 machine and Azure VM are 1500 bytes. Unreal Horde is listening on all interfaces (0.0.0.0), and finally we updated TCP idle timeout to 30 minutes.

I'm running out of ideas, as I reviewed the components (VM, NSG, Interface, Public IP, Network and subnet) and can't see a setting that could be affecting the connexion. Still something is happening with the packets as seen in Wireshark.

What could you suggest at this point to continue investigating forward?
Alejandro.
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-19T08:24:54.66+00:00

Hi Alejandro Fernández,

As MTU 1500 bytes try by MTU is lower than 1400, set it to 1400 or 1450:

netsh interface ipv4 set subinterface "<INTERFACE_NAME>" mtu=1400 store=persistent

restart the VM and test again.

If not, Since Wireshark shows TCP reassembly errors, use TCPDump on the Azure VM to capture real-time packet data:

tcpdump -i eth0 -nn port 13340 or port 13342 or port 5000 or port 50002 or portrange 7000-7010 -vvv

Compare this to the AWS VM’s output to identify any Azure-specific packet manipulation.

Even though NSG allows traffic, Azure DDoS Protection or network intrusion prevention systems might still be interfering. If you have DDoS Protection enabled, try disabling it temporarily and test the connection

Steps to check DDoS Protection:

Go to Azure Portal → Networking → DDoS Protection Plans.

See if your VM’s network is linked to a protection plan.

If it is, try removing it and test again.

If the Unreal Horde agents are communicating with multiple services, Azure might be blocking asymmetric routing (when packets go out through one path but return via another). To allow it:

az network nic update --name <NIC_NAME> --resource-group <RESOURCE_GROUP> --enable-ip-forwarding true

If not, try deploying a virtual machine in a different Azure region, preferably one nearer to your local network, to investigate any possible regional network issues, latency, or routing inconsistencies.

If the comment was helpful, please don't forget to click "Upvote".

If the issue still persist and having any further queries, please let us know we are glad to help you.

Thank You.
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-20T04:44:47.1733333+00:00

Hi Alejandro Fernández,

Just checking in to see if you had a chance to review the comment on your question. Feel free to reach out if you have any further queries.

If you found the information useful, please click "Upvote" on the post to let us know.

Thank You.
Pramidha Yathipathi 1,135 Reputation points Microsoft External Staff Moderator

2025-03-21T04:24:54.9533333+00:00

Hi Alejandro Fernández,

Just checking in to see if you had a chance to review the comment on your question. Feel free to reach out if you have any further queries.

If you found the information useful, please click "Upvote" on the post to let us know.

Thank You.
Alejandro Fernández 0 Reputation points

2025-03-21T11:18:43.0166667+00:00

Hi @Pramidha Yathipathi

We tried changing MTU to 1400 and 1450, restarting VM and still the same.

The "tcpdump" is a bash command in Linux, we are using Windows machine for the Unreal Horde agent. We can capture tcp packets with Wireshark in AWS EC2 and Azure VM and share it with you here if that's an option.

No DDoS enabled in our Azure subscription.

Regarding the last command:

az network nic update --accelerated-networking true --name MyNic --resource-group MyResourceGroup

It does not work. Either way, that is an option we have already tried from the Azure UI, both enabled/disabled accelerated networking, restarting the VM, and still nothing seems to fix this issue.
Vinay B 500 Reputation points Microsoft External Staff Moderator

2025-03-24T09:06:29.25+00:00

Hello Alejandro Fernández

I understand that you tried Standard Network and Security Checks & Network Analysis and Packet Behavior as part of the troubleshooting, but yet to address the issue.

Since the issue, Unreal Horde agents on Azure VMs experience connection timeouts, despite all required ports being open and network configurations correctly applied.

You also specified that the same setup works on AWS and on-premises, suggesting an Azure-specific networking issue & logs show TCP reassembly errors possible packet fragmentation.

Azure VMs utilize network optimization features like TCP Chimney Offload, Receive Side Scaling (RSS), and Large Send Offload (LSO). Disabling these can help resolve packet fragmentation and reassembly issues.

netsh int tcp set global chimney=disabled netsh int tcp set global rss=disabled

Disabling LSO can be achieved using the following command

Disable-NetAdapterLso -Name "<AdapterName>"

You can also try enabling TCP Keep-Alive can help maintain idle connections and prevent timeouts.

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime /t REG_DWORD /d 300000 /f reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveInterval /t REG_DWORD /d 10000 /f

This will set the KeepAliveTime to 5 minutes and the KeepAliveInterval to 10 seconds.

Sometimes If regional network issues might also cause the issue, deploying your VM in a different Azure region can help identify if the problem is region-specific.

Please let us know if it was helpful, and feel free to reach out if you have any further queries.
Vinay B 500 Reputation points Microsoft External Staff Moderator

2025-03-25T03:24:00.8633333+00:00

Hi Alejandro Fernández,

Just checking in to see if you had a chance to review the comment on your question. Feel free to reach out if you have any further queries.

If you found the information useful, please click "Upvote" on the post to let us know.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-03-25T12:48:39.93+00:00

Following up on this case. Kindly confirm if the steps provided by Vinay B was useful.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-03-26T06:28:23.57+00:00

Hi Alejandro Fernández, from what I understood from the entire conversation here is Wireshark revealed the error:

"TCP reassembly error, new fragment overlaps old data"

This strongly points to issues with Azure's virtual NIC offloading or segmentation behavior.

The root cause is most likely related to Azure's NIC offloading or segmentation behavior, which differs subtly from AWS or on-prem environments. Disabling offloading and adjusting TCP/IP stack settings resolves similar packet overlap issues in many cases. Could you kindly share the logs with us once over private message. Since Wireshark has indicated TCP reassembly errors, we can conduct an analysis of the packet flow between your local machines and the Azure VMs. This might help identify anomalies or patterns that could point to the root cause.
Alfred 0 Reputation points

2025-03-26T10:22:01.2333333+00:00

Hello Arko.

I am Alfred Barbero an Unreal Engine programmer working with Alejandro.

We have modified the registry entries KeepAliveTime and KeepAliveInterval, disabled LSO and RSS but could not disable Chimney offload (does not appear as a valid command option).

After these modifications the problem still persists.

Currently Alejandro is on holidays until the 10th of April.

We can either wait until he comes back as he is our only backend programmer or I can send you the Wireshark packet capture files from both my machine and the VM sides and go from here. If you need any other logs or modifications in the Azure environment it would be really helpful if you can guide me on how to perform these actions step by step as my knowledge outside a Windows or Linux machine is limited.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-03-27T07:10:07.3333333+00:00

Hello Alfred, due to security reasons, would request you not to share the wireshark packet capture data on the public forum. There is a private chat box with Alejandro which you won't be able to access. If the matter requires urgent attention then would request you to create a fresh case for the same issue from your end and we can continue there.
Alfred 0 Reputation points

2025-03-27T08:48:38.5933333+00:00

Hello Arko.

We will wait for Alejandro to come back then.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-03-28T13:44:07.58+00:00

Would request Alejandro to open a fresh case once he returns from his leave with same content of this question. We can follow up from there. Thanks

Answer 1

Hi Alejandro Fernández,

The Azure setup is blocking the connection, likely due to Azure networking or the Windows Firewall inside the VM, even though the necessary ports are open in the NSG.

Even if the NSG allows traffic, the firewall inside Windows can still block it. Try temporarily turning it off and see if the connection works:

netsh advfirewall set allprofiles state off

If fixed, allow Unreal Horde and required ports in the firewall, and ensure the NSG is applied to both the VM's interface and subnet. Check for other NSGs that may override rules.

Are you connecting using a public or private IP? If it’s private, your local machine needs access to the Azure VNet, either through a VPN, ExpressRoute, or a correctly configured peering setup.

– Run this on the VM to check if the service is running and listening on the expected port:

netstat -an | findstr :<port>

If nothing shows up, the issue might not be networking—it could be that Unreal Horde isn’t running correctly or isn’t set up to listen on the right interface.

Since AWS worked without any extra configuration, check if Unreal Horde has any settings that need to be adjusted for Azure. Some software expects a different type of network setup depending on the cloud provider.

Test you can run: From your local machine, try

Test-NetConnection <VM-IP> -Port <Port>

If that times out, the issue is almost certainly a networking or firewall problem.

If you found the information useful, please click "Upvote" on the post to let us know.

Thank you.

Share via

Connection timeout to VM with Windows 10/11 with opened ports

1 answer

Your answer