HTTPS fragmentation issue over IPSEC VPN

[John Adams]

Hello,

I've got a problem that hopefully you can help with:

Remote Office.
PC - MTU Default 1500
Switch - MTU Default 1500
Firewall - MTU Default 1500
Cisco WAN Router:

• inside interface - MTU Default 1500
• outside interface - MTU 1600

>>>

Note: Outside interfaces on Cisco Routers links to 1GB BT Fibre line. AES128 IPSEC VPN tunnel configured on the Cisco Routers.

>>>

Head Office.
Cisco WAN Router:

• outside interface - MTU 1600 
• inside interface - MTU Default 1500

Firewall - MTU Default 1500
Switch - MTU Default 1500
Server - MTU Default 1500

The PC can access everything at head office on the Server.
HTTP is perfect.
Unless it's HTTPS traffic. Then it struggles to load the pages. They load eventually, but often time out.
I believe this may be fragmentation, but not sure what to change/where/why?

[briadunn]

Hello,

Without seeing each device(s) config and/or a packet capture when the SSL session fails it will be difficult to give an exact answer on the cause. However, if fragmentation is playing a role with the topology you've given - you may use the "ip tcp adjust-mss <size>" command on the transport interfaces along the path. A safe MSS starting size, since you may have various IPSEC configurable options added would be - ip tcp adjust-mss 1400
 

A good article describing the behavior can be found here: http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
 

Thanks,

BD

[John Adams]

I've done a wireshark on the client PC and requested the https page. I can't share it unfortunately, but I see lots of TCP Dup ACK,, TCP Fast Retransmission (Application Data) and TCP segement of a reassembled PDU.

Does this indicate the MTU issue still, or something different?

Where to go now?

[Richard Burts]

The indication of segment of a reassembled PDU does sound like fragmentation. I would suggest that you use the command that BD recommended ip tcp adjust-mss and see if that helps. He suggests a size of 1400. I have done some VPN implementations where size of 1360 was more effective than size of 1400. You might experiment with different sizes and see what is most effective for you.

HTH

Rick

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Assuming end-to-end supports a 1500B packet, 1400 is usually 20 to 40 bytes smaller than what's needed.  However, Rick is correct, it's worthwhile testing.

For the TCP adjust-mss command, using smaller than needed is "safer" in the sense that you're unlikely to accidentally fragment, but getting closer to the necessary minimum size is slightly more efficient; also for IP MTU, it's much better to not size smaller than you must.

BTW, TCP adjust-mss only works when the TCP session starts across such a configured interface, which sounds like it always should be in your case, but it's something to remember if the encrypted path is an alternative to a non-encrypted path.

TCP adjust-mss is a very worthwhile command, but don't overlook the other suggestions in the reference BD provided.  If they are followed, perhaps not only will your HTTPS stop struggling, but other traffic will perform better too.