I've seen several conflicting recommendations for IPSec tunnel MTU/MSS.
First and foremost, publishing this (preferably inside the tunnel slice/pane) is a good first step, since it'd allow us to know definitively what we can do.
Second, and more significantly, I'd like to be able to CHANGE it... preferably by increasing the size... it seems that every time I turn around, the MTU needs to shrink - I'd rather leverage jumbo frames to allow higher throughput.
Thanks for the feedback – totally understand the pain points and confusion. There are a couple of constraints on the Azure side and also specifically with VPN. The key issue is this is for packets coming over the Internet which we can only assume total packet size of 1500 bytes max. Azure SDN platform performs additional encapsulation on the packets within our datacenter networks, so it will be subtracted from there.
1. On the Azure VPN gateways, the recommendation is to set TCP MSS clamping to 1350; or if not possible for your device, then set MTU to 1400 bytes on the IPsec tunnel interface. We had updated/clarified the Azure documentation to call that out.
2. Changing MTU currently is not possible from the Azure VPN gateways. We will take it into configuration, but it will not be possible in the short term due to the scale of changes we need to do.
CA RIBON commented
This is a great issue on Azure infrastructure. In our case we have some servers that send a frame with don’t fragment field set, for that, the frame is dropped out by the Azure VPN GW.
My question. Why cannot a MTU of 1500 be configured? When Is Azure going to fix the issue with the value of the MTU and the MSS?
I am experiencing the similar issue but in my case the packet did not even go out. The large packets are marked as bad checksum and it seems like just dropping them as errors. Would you please advise me if you were able to resolve your issue?
I also just completed an exhaustive troubleshooting session with Premier Support to discover the MTU was the root cause for erratic responses to ASE web apps behind our ILB. I realize that ILB's and Connectors start getting into the realm of the MS network but it is extremely difficult to properly troubleshoot an issue without deeper visibility than we currently have. Coordinating with engineering for traces adds additional time to the process as they are always running with a full schedule so unless I pull in my TAM and escalate to a Sev. A, I go on the waiting list.
My issue was related to Express Route but I believe this tunnels via IPSec on your backend. Like Scott, I would also like the option to modify the settings for the ILB or ER interface. When we start integrating multiple technologies like Citrix and streaming media services they require different frame sizes for optimization so clamping the MSS to a single size on our ASR on prem does not scale very well.