Large TCP packets dropped over Site-to-Site VPN tunnel — suspected MTU/fragmentation issue on VPN Gateway data path.

Question

Large TCP packets dropped over Site-to-Site VPN tunnel — suspected MTU/fragmentation issue on VPN Gateway data path.

Scavi JS 0

Dear Support;

My site connects to Azure IPsec Site-to-Site VPN to Azure VPN Gateway (SKU: VpnGw1)

On my Sophos XGS4300 device, I configured the tunnel interface with an MTU of 1400 and an MSS of 1350.

We have an internal client/server production management application. When the client uses the application to work, sending large packets results in dropped logs.

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

[2026-08-14 14:24:36] (RequestId: 20260814142330010_PcName_3fde6dc98d53499aabda1218c0b0d92a, Size: Size: 1384 bytes) Message: (IsTransientSendFailure.IOException(A connection that was expected to be kept alive closed by the server)(169.254.88.135)) PROCEDURE: usp_PP_GetListSmallOrderFactorJSON_V1 - HttpRequestException: An error occurred while sending the request.

StackTrace: at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at System.Net.Http.HttpClient.<FinishSendAsyncUnbuffered>d__59.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()

at CNY_BaseSys.Common.AccessDataAPIConnect2.<ExcutePostDataToCNY>d__34.MoveNext()

?? InnerException: The underlying connection was closed: An unexpected error occurred on a receive.

?? InnerException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, established connection failed because connected host has failed to respond.

?? InnerException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

[2026-08-14 14:28:36] (RequestId: 20260814141335982_Pcname_75246c7ee2274e83a81f01905b5aba63, Size: Size: 1139 bytes) Message: HttpStatusCode: NotFound - PROCEDURE: usp_PP_LoadProductionData_JSON_V24 - HttpRequestException: Response status code does not indicate success: 404 (Not Found).

I checked:

ping -f -l 1330 Server_IP → success
ping -f -l 1331 Server_IP → fails ("packet needs to be fragmented but DF set")

Can you confirm the effective MTU / maximum supported packet size on the Azure VPN Gateway data path for this specific Site-to-Site connection.

Are there any packet drop / fragmentation counters or diagnostic logs on the VPN Gateway side showing drops for connection on-prem with Azure VPN Gateway during our test window ([date/time], GMT+7).

Thank you so much.

0 comments

1 answer

Your answer

Answer 1

Hello @Scavi JS

Your test strongly points to a path MTU issue, but I wouldn’t conclude yet that Azure VPN Gateway itself is dropping valid packets unexpectedly.

You already configured the Sophos tunnel with:

MTU 1400

MSS 1350

which matches Microsoft’s current recommendation for Azure VPN/IPsec scenarios. Microsoft specifically recommends TCP MSS clamping at 1350 bytes and a tunnel-interface MTU of 1400 bytes.

The important part of your ping test is:

ping -f -l 1330 -> succeeds

ping -f -l 1331 -> fragmentation required

For IPv4 ICMP, the payload isn’t the whole packet. Adding the 20-byte IP header and 8-byte ICMP header means those tests correspond to roughly 1358 and 1359 bytes of IP packet size. So the effective path MTU you're observing is around 1358 bytes, which is lower than the 1400-byte tunnel MTU configured on the Sophos.

That means I would check whether there is another device/path segment imposing a smaller MTU, or whether PMTUD is being broken.

Microsoft explains that when a packet exceeds the path MTU with DF set, the intermediate device drops it and should return ICMP Fragmentation Needed (Type 3, Code 4). If that ICMP response is blocked by a firewall, the sender never learns the smaller MTU and TCP can repeatedly retransmit or stall.

Also note that Azure VPN Gateway explicitly states that IP fragmentation is not supported for ESP packets or for packets encapsulated inside the Site-to-Site tunnel. That makes avoiding fragmentation through the correct MSS/MTU even more important.

I would therefore verify:

MSS clamping is actually applied to the TCP SYN/SYN-ACK packets crossing the Sophos tunnel, not just configured on the interface.
ICMP Type 3 Code 4 is not being blocked in either direction.
There are no additional firewalls/NVAs or WAN devices with an MTU below 1400.
The Azure VM NIC remains at the normal MTU rather than being increased.

A packet capture on both sides would be especially useful. Check the TCP SYN/SYN-ACK and confirm the negotiated MSS. If you still see MSS 1460 or another value above 1350, the Sophos MSS clamp is not taking effect on that flow.

Regarding Azure-side diagnostics, VPN Gateway packet capture is available and can help confirm whether the packets are reaching/leaving the gateway. However, there isn’t a documented per-connection counter that simply says “dropped because packet exceeded MTU.” I would correlate a VPN Gateway packet capture with the Sophos capture during the same UTC test window.

Based on the current evidence, I’d treat this first as a PMTU/MSS mismatch somewhere in the end-to-end path, rather than a confirmed Azure VPN Gateway defect.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.