Virtual Network: Out-of-order IP fragment reassembly for FortiGate NVA — Support inquiry

Question

Virtual Network: Out-of-order IP fragment reassembly for FortiGate NVA — Support inquiry

David Grenon Cloud ADM 0

Problem description

I am seeking assistance regarding enabling out-of-order IP fragment reassembly for my FortiGate NVA's public IP in Azure. My resource is experiencing issues with fragmented UDP packets over IPsec tunnels, where fragments are arriving out of order or missing, impacting tunnel connectivity.

Environment

Azure Virtual Network in Canada Central with a FortiGate NVA VM running FortiOS 7.4.12 on a Standard_DS2_v2 instance, external NIC with accelerated networking, and a Standard SKU public IP.

What I've already tried

I reviewed the support case details and available Microsoft guidance on NVA scenarios. I examined the case history and diagnostic outputs, noting that no specific Azure setting was documented to enable out-of-order IP fragment reassembly. I also checked for network security groups, user-defined routes, and routing behavior, but found no configuration changes or diagnostic insights that address the fragment loss issue.

Current status

The issue persists: the first IP fragment often arrives, but subsequent fragments are frequently missing or arriving out of order. I am seeking clarification on whether Azure can support enabling out-of-order IP fragment reassembly for this scenario, and if not, what mitigation strategies are recommended to improve UDP traffic delivery over IPsec tunnels.

David Grenon Cloud ADM 0 Reputation points

2026-10-01T12:31:51.76+00:00

Thanks for the answers. I've been troubleshooting with Meraki and it seems that a firmware upgrade might fix the issue for the post-encryption:

We're currently at on our MX250's: MX 26.1.5

And the support propose: 26.2.3

Only happening with MX250 from what they told me:

*"Thank you for your consent. I have generated some artificial ICMP and UDP traffic across the VPN and I can confirm the same behavior on both IPSec peers this MX250 connects to. Thinking it might be something related to firmware & hardware combination I have set up an example IPSec between an MX250 running the same firmware, and an MX67 - unfortunately, even with the same IPSec settings and WAN MTU I was unable to reproduce this issue. Generating the same traffic from my test MX250 always resulted in it being fragmented before encryption, and so, I never saw ESP traffic being fragmented. I have collected additional evidence from your and my setup and decided to raise a collaboration case with our Product Specialist team to further understand the difference between the two, and pinpoint the root cause. As soon as I have further suggestions available I will let you know."

*And later last night:

*"Our Product Specialist was able to reproduce this issue in the lab, and the key difference between my and his setup was HA. Issue does not occur on standalone MXs, which is why I was not able to reproduce this.

With that said, they have tested different firmware versions - the same behavior was seen on MX 26.1.5 and latest recommended release 26.1.7.1, however it's not reproducible on 26.2.3 (which is in a Generally Available branch).

We will continue to investigate this and once we find out what is different between 26.1 and 26.2, evaluate a possibility of addin a fix in the former. In the meantime however, since there is a firmware where we know fragmentation works as expected, would you be happy to try an upgrade to 26.2.3 to see if this solves the problem for you?"

*
The upgrade is planned for tonight. I'll keep you posted.

2 answers

Your answer

Answer 1

Hi @David Grenon Cloud ADM

As far as I'm aware, there is no Azure Virtual Network or Public IP setting that allows customers to enable out-of-order IP fragment reassembly for traffic destined to an NVA. The reassembly of fragmented packets is typically handled by the destination host or appliance, not by an Azure Public IP resource. Given your symptoms (fragmented UDP traffic over IPsec, missing later fragments, and packet ordering concerns), the usual mitigations are:

Reduce packet size and adjust MTU/MSS values to avoid fragmentation where possible.
Enable IPsec fragmentation handling features supported by the FortiGate platform.
Validate whether UDP encapsulated traffic can be tuned to remain below the path MTU.
Capture traffic on both sides of the tunnel to determine whether fragments are being dropped before reaching the NVA. (General troubleshooting suggestion.)

Based on the information provided, I am not aware of an Azure feature that can be enabled on a Standard SKU Public IP or NIC specifically to force fragment reordering or reassembly before delivery to the FortiGate NVA.

If Microsoft Support has already reviewed the case and no Azure configuration option was identified, the next step would likely be to investigate MTU/fragmentation behavior and FortiGate-specific handling of fragmented IPsec traffic rather than an Azure networking setting.

If this helps clarify the Azure side of the issue, please mark the answer as helpful or accepted so others troubleshooting fragmented IPsec traffic with NVAs can find it more easily.

Answer 2

kagiyama yutaka 5,575

I think Azure drops out-of-order fragments arriving at the VM, and fragmented packets take the nonaccelerated path. TCP MSS clamping does not address UDP, so avoid IP fragmentation. Check the path MTU first, then adjust the FortiGate tunnel MTU.

0 comments