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

Arsen Abayan hi & thanks for join me here at Q&A portal,

yes, this is a known Azure networking behavior with fragmented UDP traffic, and the practical fix is either avoid IP fragmentation by lowering MTU, or ask Microsoft support to enable UDP fragment reordering for the affected subscription or VM path. This is not a Linux setting if fragments are dropped before reaching the VM.

Your test already points in the right direction. If the app works when u lower tunnel MTU and fails only when public Internet UDP packets arrive fragmented, then the issue is the Azure fabric handling of out-of-order IP fragments. There are Microsoft Q&A cases describing the same request as “UDP packet re-ordering” or “out-of-order UDP fragment reassembly”, and support involvement is required. https://learn.microsoft.com/en-us/answers/questions/5536544/need-udp-fragmentation-packet-reorder-applied-to-a

Do not rely on the VM OS to fix this. The VM can only reassemble fragments it actually receives. If Azure drops out-of-order fragments before delivery, Linux never sees the full datagram. Cisco even documents this Azure-specific workaround for similar fragmented UDP cases and calls out the enable-udp-fragment-reordering option. https://www.cisco.com/c/en/us/support/docs/troubleshooting/222339-troubleshoot-fragmentation-issues-affec.html

Send support a focused request like enable UDP fragment reordering for subscription <sub-id> in westus2, affected public IP, NIC, VM resource ID, and VNet. Include packet captures from sender and VM showing first fragments arrive but later out-of-order fragments are missing, plus the MTU workaround proving the app works without outer fragmentation.

if Azure Support API returns InvalidSupportPlan, create the case from Azure Portal instead of API, category Virtual Network or Virtual Machines networking, problem type Connectivity, and put “enable UDP fragment reordering” in the title. If the portal still blocks technical case creation, use billing or subscription support only to fix the support-plan entitlement issue first, then open the networking case. Actually Q&A moderators cannot safely collect subscription IDs or enable the flag publicly. Long term, the cleaner fix is still to avoid public Internet UDP fragmentation lower tunnel MTU, enable path MTU discovery where possible, reduce encapsulated packet size, or move the UDP service behind a design that does not depend on fragmented UDP over the Internet.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

Hello Arsen Abayan

Based on the details you provided, your configuration—UDP traffic coming directly from the internet to a VM using a Standard Public IP attached to the NIC, without a Load Balancer, NAT Gateway, Azure Firewall, or VPN/ExpressRoute—matches a supported scenario where Azure can consider enabling UDP fragment reordering at the platform level.

However, whether out-of-order UDP fragment reassembly is supported depends on certain backend factors that are not visible or accessible to customers. This capability is linked to the Azure host networking stack and the hardware cluster hosting the VM. Although you can view VM size, region, and fault/update domains with CLI or IMDS, there is currently no way to identify the hardware cluster or verify its support for UDP fragment reordering. Only the Azure networking or host engineering teams can perform this validation internally.

Additionally, UDP fragment reordering is not enabled by default in Azure. This is by design, as dropping out-of-order fragments helps mitigate security risks and maintains consistent platform performance. If enabled, the platform can buffer and reassemble out-of-order fragments, but this introduces extra processing and may affect how traffic is handled by the host networking stack.

Regarding broader enablement, this feature is scoped at the subscription and region level. It cannot be enabled globally at the tenant level, and it does not apply automatically across all regions or subscriptions. Even when enabled for a subscription, it only works for workloads on compatible backend clusters. If existing VMs are not on supported hardware, enabling the feature may require redeployment or moving to compatible infrastructure.