MTU Optimization for Network Connect / Pulse

[mtessier_]

One of our users has reported an issue with an application that they believe may be MTU related. I've been doing a little research and it appears that packets passing through the VPN using Network Connect get fragmented if they are above 1400 bytes. I found this value by pinging across the tunnel with the Do Not Fragment bit set to on and an increasing payload. I found that packets over 1372 are getting fragmented. Add to this amount the overhead of ICMP (28 bytes) and you get an MTU of 1400.

Poking through the forums, I found another post that confirmed that the Juniper tunneling adapter adds 100 bytes to each packet's header. Doesn't this mean that we're left with an effective MTU of 1400 bytes on packets from the Net Connect / Pulse endpoints?

If so, wouldn't it be optimal to set the MTU on the IVE / MAG down to 1400 to avoid fragmentation for Net Connect / Pulse?

Ref: https://forums.pulsesecure.net/topic/pulse-connect-secure/38191-problems-with-windows-7/highlight/tr...

[Kita_ · Accepted solution]

Do we have a ticket open for this one?  NC/Pulse MTU size on the VA should be 100 less the total size of the MTU on the physical interface.  This is due to the encryption and decryption of the packet.

If you are seeing 1400 size out of the internal interface of the SA, then I would check to see what the MTU size on the client's VA is.  There may be another VA on the device which is decreasing the overall MTU size on the NC/Pulse VA.  You should be able to tell the MTU size from the debuglog as well.

[mtessier_]

Kita,

No need for a ticket. I did some further investigating and it's working correctly. I was under the false assumption that the MTU configured on the virtual interface was equal to the MTU configured on the SA. You were 100% correct. The MTU on the virutal interface was set at 1400 and the MTU on the SA was set at 1500. I was able to craft packets up to 1400 bytes and send them through the tunnel with no fragmentation.

Thanks!