Hi,
We are having a situation where we have an application that works perfectly fine in legacy. As soon as we migrate to SDWAN, the application starts rebooting and doesn't register. After analysis we found the application is sending certain bytes of MTU and expecting the same which works perfectly fine on legacy network. Unfortunately we are also not able to set the MTU under DHCP for this particular application.
My question is:
1. Are we adding additional bytes for the VPN tunnel? Will MX report 1500 bytes or will it adjust the reporting value to the "available to the end point/user" (i.e., Total MTU minus the header that it's going to use/add for establishing its VPN)?
2. Can MX change the LAN side MTU? Or can it handle fragmentation/defragmentation within the box itself at the L2 level making it transparent to the application end points that there is some "VPN" in the path and the original payloads are being fragmented?
Hi ,
Is it TCP based or else ?
The MX will clamp the TCP-MSS
It is HTTP traffic actually. We did follow the steps in that link, but can't get the application working as of yet.
So TCP. Have you tried to capture on the VPN tunnel to see the 3-way handshake ? Do you see any fragments on the other end ?
MTU shouldn't be an issue since the MSS is clamped.
Bottom is the original SYN ( on my computer , before VPN tunnel ) , Top (inside the VPN tunnel ) is the SYN after MSS clamping.
Thanks, that means VPN header doesn't add any additional bytes for this traffic. We are going to open a TAC case to troubleshoot further. Just want to see if changing MTU on WAN links help
The MX uses an MTU size of 1500 bytes on the WAN interface. I think you should have to open a support case.
There were some recent bug fixes in firmware to do with MTU over AutoVPN.
Review the firmware release you are using against those bug fixes. I suspect you might just need to update your firmware.