Please enable out-of-order UDP fragment reassembly for our subscription in westus2.

Question

Please enable out-of-order UDP fragment reassembly for our subscription in westus2.

Arsen Abayan 0

Hello,

We have an Azure Linux VM in West US 2 that receives UDP traffic from the public Internet.

When incoming UDP packets require IPv4 fragmentation because the resulting packet is larger than the standard 1500-byte MTU, a significant portion of the fragmented packets is lost. In repeated tests, more than half of such packets can be lost.

The application works normally when we avoid outer UDP/IP fragmentation by lowering the tunnel MTU. The issue appears only when the Azure VM needs to receive and reassemble fragmented UDP/IP packets from the Internet.

This looks consistent with Azure dropping out-of-order UDP/IP fragments before the VM can reassemble them.

According to related Microsoft Q&A answers, Azure Support can enable a platform-side feature usually referred to as out-of-order UDP fragment reassembly / UDP fragment reordering.

Could an Azure support engineer confirm whether this feature can be enabled for a VM/VNet in West US 2, and how we should request it under a Developer support plan where the Azure Support API rejects ticket creation with InvalidSupportPlan?

I can provide subscription ID, resource IDs, public IP and packet-capture details privately if a Microsoft engineer needs them.

Thank you.

Praveen Bandaru 11,555 Reputation points Microsoft External Staff Moderator

2026-05-02T17:36:34.1866667+00:00
Hello **Arsen Abayan
**It looks like you’re running into Azure’s default behavior of dropping out-of-order UDP fragments when they arrive at the VM’s public IP in West US 2. Azure can enable a platform-side “UDP fragment reordering” flag for your subscription so your Linux VM can reassemble those fragments, but it has to be turned on by the networking team. Here’s what you can do:

Make sure the UDP traffic is coming in over a public IP directly attached to your VM. (ExpressRoute or VPN Gateway paths aren’t supported for UDP reordering.)

Confirm your VM is deployed on one of the supported hardware clusters.

Verify there’s no NAT Gateway, load-balancer or Azure Firewall in front of your VM IP.
Arsen Abayan 0 Reputation points

2026-05-02T19:16:47.7366667+00:00
Hello,

Thanks for the confirmation.

I checked the requested prerequisites:

The UDP traffic is coming in over a public IP directly attached to the VM NIC. This is not ExpressRoute or VPN Gateway traffic. The VM has a Standard static Public IP associated directly with the primary IP configuration of its NIC.

I cannot confirm the "supported hardware cluster" requirement from the customer side. Azure CLI and IMDS expose the VM region/size and fault/update domain, but not a hardware cluster identifier. The VM is in West US 2 and uses Standard_B2pts_v2. Please confirm from the Azure networking side whether the current host/cluster supports UDP fragment reordering.

There is no NAT Gateway, public Load Balancer, or Azure Firewall in front of this VM public IP. The subnet has no NAT Gateway and no route table, the effective default route is Internet, and the NIC is not attached to any Load Balancer backend pool or inbound NAT rule.

We also tried enabling IP forwarding on the VM NIC, but it did not change the behavior.

Please let us know the secure way to provide the subscription/resource details, because we do not want to post subscription IDs or exact resource identifiers publicly on Q&A.

If possible, it would be very helpful to enable this UDP fragment reordering capability at the tenant or subscription level rather than only for this single VM/resource. We may deploy similar UDP/WireGuard workloads in other Azure regions, and we would prefer not to open a separate request for each individual VM if this can be enabled more broadly.